<%BANNER%>

A Speed Adaptive Mobile Internet Protocol over Wireless Local Area Network

xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20110403_AAAAHG INGEST_TIME 2011-04-03T21:27:27Z PACKAGE UFE0012700_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 1748 DFID F20110403_AABWEK ORIGIN DEPOSITOR PATH tian_j_Page_034.txt GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
2f65a5a11edd4c1670c01d73843890ca
SHA-1
83e9d771d515cd7740584b8c8562d572f9b9c87b
866282 F20110403_AABVZE tian_j_Page_088.jp2
dcc38d02ad1ce08a1bab8d410c806a19
0b06f617c22b7663a550994a021561b07ebe93ac
1454 F20110403_AABWDW tian_j_Page_018.txt
3f4af748d5924069cad61657d2951c7c
689f1b12c47dcb9a703d23eed628fe8af55efc86
1916 F20110403_AABWEL tian_j_Page_035.txt
ccb7e5eaea39f5c55dc57d6bfb1c0e93
22ada78883ec6e6ba0812e6b1f4bc58b5069ce73
945428 F20110403_AABVZF tian_j_Page_090.jp2
bb566b3e10439324a425fc807f595fed
ceb6736f690eb0f949c69dc6264c2b89a9501f46
2459 F20110403_AABWDX tian_j_Page_019.txt
e63e3c7a3fab96c8c1323661f4ee8910
ec01cec9c254220d9c9e5d408ac498f5ba28fade
597854 F20110403_AABVYQ tian_j_Page_071.jp2
0fd5cbcc9462d65083249360ce4aa7bf
2c140d20ad156f9caab8df1b0d6054b4cd4e4857
1493 F20110403_AABWEM tian_j_Page_036.txt
4cd11f51c28c283d8284dfb5dfe8344b
00cb49dc7229b6998968f96d417dfbcae108dc8a
830048 F20110403_AABVZG tian_j_Page_091.jp2
677cb71e08658af5f2b50a95d465c31c
7520bb1e3a4deb7ce4e9f228642fdf0a23db289a
2503 F20110403_AABWDY tian_j_Page_020.txt
87169ac002e3a0a9f69f5a91fc197a7f
1a1697ef826d891e3679a04bc4fe822e29c79ca4
531838 F20110403_AABVYR tian_j_Page_072.jp2
04445376a1fcaa6e55ddb56a2468d9c5
3f31e2b1c620b025696fe09813b18e4d07ff5ca8
1474 F20110403_AABWFA tian_j_Page_052.txt
59e07c5c5320f1b3a8fda9a29d3bd08f
7a2aa0d3e74894b71d700eef41383a40e9ae125d
1040976 F20110403_AABVZH tian_j_Page_093.jp2
66c5d2a37a24b795f9be98fd3740bfbf
25e5ead7f639a6a8cd4ba942247a188eb3966835
1963 F20110403_AABWDZ tian_j_Page_022.txt
b28848c011322b87c93911e2e02e6caf
f3ab2dcd412b11e7ece58956eb6d4858bd6dc99a
885658 F20110403_AABVYS tian_j_Page_073.jp2
b973a277df5e13e2c2c9a34490f2bcc5
5fcae695ae16fa0590d05b322bd11187b35256ae
1801 F20110403_AABWFB tian_j_Page_054.txt
9851a6ef7e8529b4a2c33d3346ddce85
7c063ed8b4be551198f0160f62a426364c1ea434
1414 F20110403_AABWEN tian_j_Page_037.txt
1f8934d8560296f8f105078e04823513
2154c48931e4f931ea9169d339b9784e5605da81
561113 F20110403_AABVZI tian_j_Page_094.jp2
3e0bb4522dc6def01eb9d2f2c0f521bf
edb426f2ce6d58ff39237c66c856c099022d0888
996862 F20110403_AABVYT tian_j_Page_074.jp2
f2ade621ae0e2981f2d610994e09d175
d760c55519575e556a60895928c87774dabb2057
1815 F20110403_AABWFC tian_j_Page_055.txt
ccdc79597b57f5dbd5defb7e76fbccb9
b1e85d9029c8607db58aae59938dcd4f4fd1293b
1833 F20110403_AABWEO tian_j_Page_038.txt
8f7ad4eb225a46e470ef48857029da60
148635b23220844c61e7e3adb2ea38f5c5dcca05
867569 F20110403_AABVZJ tian_j_Page_095.jp2
1f8d9ef488a0183d3cab75d3481e2868
8d3190694137eb0fb07507b68f15e38732602205
980563 F20110403_AABVYU tian_j_Page_075.jp2
fcd73d4af69386846e3c0c56601ac1f2
afc7cdde93b8ab4b914a28d16b7ad036c832bacc
1706 F20110403_AABWFD tian_j_Page_056.txt
90cabafd6f6c09cde78bbcf8040a3ee1
5afe6539607da370badfa31a02bd8dc96a8dc1cd
1841 F20110403_AABWEP tian_j_Page_039.txt
673973c80d897a6e0d8d6efb416c0b5a
f1fcc5c1903386e1f97dcd14749414b66f319e87
678772 F20110403_AABVZK tian_j_Page_096.jp2
693a56623f3e97637758606593215aca
9cdf197a965fe81af64c660238ae415f9db6b326
676908 F20110403_AABVYV tian_j_Page_077.jp2
78691ad81a30a783d50a2029d9232252
4dcfb3f286f23fcde0b6f39bda637a9bb0688ad4
2074 F20110403_AABWFE tian_j_Page_057.txt
1e618a49e95d059d0f885cccfe83b13c
23cbd4f9273a9cf0c65c48abef355176500feb76
1641 F20110403_AABWEQ tian_j_Page_040.txt
8a89f0122c002ef4f353d802627e627d
0c5d84a20e2663e482503e65f70ee80a18596fb5
487401 F20110403_AABVZL tian_j_Page_097.jp2
cbfa4dd9538674cf02a533493492b85b
346bdaa07d76c52bb250ddbc25e2e3704010a5ec
746834 F20110403_AABVYW tian_j_Page_078.jp2
14742d34134737b87297128977d2a827
3b053c217d386cfc1c2b830c00c66af36ce524a9
1611 F20110403_AABWFF tian_j_Page_059.txt
b3c943342cd41600a48a2996ae70365c
466c7147a0a0e473c114dd0577205dce7460f3ac
2049 F20110403_AABWER tian_j_Page_041.txt
1c3115e52136e1379a767c652a940820
331f3de36dd5c93c6b933d40810c660dab7f3b16
311564 F20110403_AABVZM tian_j_Page_098.jp2
f443fb82e66ad550a9664be77b3443e0
2be2413ef14acb181873d020581f3ee9cc91ccd2
934401 F20110403_AABVYX tian_j_Page_079.jp2
35ce8884e2d2325de55db837ac994bf3
ebd01fd2c4d0258bc5448ec723371dde5938afe8
1754 F20110403_AABWFG tian_j_Page_060.txt
b35a55f7de6882ed12de4ca6aab0bb73
a21c99d4993cbf5498283662ee6811e5223a0d07
1401 F20110403_AABWES tian_j_Page_042.txt
01a30550f1eddfeaf5ef13dd1b0404c8
cc7ccdf26d050781ee3e779de900c9c694134fa1
833300 F20110403_AABVZN tian_j_Page_100.jp2
0a5c3a132c12d851ce5f38eaebd442e2
0e354236c346525a51441453cf23d141618f2f21
762741 F20110403_AABVYY tian_j_Page_080.jp2
823048ba71ef7f9384e19587709462ef
5b314758bf6cfd500421815825896254ac0efdcc
824 F20110403_AABWFH tian_j_Page_061.txt
edf332edbee6d3a55009cd4f3d6d5fe6
619036c703f1487687f6cd9ebbb0ab150d17d664
1580 F20110403_AABWET tian_j_Page_045.txt
da3730770d93b7f74112bf02e02b05df
fd1a913cbd48df7e7613b42d3f2e78258ecccd86
919085 F20110403_AABVZO tian_j_Page_101.jp2
7bfde25bb0246ea1ea85e174e1c6a789
c4903b540b0049888cf5b1972fc6ba56c4303362
768128 F20110403_AABVYZ tian_j_Page_081.jp2
f855c0bde990c7e33352a522cc7a0745
41cc735620660b35a937ee7844f19e3536faf31b
1790 F20110403_AABWFI tian_j_Page_062.txt
44dd6a8064f1d97e44b716f6802bfd04
2b37a809fa84f6e9a0e9af26d2a5b4b48180ccee
3130 F20110403_AABWEU tian_j_Page_046.txt
e0cb223240a0b26ccf4ff0c72f2250f4
e214194af0c67701fe5e4f15e6f69bdf878597b8
1051972 F20110403_AABVZP tian_j_Page_102.jp2
28a8a5026f0b489b9bf7f58381d6057a
3aace7f2a52c8fb862d300f9e0a3c404980e03f8
1124 F20110403_AABWFJ tian_j_Page_063.txt
607ed2da2a405b165b0cf3b02000a576
02f6028fef9c548c12d4b88b6cfa1b37c1a6d392
2580 F20110403_AABWEV tian_j_Page_047.txt
d8f6b5fff39ad39632fb01570e808399
841c87e8b82297985f45a5027b78e74adbf6ebb2
1025854 F20110403_AABVZQ tian_j_Page_103.jp2
69dea19dc3adc3b01b1c45612c87526f
a35cc684456053ae0db6373dec996995637d7892
1145 F20110403_AABWFK tian_j_Page_064.txt
30b1103e2c1f6d6a004b4598f65bf712
ee7200a246689693bc9fddf5b3fb841b44e326cf
1984 F20110403_AABWEW tian_j_Page_048.txt
cfab86f0ad9c7dae36f81cd6ebffeae2
d8e3399bbb939a4403b042762f89e1aeadbe8032
817 F20110403_AABWFL tian_j_Page_065.txt
51e81f01e5ce0f6ff13a5a844f622745
90630e7221d0faca455f0efbca3ff79931b4459b
1676 F20110403_AABWEX tian_j_Page_049.txt
4430e3889d93663a4d8b790284483548
95f81590c1d759daf807c5f18002627db7f8807f
983634 F20110403_AABVZR tian_j_Page_104.jp2
d47217936575a14f60ea7bc70f9beb61
48463e76c99ab1d6761445875fb916e1166f3b56
F20110403_AABWGA tian_j_Page_083.txt
55b3749a2392b90aa201cb6c1d9bad15
c529f73fdcf454830a4d528dbf75973be7d0270d
486 F20110403_AABWFM tian_j_Page_066.txt
762c557207a8aa1f158e7f8cc41f8b9f
539c824e40f116b6607f7b26a956ada7e966dc00
1836 F20110403_AABWEY tian_j_Page_050.txt
a3699c70557cafb527753d23c9b07a5f
ee35b3d6914e3e566f9d9eeae2810556e89a5622
1026647 F20110403_AABVZS tian_j_Page_105.jp2
329a32fbe0d4cd883a948bbb587ba93a
a3b05fc4eeddd6e5861baea9709759398a3b6d11
1572 F20110403_AABWGB tian_j_Page_084.txt
a1cc5f4aa2ec79c999478c634ea9e5ff
dcb17b5da29a96f26c2559d79dd4c4168cb7e992
1451 F20110403_AABWFN tian_j_Page_067.txt
24446ff349628a7054d56471577eddee
fe480d9fe15e3131849770252cd33b8115e8f650
1810 F20110403_AABWEZ tian_j_Page_051.txt
d01768ce2c7a2e5e08a9c9f1017ddccd
f284811bb3dccb5e28334cbe33237d07378e853b
1051893 F20110403_AABVZT tian_j_Page_106.jp2
695f81965970f0c11fb1bc0da52350ce
d6d735f9172fad669b4ea152948d72dc9e1a2e80
1873 F20110403_AABWGC tian_j_Page_086.txt
396b14a36ccce4a400ff86231e2ae3bf
53a5a2d5cc3f32c5b5ad21daee714b711ee77771
1855 F20110403_AABWFO tian_j_Page_068.txt
d2dc96c572d79a38ec39d0d89b2c737c
c2ade8ed6b0fb27b4af8f3f97cb2853cee9e41da
602 F20110403_AABVZU tian_j_Page_002thm.jpg
86caea3c7741a9e2bdb2b9931080639b
f30edac865926f4b801b77b05e3b96b672903061
1540 F20110403_AABWGD tian_j_Page_087.txt
31c1cd90b8eaa0b0b95e0f69901462ba
93285222391b9da5ce7c3315caf183195c1de76a
1639 F20110403_AABWFP tian_j_Page_069.txt
fa74244805c2f0db4746c1db23f76f70
d0ad663d9684f7c0118a9842c5147db90695fe41
3850 F20110403_AABVZV tian_j_Page_003thm.jpg
f9269e5752cde2e4ecb833d9a2132e71
2adf6dfe880de6bd935a7f450f737cd80474e372
1589 F20110403_AABWGE tian_j_Page_088.txt
b1ce509d39b8d9af38f51921b4a7268f
9e3843f6ae470d1fe51ba593ef8c004dd1eb96c0
725 F20110403_AABWFQ tian_j_Page_070.txt
656effc4e335e44a132a73b18acae258
4e82d2798b8ae66b86e181ac51b736f052dceb9d
5139 F20110403_AABVZW tian_j_Page_004thm.jpg
372d07a3d022f181aceccd054db91c5a
2cea4980b79cf19717142b951d5eb97cd2744ff5
1644 F20110403_AABWGF tian_j_Page_089.txt
88ea4f19c4e1c536e58f6ddbc3dd6b51
f59e701532171f3c6c40afb823873ee3473b1b32
1219 F20110403_AABWFR tian_j_Page_071.txt
8dd2ed0a2f6adc67cccfeab2e651086e
a8f32ab4795e3d827aea1d54987b8391806d91e9
1755 F20110403_AABVZX tian_j_Page_005thm.jpg
29312cdd97cb9a542030cecb337b19c9
06b9e9992782ac57feb94feac4c5d46174070195
2013 F20110403_AABWGG tian_j_Page_090.txt
7f0777dbb2e3788b4004241e9b2b0c91
22a60b2bbf730801c0328db3dd1385845b7fd042
1070 F20110403_AABWFS tian_j_Page_072.txt
33de74c1cecc45d199b37cbfef5560af
cb87df4b86c434e5d3477074356fb96b97225398
2785 F20110403_AABVZY tian_j_Page_006thm.jpg
208fbe07aa5c4ac510b0e326f611fd0b
848b8e2eedbcda3ee048c0b1782b73a807380058
1350 F20110403_AABWGH tian_j_Page_091.txt
adc5942b682d56c9ec0c93bfe4ce8b94
b19035dd22c3902fb67ede1e613b92a268d1d680
1631 F20110403_AABWFT tian_j_Page_073.txt
4d6562072c616e3358f41505a62a3da9
ac6e34bb26f58fb879e5e2b84fb8e5bd0d07338e
4298 F20110403_AABVZZ tian_j_Page_008thm.jpg
270f12f30e276c680c98a894ade60864
ee98c99aca57f56c978ed33b3edbbdd8e0a9649e
1587 F20110403_AABWGI tian_j_Page_092.txt
1a9afa5ca7988d8d9a73b182f6020bb9
675252928f1d7cd6ed544a8d9248ba1b140e2394
1740 F20110403_AABWFU tian_j_Page_074.txt
707001daf32ed0c4404a702c6e0b76a7
90d89af8e439d6c05ee1ba863bf3ac880f5c14ca
1067 F20110403_AABWGJ tian_j_Page_094.txt
41125a6bbb65268c7b2dd61886fd8f50
02e97b960015d158e1d9b7942b607642dc60fab2
1721 F20110403_AABWFV tian_j_Page_075.txt
f3c3d62ae11c42d9fc73393500d079ef
f5c65c75f034d0717ddf0b076a9884331946e830
1385 F20110403_AABWGK tian_j_Page_096.txt
a3ab1a1e7dc7dc6c86c7670a788daf64
80c53dd6d858b7b94b763e4cdca7a1dd6ac14c9c
1374 F20110403_AABWFW tian_j_Page_076.txt
e4e3a7e0aa0afe29eb77eef0071f7916
00b2a4d724bd45e4ffe49a2eeebd26c8835fd94d
592 F20110403_AABWGL tian_j_Page_097.txt
1bbe74d763d434a8f471a33e48169c96
a5e047ef04dc7d4c12566f7249b94bb550ff2c15
F20110403_AABWFX tian_j_Page_078.txt
73817e20e0a86010ef4d9a3cfeb1fd77
cfe3ae82fba03b6bc463352c95a198c391388b4a
977 F20110403_AABWGM tian_j_Page_098.txt
811c06f165b8bd5b9e460e9ca3ef42b9
a5a327f85b85226a323be9db95ce77a432e76c29
1762 F20110403_AABWFY tian_j_Page_079.txt
f86f198dff6f588cfa093ecb734bcfce
041f933c084fa748c0fdff3767e9c7ae8cfd56b0
43954 F20110403_AABWHA tian_j_Page_008.pro
4c3addbee93e398dda52e6601916113c
55fbd94da720b698c350a75fb023f555522577a6
1671 F20110403_AABWGN tian_j_Page_099.txt
7f7591f46d27e1607db4375187d6c878
c0ef76d57a4d241dc85a4f3fd0434790592908be
F20110403_AABWFZ tian_j_Page_080.txt
93bc283b1a4299be2b36520a1a6ee874
0ee170127ff5ea35fab1017b3c5541e388709a0d
35348 F20110403_AABWHB tian_j_Page_009.pro
919a287d2489e3ac7681aa260527f677
962ee05118a2a74b147ae28f3df35edd936cff65
1856 F20110403_AABWGO tian_j_Page_101.txt
5f0614b63438685feaf0b9eada996d47
6d3918bcb8f80a671073f71eb7aa7b6f17fdb24c
14648 F20110403_AABWHC tian_j_Page_010.pro
dc6e9cdfa97fea4c09ff57d711ce7dbe
fa2c7184400bda7c0edbb0510fa6f3c34c83a101
2273 F20110403_AABWGP tian_j_Page_102.txt
cb9a259ac243aa1b09d5d7817fa012f0
3eac439fc1b502322f4c7d0650c0656a65f20471
37700 F20110403_AABWHD tian_j_Page_011.pro
98ac31d01485ac5ae8f17dfd9aaca0c7
63ced6d064dc688858adc2edcbc44eb1d14bf591
2034 F20110403_AABWGQ tian_j_Page_103.txt
47d48e8687f526671ad98927e3fda010
a4b3f79570f2fe92b6a7ef44325eb116d62a098b
47838 F20110403_AABWHE tian_j_Page_012.pro
44ec39550340c24d0a40b51eef8195f2
549ce7e8df4c5687800dc137e6546abaf71284d3
1993 F20110403_AABWGR tian_j_Page_104.txt
9e0ea410a0ea13b62847925f2342071f
7d81cbfab45017cdb8205cc395e7576b54f3467c
48090 F20110403_AABWHF tian_j_Page_013.pro
5ce47b5204ae549529ad0fb08548090c
a66bae0ccac19e0b13a8cc2d1142e2e993f009ea
2531 F20110403_AABWGS tian_j_Page_106.txt
1b76e4b685b339504cfafa18ba008c0a
39052adca5b2c2dba49b9e1e87b5ca772e3c35d9
23523 F20110403_AABWHG tian_j_Page_014.pro
ea868ba8867d07ff9088b024ff0a6a40
0698f6350bf5ea406c59c3c045568a38937db833
437 F20110403_AABWGT tian_j_Page_107.txt
ded66610b5b9d626204db39625910a71
03637e39e799ec0b3f26fdd669a61e2bd52fe30f
33543 F20110403_AABWHH tian_j_Page_015.pro
0b49bc2c431d1cfcfbc40eca28217e73
8e77e53bee0d469403e5d0d7b047c391c00ab562
990 F20110403_AABWGU tian_j_Page_002.pro
05dc6387b8b37d33ff4a6f82023e06fd
2cfc16025f33e99723b75c18ff2f3da05297e141
32845 F20110403_AABWHI tian_j_Page_016.pro
0d5d73931de9031ad124ebc96337f246
2fcf1452abc0dc1ab62b39c6ebcdc599e5db0338
69463 F20110403_AABWGV tian_j_Page_003.pro
5bc705a94f2ac80bb947596fc26b2eba
691914e2e568e071cebc3f07f0c0b58a8b4d9212
34820 F20110403_AABWHJ tian_j_Page_018.pro
ce35119e771f3c95e5ae2b8af1138bd6
bec971373f543d3ef79a762d429b33312e7b4667
84249 F20110403_AABWGW tian_j_Page_004.pro
d20f2459cff07d71498b3ef84fb16770
a2d1c12f018b9e3937a3b26d99b1857fdbb0b301
58794 F20110403_AABWHK tian_j_Page_019.pro
78f05c70ba1b2ae66004b62e802f2688
304f12d859f0b0ec81c8b53a4ccef4f2bc496e97
17775 F20110403_AABWGX tian_j_Page_005.pro
1022aa08256daa96fef8a658aa3931bd
fbbc91916f4e7a8809121038f54609ce193944ed
59194 F20110403_AABWHL tian_j_Page_020.pro
f8cf59d282d6168446caf4376ea681fe
e2f0c380474304c5fb846288cec15d96c1f6e1c5
23466 F20110403_AABWGY tian_j_Page_006.pro
b334db54be7f32528ec4a4e50ef6a81d
cfad885b16d20b6b554273f762b5b892e76f2a99
42479 F20110403_AABWIA tian_j_Page_038.pro
012ddcd0f30f9dc4186c9f13d40c712d
9851478e910fa94427c715e4b2bad84436affe06
65485 F20110403_AABWHM tian_j_Page_021.pro
c9b0a1797ae202d9e64ebe1bfab6f097
fdf709e109240f8ce922f700dabca774a675d37c
48864 F20110403_AABWGZ tian_j_Page_007.pro
54ff12ae5db2aa2c8e66154d49a6a965
aef8fe65895b451e41be8ade6dfa0632fcdc5be9
44287 F20110403_AABWIB tian_j_Page_039.pro
540358f3989ee6e32e3234afe0d6bea1
c30736f99bbea78e3130637ebd21e136e883fbfe
48461 F20110403_AABWHN tian_j_Page_022.pro
4e9a93f55b7084a4a1cf29c0a97be978
3d5014499a85acdddad16f43c93f513a5f9fea2d
41197 F20110403_AABWIC tian_j_Page_040.pro
a36e0585be23d667ca079a72ab2d9bec
235cad3dd9f4a9df3b8be18cb14738654bccbb53
35181 F20110403_AABWHO tian_j_Page_023.pro
d62a77218b193838a5ed5e0a58fc2d39
7787427fa2b12134ac2b7a444996616b51e3bf62
46749 F20110403_AABWID tian_j_Page_041.pro
bc839b9032a599111316a9752a78b1e6
b107ee2920dcf8105a36d3b96fc5c7310ebe1584
47927 F20110403_AABWHP tian_j_Page_024.pro
607235b87ed374748ded0986572aec65
9b41a6797372ad13b0b80d99ffd2c572859c4eef
32423 F20110403_AABWIE tian_j_Page_042.pro
df99f96ecc46019775a301146649e025
805fad08bca333b68bfe33fdf13d799dcc4c7920
34561 F20110403_AABWHQ tian_j_Page_025.pro
ff00ec4592170e785d46d1b49118b695
ed720103bc6d81dda095c69be257629ce340a26f
44216 F20110403_AABWIF tian_j_Page_043.pro
7f143afb9bf27a4d370c10fd31ef20cf
07570606e6dbaa9e4b89d23fffbdda7fedec2334
40365 F20110403_AABWHR tian_j_Page_027.pro
2d25faf66d99db9b26ddd981d623260d
82642c63a954536249131d925e70b757f1f29984
40226 F20110403_AABWIG tian_j_Page_044.pro
7c02b29c961d2b200d57b806a973989b
9032938d7375add5a4b2f31d0b5f5a02a597de3d
47030 F20110403_AABWHS tian_j_Page_028.pro
fce4f915010e4ef0a6cecd946a782666
5f31a761575f854b27208d22decb134101281914
75996 F20110403_AABWIH tian_j_Page_046.pro
929689a4c2e7b659673f5a4a7b42fa12
438c496cd7ddccc8495fc873d39819be1060cdcb
44454 F20110403_AABWHT tian_j_Page_029.pro
7c60f26b22ecb0172a21368bf830d9a6
87a23d85539095439030ad4a53278f9e6e7233b0
48971 F20110403_AABWII tian_j_Page_048.pro
92b57113135254951ca89b2a3bab1ef9
8be85918260f799ba0a2fe9026c56d6a910af835
44322 F20110403_AABWHU tian_j_Page_030.pro
4ec41906295a57c33f70eafd7ed430c9
134247d7535ff958d98db417b063655feffcd821
28900 F20110403_AABWIJ tian_j_Page_049.pro
350184a8a29f2d524995fb28764bc837
cf079020040f28dd3b38a395ce9bb1aeed501e85
45764 F20110403_AABWHV tian_j_Page_031.pro
65e051b0a43582e8a4c1a2ab28b97d88
574f259f921ea292fa25b5ce7dbc9f4b6f9e4dab
46654 F20110403_AABWIK tian_j_Page_050.pro
647d924aff2295b536495a48b0deec1b
edc53ce6140dc168c2be55e1f6c8a3dac04387ce
40038 F20110403_AABWHW tian_j_Page_032.pro
ca6bfa6fd96ac250713633d997795f81
2519b38fd215bb9212468500ef307424f597daf1
36780 F20110403_AABWIL tian_j_Page_052.pro
ad2ed33d7d9765f8b99110cf6ca386e8
b1fc44161c465aaa0126a978b771ab1c2e53cec9
43328 F20110403_AABWHX tian_j_Page_034.pro
9a92d85bc19b9693db05b3da29549a3d
aece320e6354dd318fe7f23cba115afbaf6e85ae
28020 F20110403_AABWJA tian_j_Page_071.pro
5f52b2f471a7432fbdad33a201f64be2
8b910b27580b425583e0aa9ba6076dfa2ca29b58
41994 F20110403_AABWIM tian_j_Page_053.pro
26301f2c906fd51fd7ce43469e4c799c
0f6c34e50527c340a07ea7c1ca3b3bfc5f4b1c1e
47897 F20110403_AABWHY tian_j_Page_035.pro
c04378a52287eef3664ed8d78c5a03ac
aeb51ad0ade3e6fcf16c8e819061aa6ab5686596
23069 F20110403_AABWJB tian_j_Page_072.pro
70eb69bf63b6ee1bdd9c841927420e79
383cae267b88293f9ade89727721a39a22183cb5
46052 F20110403_AABWIN tian_j_Page_055.pro
6e90b9a5b064acb8b6a848c21b7825bf
7aab643fd62425f10689a8ba4516e7bd7b478790
35391 F20110403_AABWHZ tian_j_Page_037.pro
2cde91a1e128a99c0dcce6a4915f2730
2699d845b4e52b15654b1dfb48a9c4cbd602ce75
38569 F20110403_AABWJC tian_j_Page_073.pro
4f4aa83042f343ce4bb7173035d3e020
5ee783ea0b06ad0cf663b77fd485966176237f22
52821 F20110403_AABWIO tian_j_Page_057.pro
50dba1e22456e4b1d6bdbafaf9c3b9e7
2bd3c73d27e2e06c0821b89895b5f784c518fabd
43691 F20110403_AABWJD tian_j_Page_075.pro
58467d07ba40fc29314ed7ea563e356b
51f2c34e761f88e372c73804828d987d13acb2e3
7071 F20110403_AABWIP tian_j_Page_058.pro
ad78ea69c9b389a2dde4e4f6724225d2
0a46ca53594596c064b7976781aefce6e17bd91d
32671 F20110403_AABWJE tian_j_Page_076.pro
25768616e32ded2fbb66366c8de7edb6
16799b2bfd7f0cc616cb37a7c48e7d32650e0192
34375 F20110403_AABWIQ tian_j_Page_059.pro
529f695370d5d92bda9003eb5e19d810
a864d81c67f8467746dc7dbf6442b4022c50d15b
25319 F20110403_AABWJF tian_j_Page_077.pro
c3699b06f1b84eff61ea759f638c88c5
9cea9933f33e93871e13e36c04762b4c9ed5866c
34973 F20110403_AABWIR tian_j_Page_062.pro
d064ae7bd48ce6b909a14255a02a75a9
c54a16dfb21d7e8690603062893a8f059178e3af
31162 F20110403_AABWJG tian_j_Page_078.pro
791a40945898594f4fc8155dba9dc6fb
65198cf5532b986537a7ac2396fc48bb775fc621
24945 F20110403_AABWIS tian_j_Page_063.pro
5bb07bc313117f7908eb5dd724d44773
fb6f8ed5af401ffbb2f94143d16a92ff91739dea
43065 F20110403_AABWJH tian_j_Page_079.pro
8fbc19f2c0f36191af2912cb1ed00500
584d9ae2e134bb351ea018394ca851f00a9f4095
20459 F20110403_AABWIT tian_j_Page_064.pro
08d3187cf1134c63df4cd9e8d7597659
ee6ca06860d4354a4ff8c4339052613cca75080b
34979 F20110403_AABWJI tian_j_Page_080.pro
4b9e1938f61bbe8a6cc8cfcf4a136b1d
04c0dee0c89c9c3fbb99e8e1c0c7e70cba4e7702
17024 F20110403_AABWIU tian_j_Page_065.pro
0ca86ef42e5eb2b2c16ad4a3fef70fd0
87f787ff29bd424ed8a49a8004c91da6422456cc
20612 F20110403_AABWJJ tian_j_Page_082.pro
08f13db254912adb1e76a26c6852dfed
fe6cf63ca3a3b906448dd36925ed496bef5cbcaa
9172 F20110403_AABWIV tian_j_Page_066.pro
c65772f89baa92282a5cc4349de25378
3353bde0787e110fce10a0f01bcac865c7ce6db0
25834 F20110403_AABWIW tian_j_Page_067.pro
163b746313791ef3f65c2da6f261afe5
a24a28250e79ce75f2c6d5e033136b11f913f6c0
39894 F20110403_AABWJK tian_j_Page_083.pro
a32e51c4d5912a27520c44c123b226cd
000b14efdc4b50e3e2eac8edf8214d520ef12ae2
41436 F20110403_AABWIX tian_j_Page_068.pro
cda1747447d6763ed53e34f353361b72
9c6fa29a35113d891d7ed1c2b78823c66db6eb73
48762 F20110403_AABWKA tian_j_Page_103.pro
a8d17e1a0033b1b29102a93fb01de398
8546a43e2ab975c5589a99e868dd1f9e8e08c3c4
37190 F20110403_AABWJL tian_j_Page_087.pro
7d264fc221953031ed5a1b577c11a855
e4bd58f89621c602e1ae0c8a1888952aff3664de
35059 F20110403_AABWIY tian_j_Page_069.pro
0e0606aa6aea4c0de49fd429ace361ec
cead452c9cd68ba0c2ddd7ead9315dc4dbe0d47d
38594 F20110403_AABWJM tian_j_Page_088.pro
44395ab26730d152b9febe2da36c0dbd
9d6f55230577e3db541d6ca8f45f4e6b02af27d1
12422 F20110403_AABWIZ tian_j_Page_070.pro
169518f85c1a6622c2e0c8da20c7d514
c975902d5f373232dd92da934f0e8a60febab59e
47123 F20110403_AABWKB tian_j_Page_104.pro
2beea68488196ad7e88c35cf647b9a51
faadb0b6e633dabc1b8df53af3357f3a98c5d14b
39890 F20110403_AABWJN tian_j_Page_089.pro
4581ea445577729906d3e6554c992557
97ba6e4533cbab4dc56ff848b0f52ce467416af8
48860 F20110403_AABWKC tian_j_Page_105.pro
551167d629f0b1851214db1cf55f1701
cab6bb80a5cab2473f13da99a6b46ad8f8e0a36c
48407 F20110403_AABWJO tian_j_Page_090.pro
1b0dc0e4d33d0406f8bddfd4bc7d6739
3160825be8477b8205d58b8a73958b37b4f1c3d8
58772 F20110403_AABWKD tian_j_Page_106.pro
1983920e80cda6275ad5c877cea2bb83
d6d5b8895ad506322313cb12f380561f5ef2550a
28731 F20110403_AABWJP tian_j_Page_091.pro
bde3f005d815a85fd53d5e53a18e693b
a0a359bf6adac979db9ae60333fca0251a1eafb5
9693 F20110403_AABWKE tian_j_Page_107.pro
4a41d2487fcdc3aa6c4545f0a7bffe6a
88b089ad67adb52d877ba99fb206482d38ba655c
39312 F20110403_AABWJQ tian_j_Page_092.pro
a6d19819a1895e8edcf80dc3c09cd1ce
ddca6654d6984f8d4f82c7ea2e919aa8b9dfaa14
1606457 F20110403_AABWKF tian_j.pdf
f34ece4065dc9ee2659bc35d1a82643c
0ac5a5034e12e9244d110ab33f9882427042e076
46021 F20110403_AABWJR tian_j_Page_093.pro
cbb3d20758c12bbcaad8566552a25f46
32b81efc4c8eaab3b6380c1b06437b7535489c2b
125325 F20110403_AABWKG UFE0012700_00001.mets FULL
004783379d75b11cc4ddfe978277c955
037a52b9c9ac0869c616c0a7cd33288721570260
BROKEN_LINK
tian_j_Page_001.tif
22029 F20110403_AABWJS tian_j_Page_094.pro
3c5cf1966ded623aa1ebcb7854c647ef
d2c81e6f20191c10cdcd3c4cbc11724820528b52
55776 F20110403_AABWJT tian_j_Page_095.pro
a4a74289bff236512d19d7aed548c38f
36321326f191640bcd0d9f5b35cd8af7b5887402
28159 F20110403_AABWJU tian_j_Page_096.pro
b30a0ab1a7e1f736f7ab9c2e12a857c3
f078c60a0b1dc8b7482659a5a5dbbce6534b5f24
14158 F20110403_AABWJV tian_j_Page_097.pro
dde8741f6397f337809cc37cab4835c9
834302dba6c349afc8bdc9cbe7fed45045383aac
21162 F20110403_AABWJW tian_j_Page_098.pro
d4810b04cb9b1fc204d5f3907f4fd7d9
9bc90265d08583a41b80f30c8b980b03a82185ca
35646 F20110403_AABWJX tian_j_Page_100.pro
c5fe251f37367cdaae389cc7f9b055b2
66cd88f5cc6aa5e8c7a721142124f6bbd9a686a4
44098 F20110403_AABWJY tian_j_Page_101.pro
f0d81b4ecacaf7ed06c5bc0eeacf8b7f
76015f7733b7a6e2cbd8f62acb85f718f42aba92
29911 F20110403_AABVHL tian_j_Page_033.QC.jpg
ef957db9e839444d4d4bbbeb4c5f6955
cedbc9c9052b33014aca2c798a3c1fc2e9a0b303
54288 F20110403_AABWJZ tian_j_Page_102.pro
74014b27cb067c8747072616390e8d83
b52ed162fbcaa937d90484278c3515e47162af4a
1607 F20110403_AABVIA tian_j_Page_044.txt
493a364eca696339ba919d0839048ca3
808dc746733532d5aa7e1993237c66c9b4947ef7
1394 F20110403_AABVHM tian_j_Page_082.txt
2a51241ff73606a89413005d6066a395
2adf92e6f3f197504bf835d6190db00ce7125127
2616 F20110403_AABVIB tian_j_Page_095.txt
591431d50626fa9b653bac8d018aef6c
feef2c2e9e2b525a3a82d15b5afb532eb4138e9c
39244 F20110403_AABVHN tian_j_Page_045.pro
a4cabb0b49cd2d96c0cc4437a51809f3
14ecadf2e6d105a2b4bd72d736e8e76ba8c20fb1
713288 F20110403_AABVIC tian_j_Page_007.jp2
6903c368ca5b014d7bd8ceb59b9c42f6
39a0854816151c219707e13b208b31369caf1dfc
5226 F20110403_AABVHO tian_j_Page_007thm.jpg
ac8a2e53fa8e8b862e8c75e000290df9
c6d0ab24575da9c5eafc42bd0ea633f5580d8b92
33478 F20110403_AABVID tian_j_Page_085.QC.jpg
37dc9a1620ee7be79c0022757cd1df67
87b5e6c08d35b50847e5c02c055fc7def5e9435e
32794 F20110403_AABVHP tian_j_Page_099.pro
d4720041fb943ff806c8a8d50ac7a56e
fa5fbb463a2831f08def2124d0a0e14820c85b8e
46578 F20110403_AABVIE tian_j_Page_085.pro
566a0c03cf150bd0934762c77d67edf3
d113fdd78b2a2270ba8c375d793e1e611d0b1045
2071 F20110403_AABVHQ tian_j_Page_081.txt
9e26d40f1984e613ac9dc551d11a1f44
ce2d9b35a3ce42f8907e042480b46ba86c30cf80
1051943 F20110403_AABVIF tian_j_Page_035.jp2
154abe9f42888b0f3ee6345302d3415b
df5231feef0e235502cf4dee847f5148912a7eaa
87060 F20110403_AABVHR tian_j_Page_031.jpg
8592fdf5f4c5a0c35d65645dc9d29094
ecf315ce4ff70b4212e0ed30231e1b4db2261d5d
24629 F20110403_AABVIG tian_j_Page_037.QC.jpg
a7c99f49959b1e5fada883e32c309d7c
82188384a8add178dc50ecbf2a95943a9efc4325
19340 F20110403_AABVHS tian_j_Page_049.QC.jpg
086a71189614303749ead0dcb0e9f8ff
50f45429a55e4d821abe0daaf62e22d09d188c59
8224 F20110403_AABVIH tian_j_Page_035thm.jpg
4a1391deb481533c20146597b8f4955c
cfb3ff3008797f899310d9c72d6b49ce885eeb16
76006 F20110403_AABVHT tian_j_Page_043.jpg
cc78de9373f3725f93445bf2042db6a5
f44a931af5150a44683f4ca4d8cea18055b11276
8168 F20110403_AABVII tian_j_Page_017thm.jpg
b3930490b6914bf697371285e3c9a166
fd35f6a245b77c7c809124291d69e6feec1f79d8
20625 F20110403_AABVHU tian_j_Page_084.QC.jpg
98585b4b694772992221e4ab74511a43
e509da370f01be11293cc7ebba956a0f2d90f532
43031 F20110403_AABVIJ tian_j_Page_060.pro
ad698248028e4d6354ce36758544c31d
b563a92380687e4fe120c15303cf2cad9d377044
40169 F20110403_AABVHV tian_j_Page_081.pro
fa5fb5b2c1a0a1906f77b4cc405820eb
3997cb3e8b6306d0d13e6ec6e2f314530800c9df
8423998 F20110403_AABVIK tian_j_Page_057.tif
dccb5acf1b7c1d6e6eb58ffbfe0aae0c
d3c69b7d764ed4d4344360c5c33e6741ed4be0c5
66852 F20110403_AABVHW tian_j_Page_042.jpg
e4e8ec305a6d7f94af9874bdc5928084
6f4a80565cf94941ac099f1c0df02a526e97bd6c
18046 F20110403_AABVIL tian_j_Page_061.pro
6ab6f6d91ee712513ec8afff2962a10a
de40d85a438b1aa78ad6f502744d74b60012de45
F20110403_AABVHX tian_j_Page_027.tif
46b71ab4275fda0e6301bd4326d5f521
a0c840cf9cb495da4992f1b2e645cea94d856d7a
2851 F20110403_AABVJA tian_j_Page_021.txt
da4bc3a9bb51a61e7889448f07658ffa
08535fffe1750ac4af8aad9d2781f4446c3ec91e
33203 F20110403_AABVIM tian_j_Page_031.QC.jpg
b1e73a775af94c080e435ff1303871ca
0de0c5e4dd53ba33c1c324ad01e91fdcbc75fb5a
19159 F20110403_AABVHY tian_j_Page_080.QC.jpg
d2ed950a10026393c59fb025a5dbe6a5
a3fa7d37b6fbdaf57c94d0cad8cb50e41c3db8a0
F20110403_AABVIN tian_j_Page_039.tif
8f6d362a7259520f688c0fa0a70f60a6
b98e13b6c094d2a6ca1a635eb7482b8c36561ce6
1751 F20110403_AABVHZ tian_j_Page_029.txt
f1ff1e416076d3e797ecf7e8f4216e6a
f7a53b3610844fb0db9da1ba7eaea99d4890c114
910754 F20110403_AABVJB tian_j_Page_089.jp2
45d00ac25d96aff246a97ab556678914
4293f9325076517812dc48d3521bb7f6f4b41eeb
899847 F20110403_AABVIO tian_j_Page_045.jp2
d0967417e3c6122374e3ad8d16048e54
f42761f672bc0b553d5d85385f2e3c73f78cb794
32847 F20110403_AABVJC tian_j_Page_021.QC.jpg
83f15fb861de6e9511aa5a83cbf84804
507a9e6278493f91b858968aa157877cfac97547
44147 F20110403_AABVIP tian_j_Page_014.jpg
a88164b89feb9bacb3f636ba11883e8b
baf6e58d234454714df20b6e16d75f5c374443ee
44746 F20110403_AABVJD tian_j_Page_054.pro
8d4d46b0bc9e021319308ed9e20cfa98
136d4253b9d0ec96f0c8c8bb14fb857e47594be0
F20110403_AABVIQ tian_j_Page_014.tif
3a271cf53f594f5f4885761d730188a3
f6162f06f87b9b5e36b1fc8265065648432988d3
5501 F20110403_AABVJE tian_j_Page_094thm.jpg
9ee3b92a4b6b30fa159d089a749e87dd
7a1ee7cc1d17bbe40010541774eb4f5dfa47104c
235651 F20110403_AABVIR tian_j_Page_107.jp2
25f74961d621ef6fc68667714daa8ebf
af45445237a468d70d66000176041c1ba9bc0c5e
677905 F20110403_AABVJF tian_j_Page_036.jp2
b516a97c4861e78157474f5075b1fed5
e284af1e74b394e6d71a1ef28eaf9f585e628445
F20110403_AABVIS tian_j_Page_078.tif
37cb77e67d5c3c2f22703a56a57b72f6
c69ca491d06dcd2c26e4ef179f95d6ead2aceae0
83084 F20110403_AABVJG tian_j_Page_073.jpg
de3e87a39552c71e786c5dfc868fa714
aae20cb08a6a8a0311ea0cbb64642f28ea8fcfc6
30654 F20110403_AABVIT tian_j_Page_084.pro
015032bd0f987a654fbdbc4de823c438
53275b5ce684ebf823e8689313d3695e5e975ed0
31408 F20110403_AABVJH tian_j_Page_036.pro
437e7988cefa885f3f7be9183550dc12
d0f3f7e89c4ef7d241ee921102a92eedc4922765
92058 F20110403_AABVIU tian_j_Page_048.jpg
f4fddbc319a96b2ccaa07fe6d684bfc3
42a873511db4958e8884ee2250ec3045cc9b7792
66939 F20110403_AABVJI tian_j_Page_037.jpg
fc1be7be599155c6b0d1fc4e55977cc0
f7e197bc4d885c99a33d2f1078c9aaf1df56dd50
329707 F20110403_AABVIV tian_j_Page_082.jp2
71e33db117b70030dd5058493749429d
bfa08d6e5aa413d0151e4e76a00bf2f0e99cff64
42042 F20110403_AABVJJ tian_j_Page_056.pro
666d9ab893686a049d879d36bed1edb6
855e03e5a91db56a00f333f61c28ca8e8cba7243
62118 F20110403_AABVIW tian_j_Page_047.pro
40bc23544708a65a6a8d9d3661fec355
1ff23f9a7cc0611bbd8255e060040757305e91b4
72137 F20110403_AABVJK tian_j_Page_015.jpg
deb4621c91f82168ef111b3b6c667f4a
f877ccd2e50634d5cdd08f761226e032d0339e7a
784120 F20110403_AABVIX tian_j_Page_084.jp2
bc0e98ea1c59dd819aa02816000e2c67
366079aacc00d5a9fb31cf65f8f171bd4f928598
664064 F20110403_AABVKA tian_j_Page_099.jp2
fca49c9a8aa06a0e77e8a2a960d577f6
a239153cd23ff757944659b8c25acb2a512a2dfc
26163 F20110403_AABVJL tian_j_Page_052.QC.jpg
b3dbec9c5241bc4fbb84e0a2962fcff8
aebb6a2233a5d5399c766627254556cae2b405d2
737508 F20110403_AABVKB tian_j_Page_076.jp2
dbab5eec1f7d358617ad18c8592d41d9
0081e290b83ceff97ab3dcb480826e25add1a8e4
2102 F20110403_AABVJM tian_j_Page_001thm.jpg
032ded7e2150bf1fb3a1d0dbebf94655
b49f3f7f6fa24634c482799bf1b64ed365cf262f
47728 F20110403_AABVIY tian_j_Page_086.pro
00e8091f44f4e8139ecd108254882490
b413f8e9cbe6403939bbed17a0c737612d76b548
2070 F20110403_AABVJN tian_j_Page_105.txt
e938a9da99035e445c5555a33fb68c81
3ce12a451043e4149659b0ebdabb7749fa7a9403
34338 F20110403_AABVIZ tian_j_Page_086.QC.jpg
28c02a8562b50eed7aac7f3b3b6d9315
ae4cf92fa8bda60f3dc652494d9f2f871e1cfc7c
6728 F20110403_AABVKC tian_j_Page_078thm.jpg
279debbdadac49043534856d7a40b51d
43bd08f5cad1259316c76df4550bcb56c62c3ce2
83109 F20110403_AABVJO tian_j_Page_079.jpg
fe141ce12b5c32eb18302d040b5279be
587e2912645eec76c68388977293efbbfb5e7530
1817 F20110403_AABVKD tian_j_Page_093.txt
4421c9333c83228f4b5021c535f6e2e1
056e354a4d035ef48c93d47b8c96d55c5e3b118c
951232 F20110403_AABVJP tian_j_Page_053.jp2
9f046b5669eb0194604b69a69d001dd1
ccf39b4c19e01964d6af7a0da690127b3923df4e
20136 F20110403_AABVKE tian_j_Page_018.QC.jpg
75aa99142c7c1e2474e2d8915defac25
b53a8f79d21a062792e7e8312cc0b6849396c8d4
717826 F20110403_AABVJQ tian_j_Page_069.jp2
652afaa2e6c2c66e7ec861842401cb53
defd0ca8e33909177e4057a722acf33875da23a6
6534 F20110403_AABVKF tian_j_Page_001.QC.jpg
7a988a5a77a02cc5432b6355b510ae70
ae9be9e8dfc02dbd5ae5ea7dc0aaed6da8580c8b
26458 F20110403_AABVJR tian_j_Page_041.QC.jpg
8b13d8122c9b0f924a7ac0d41b85c058
a0f373266aa771ed5d4762037602359e8fd05ce4
7872 F20110403_AABVKG tian_j_Page_090thm.jpg
e15bcf5cd0e81340bde630ebc85f5eb4
aef58b686bb9903903506b082c405f3444aaf6f9
89310 F20110403_AABVJS tian_j_Page_039.jpg
c2d95c932ae13303c8318ca79c80f89c
41942ba1061c14a6034a1a6ca8ec4e29f8324900
7494 F20110403_AABVKH tian_j_Page_027thm.jpg
4a0e6e94bd317f1a1f43b2c97438ba93
cd632fd912c46cfd8c78e5972e09de351b1fc723
7861 F20110403_AABVJT tian_j_Page_075thm.jpg
f3081b6567d716691966e0b275ed2929
d6d3a85ed0e2494a8d68ad3deff911abbd72b024
978 F20110403_AABVKI tian_j_Page_006.txt
352e8ce651ab7065dc1d001475efd3d3
fd5e9b714d8cefd258a45df67511e8764c8a9531
29060 F20110403_AABVJU tian_j_Page_032.QC.jpg
1cec570cc0c25316eec59b1eb32cdb7c
8bab97a248e8759d5346d99e67137e58b8c6eb94
1347 F20110403_AABVKJ tian_j_Page_077.txt
e9e64fef2243aacb2a868a6df6968b10
dc5c025893dd7b7d533591cb4fba335d1ccdce45
45970 F20110403_AABVJV tian_j_Page_051.pro
30df29146ca7a415b885fca556658577
e43eb957a62752164f061c37b9f6ad4fb61943b0
968515 F20110403_AABVKK tian_j_Page_060.jp2
fdea1bec8eccdf6dcc44bf947f9c8aac
998ba6ad92d442b2b0e454c6b0b3ff0c2756c824
6815 F20110403_AABVJW tian_j_Page_101thm.jpg
0f07b2cfcea5949bf9819b3924193e6e
2af7acc6e40d77c7ba29d4c68cc0213f6f786c7c
44189 F20110403_AABVKL tian_j_Page_074.pro
ec13b146af59678e745100e94b5e3074
2f0e6155d77a088e0d349d9b856e0f9b74462ffb
45130 F20110403_AABVJX tian_j_Page_017.pro
7ea7e51ed66b7c244a08428ef504440e
660a54baab009ef2ec985476b2a8ab12600f2aba
1051894 F20110403_AABVLA tian_j_Page_020.jp2
29ca9ca8d3df617e207bb90e932fc6ec
83ef7474eb68570c316836e9e85ff2c394f1d48e
5464 F20110403_AABVKM tian_j_Page_071thm.jpg
7cdedb96a959f4a441447c27464a9e9e
3a45938913a095fad8bf5df930bb2ef758c91f25
7057 F20110403_AABVJY tian_j_Page_084thm.jpg
e4dce953c564b035e2f8d8693e2e8846
0ac9db89476cc23cfe0df3d06a61f5600725aa1d
5166 F20110403_AABVLB tian_j_Page_097thm.jpg
4cd8c3f34cf179b0e270d1ece2d646cf
6197e3cff545a48583481c549e6ac2bf5e56b4fd
64607 F20110403_AABVKN tian_j_Page_036.jpg
511e49e1de078bde61052de4a6e68347
444bf0e17348276885f5effec52e29c612e8a82f
F20110403_AABVJZ tian_j_Page_098.tif
7a6b7a71b279a95d838e45a0c1e7eea1
e39e4eadc833f57fc4fae382db5dcc4c9830b6e8
42620 F20110403_AABVLC tian_j_Page_033.pro
c96b93ffb729ba7e66e8bc350d049595
f38c5b93f67d73a1a7a8c37156b8f0fb3206733b
909894 F20110403_AABVKO tian_j_Page_092.jp2
916e906b39cb59ce98af4ab0ad77b7b1
18ab999c8865e50e7a420bb32200a1b865f3fc28
36933 F20110403_AABVKP tian_j_Page_066.jpg
2d01ddf80c0b7fa6123b189a1ff18040
253da6cf8fea68784a288e8a798111f3382619b4
F20110403_AABVLD tian_j_Page_020.tif
4d2be4f93ca0f6b447b422069e2be369
a66924f2c77214f2bb682c0506b580dec69d935a
322 F20110403_AABVKQ tian_j_Page_058.txt
139e053d012f293bdddb32f0736b3670
49d3be7ac3b3a22326d132275e56159dce6a4491
18633 F20110403_AABVLE tian_j_Page_064.QC.jpg
38bc5845f562d15e0ae13cf1b84a2aac
398db1dfb80c77ee724cd9116cb2aaf0c0f67237
1827 F20110403_AABVKR tian_j_Page_085.txt
7a4306a2b765cbbb3f3c6374bfe6de43
36327b95087992869fcc9f8f3af3370a99e09c47
91007 F20110403_AABVLF tian_j_Page_041.jpg
a23f0fa63603b5815745042ea86d46be
7a72a80975f72ad36ac6b238d0cd9ae8ded28ab3
44535 F20110403_AABVKS tian_j_Page_026.pro
e7f320c781300863b29998573ed03ce3
4bdfd2ce705a89390e9a310c694e434d640e1592
2310 F20110403_AABVLG tian_j_Page_043.txt
b72f1a0a45bd6b2f0926864fede5d582
97927bb597277d0c516ab7005fd968fc058dd913
810479 F20110403_AABVKT tian_j_Page_037.jp2
5e991bc2e422d96cbe0a5ab4f900c15a
148f5b0388b36a81bd9b8c0cb114694e4a736b7b
1480 F20110403_AABVLH tian_j_Page_100.txt
ec169465b07301c186a1f6cf9063ea5a
6caaaba282d708692506c4866851c7bff747d368
F20110403_AABVKU tian_j_Page_073.tif
6eb626fd67b6208c0742af04178886c5
e1aa65801476f5f4610b22ed3b0bee040a49fa28
12257 F20110403_AABVLI tian_j_Page_070.QC.jpg
f69e3094d66e7360aefc903829d9b1b5
13efab72f16ae219882b23310a7c425405a67b3d
797331 F20110403_AABVKV tian_j_Page_043.jp2
7a840919795f1f351cb2974760238cd8
2e5cbf94c95c8f5aa2e9e8085454acc8b13b1fca
1885 F20110403_AABVLJ tian_j_Page_013.txt
bd4aa58dc0044345013f86f1cce4f362
1e19833bfe64871edf762587f694e6218d842999
89452 F20110403_AABVKW tian_j_Page_085.jpg
c529abd357081371ef0f1c5418a9da92
47aa809113550854cfbbbfd3cf8aa83485b87cfa
35426 F20110403_AABVLK tian_j_Page_057.QC.jpg
72ca131d4aa1d355454b74b5f9b29290
094c51e4ea104fe4316c150058fc0c6225ef2dfd
8237 F20110403_AABVKX tian_j_Page_085thm.jpg
bf524c6d212067eb27e044e2c90b729a
150ad92d7143a77f9b6fa2e49520cc7684f28fee
F20110403_AABVMA tian_j_Page_006.tif
328d71c4b57bc7939bdee3b0026e8d24
2fd0bbc6c3647beec9a46a99c468b97d2fc97bf3
63129 F20110403_AABVLL tian_j_Page_096.jpg
05ab270f0132c42590dcd8de7338a744
7e253b593fb441d6c61c1f43899aa1422e1279c9
F20110403_AABVKY tian_j_Page_053.txt
94790ee76815a79facab43c082143ead
62d05fe1b1b074a9d8e3b56106d8818d95c0ac27
F20110403_AABVMB tian_j_Page_007.tif
e36f406ad00f7597d772a5e112f18148
d04171d9704f2f2d21a3a532726560a869082dcf
33092 F20110403_AABVLM tian_j_Page_050.QC.jpg
530a871421529552c5f2c14b199234a4
cf8a534f16e1a762d8eeb7bcd428037e06e96039
22365 F20110403_AABVKZ tian_j_Page_083.QC.jpg
1c0fc687af43a1dc4362e6812216c917
55c4f92fea1da2a20e0e7c8e8dfec43ba09dc0bc
F20110403_AABVMC tian_j_Page_008.tif
2d842220ee977e08ecd02574ae073a22
dfd09e6caaac5653328f6101bc4a4b02de84f9bc
869190 F20110403_AABVLN tian_j_Page_016.jp2
a8c38db19ed0c9f4a8c68e07d5c0c8f7
a5db08d130d1492092e79c8a3f070f7437fe1d98
F20110403_AABVMD tian_j_Page_009.tif
96813f4901ff145ad6734f01becf274b
77acb331df05019521329b893902b8e7bcfca01b
7501 F20110403_AABVLO tian_j_Page_032thm.jpg
d2f81edd82f2bcfa4ffac5ace52b263e
f53f8509a279fa205abc75b6e5afa1820196c557
29056 F20110403_AABVLP tian_j_Page_088.QC.jpg
2af2a8de0e82cdf387da0876d7df9edd
8ee3b1af5cccb28a779f5b8937ace69d239e22a3
F20110403_AABVME tian_j_Page_010.tif
a8eaeb9689df5a08c7b4b343f8057ee6
8d9b0a23a8d07a78402e0caefe73318dbf8fc4c2
F20110403_AABVLQ tian_j_Page_033.tif
f763f57ed3a45812b3e805984f5533fa
ce48becc7d6b15e65899652202aba4dae751b0cc
F20110403_AABVMF tian_j_Page_011.tif
bc30da374200c8d8c60a4c3e54c647e9
1ea4cc3be19a2cf54a7abc32ff1ebfde7ea2306d
86160 F20110403_AABVLR tian_j_Page_038.jpg
0f8e297eb1b310d96facead34441c0c6
7d298c1aea35960e8c5501a27ae0fcef3486b7ff
F20110403_AABVMG tian_j_Page_012.tif
cc0280db273e2e81883d4bfdf3461423
4e538f2c66f059fd8bf926fef4cc6551a492ee87
92991 F20110403_AABVLS tian_j_Page_013.jpg
053a7beab4037c31a77946ea59f67519
c978ece5ce56d1541d294a4a1f86d979dfdd5829
F20110403_AABVMH tian_j_Page_013.tif
4080932441994278ea5587585c291b9c
bb1b9852b7f8febfc20ab98421f726b6c3075995
171122 F20110403_AABVLT UFE0012700_00001.xml
bffd5ea732e69506683f02cd0fa79940
218cfb59b6952b26e133645808d66de765cd2189
tian_j_Page_001.tif
F20110403_AABVMI tian_j_Page_015.tif
736d8b5de062631942e92de260d77542
f3c2cbd0c9e8df600ab7e5691ed1bb3e9533b5ca
F20110403_AABVMJ tian_j_Page_016.tif
052f8eb01475954a6822ddbc68a9a236
a3fa39636d70244c3fc2ed3cadc588c95646a25b
F20110403_AABVMK tian_j_Page_017.tif
ed03e465b1fdd36135dcd4828262b7ab
bc1d57c5a54492955a6cc379e5880d3b3ef8559f
F20110403_AABVLW tian_j_Page_002.tif
4ba78a2ede52de88946db71ead2da435
c1918a858e5cf1188fc0fe2719fc039c2379c366
F20110403_AABVNA tian_j_Page_036.tif
f7db7aa654e2bcb6eae4a5652d2d298d
2ee2402a20f7b73bd86a41df6c7547f4391ef5f6
F20110403_AABVML tian_j_Page_018.tif
140d93428e2e662f29e61dd6d1b609c9
74fd9b807f879a94369465dd43fc48c97751e329
F20110403_AABVLX tian_j_Page_003.tif
645d0b051549cd13dd0832ecd8458d2f
b113f653542da9a0e476b46b11aed13a018dfcd0
F20110403_AABVNB tian_j_Page_037.tif
89f7af8c16cf4a83dec6c77a6269019c
0db0674b8d07110c86e9312b20266fa5e021e87a
F20110403_AABVMM tian_j_Page_019.tif
3187062e17cb97c1ef514ca8e42a1777
d41c0eee3ae2374f714b134a7aea142d97b2a06d
F20110403_AABVLY tian_j_Page_004.tif
dcea8f7a3d7a87ce5643d40894cfd19d
aaee9ba4c4133a9086c802e475505d69974e03f2
F20110403_AABVNC tian_j_Page_038.tif
4427c1a50d26d417c5f05741a07c328a
507a3f316687fe50b6e641228211709234ea3f9c
F20110403_AABVMN tian_j_Page_021.tif
521fb5f70f4ddc5f8e77b998599aaec0
c6e5fc30cd4cd093b3e2fe2a97ad382576449258
F20110403_AABVLZ tian_j_Page_005.tif
57972a3f3e28cfe53d22b894ea555a5c
2ac819fe57dfd91be1932523854982cc2eda9003
F20110403_AABVND tian_j_Page_040.tif
db300df327735cf53f2ded5fa50576d6
1c5d0f6c75e591c5c3fea325586670593c3bc0e7
F20110403_AABVMO tian_j_Page_022.tif
90d6793cf6d4ee1894bb6cc242b6cfaa
ca36af79853684d742aee50f2a74075f1eaaf81f
F20110403_AABVNE tian_j_Page_041.tif
70777ea03758d58bd82464233b6e5619
2195f50c942ac7362079e2aece08cfca47e73a52
F20110403_AABVMP tian_j_Page_023.tif
38ac971e2ca4cf38e3185f86821ba57b
1b93ff5e985009f9818e04d5bb23e4eeabe47c53
F20110403_AABVMQ tian_j_Page_024.tif
a395b75747b561a9a5f860bd0eaab946
c485dbe149462062684a68e5f663707c0bbe365d
F20110403_AABVNF tian_j_Page_042.tif
77eae86769337908335cef73498ccb25
11b436a56a1a2ff4239c3145c80df3a1460b4e8b
F20110403_AABVMR tian_j_Page_025.tif
06f836934077686021b35afeb7fa244a
0940e9bf80793535d3d886844680ad8063548278
F20110403_AABVNG tian_j_Page_043.tif
4b4914d4eaca36009a6a3d2ca6a3bbfe
c63a92a9f4dc0fb8d47b31ce837f548ade9b2cd0
F20110403_AABVMS tian_j_Page_026.tif
d90227e4510d3ca272a7f4f47598063b
139e40010633fcd03108e3b9259eb9e3f553630c
F20110403_AABVNH tian_j_Page_044.tif
01d57ed118593f76fe2ab6870f9e094c
21e9271c6d8b623eafdc03684606dda6505f46fe
F20110403_AABVMT tian_j_Page_028.tif
97688b81b46ce3f8a9ab02a57acf3a3b
ed9cada973a3a48d353bd427e942a61d157aad48
F20110403_AABVNI tian_j_Page_045.tif
1e4033751cfefb8a59ab0c1d29235147
28097aaad3a0d49c87fe0f44ac57b25d280d0c83
F20110403_AABVMU tian_j_Page_029.tif
27cc0da487760f56ab87e958ee165615
ae9d06510a4dab527407334affc90b71f3af2a6f
F20110403_AABVNJ tian_j_Page_046.tif
b1dd63e8cab724f439f595b259bf66b4
8b620ceb6ccdb434cad876543ea67416593aac0d
F20110403_AABVMV tian_j_Page_030.tif
84f70393b9101a142f06314dc115e347
fff48450a60a188d2052c6e1f0c602019686548f
F20110403_AABVNK tian_j_Page_047.tif
cb31f0176dda907390198cdffbb1d356
123232931d40d5424ec10d2550db7113b13439cf
F20110403_AABVMW tian_j_Page_031.tif
8925cc80753a8e624ffe94a8e853639e
bd25d30a677ddc771b0364a36c9888d952f2e98b
F20110403_AABVNL tian_j_Page_048.tif
2601b945275e14c74f69cb126068d8da
a082ebcaa965819e2c5bcda8377489f043fc3410
F20110403_AABVMX tian_j_Page_032.tif
e98f3a1c191567e3814561ee40aa0d31
ce89c0a72458b4194b1b27a28b9d008bd1bd1bdb
F20110403_AABVOA tian_j_Page_064.tif
69c93b4e715fbd58c8cfd8caf903668e
f245f9ab6c558d9040973e33938730cb648d8e2b
F20110403_AABVNM tian_j_Page_049.tif
617967f3678108906ff8a5e88574f93b
952009b6e1bf80ae08c335be67ed48d58b3ffaf8
F20110403_AABVMY tian_j_Page_034.tif
5a477be3c0fd73c303de3c45b2168997
08f2d960dfa60a904bd0733f5e40809739cd1c29
F20110403_AABVOB tian_j_Page_065.tif
bdf359fc29c0623a0ded6b19baa5906e
044498f2ae2a8401cba14b224b94c4b92ea9e788
F20110403_AABVNN tian_j_Page_050.tif
5383c2856bc599d67a50d0730e72328c
c7b7f2c26d859216aff1585e4404defbacc0143b
F20110403_AABVMZ tian_j_Page_035.tif
5f71c3544621570340bac53c086a53e6
4d6a3c020882a608a1ded63728f3e338286534ae
F20110403_AABVOC tian_j_Page_066.tif
bdf94cd7b1eea2a3e6a4a882be885b2e
0796ee267ee2be7c7c151a12c693f1222852c7ce
F20110403_AABVNO tian_j_Page_051.tif
5edf3e5e06faa88a1f3cce94e8d9694a
586f46688a0b5287554eddab9891edb81d1eb912
F20110403_AABVOD tian_j_Page_067.tif
d911098f4cf48327bc7a20e55a3b7b3c
c8738de442f5ca50ae583d84d2d59339320ccb37
F20110403_AABVNP tian_j_Page_052.tif
584b45b4785279d0c97cabb12a537172
2dc4c5dd5bfd94e348ebcf6ab7b47665e4b1fa07
F20110403_AABVOE tian_j_Page_068.tif
605413976f19225c0850c6a75fdacf9e
77ab6bac675ee862e818dbb969015545c6ac7cb1
F20110403_AABVNQ tian_j_Page_053.tif
e355c6626eeb3d3cca9500621d1f7fc7
fb4eb80c06898b77a66adaa810615fc2d4f6bd10
F20110403_AABVOF tian_j_Page_069.tif
b621452a517b7f1bab3a7483ae412300
e5aecea8d220d6fe60841ec7c1fa004119bf004a
F20110403_AABVNR tian_j_Page_054.tif
a81c466dc058e9a7a95717b40666fb8e
48f7659241966ded797221d7f1a9cfc70a9bb3ff
F20110403_AABVNS tian_j_Page_055.tif
c336a565d067877d56c8a36be18ebc0d
2d3b0862e73c8af493ce707a694b354b0ebdeca0
F20110403_AABVOG tian_j_Page_070.tif
2338baadbb36545b39fd2e0776cc4ad3
659388c24361aeb75e4e74ed86a88920d2ff94cf
F20110403_AABVNT tian_j_Page_056.tif
0b1c9acd13f0748159466ec004f6d427
ee4643602d721d239196c3ee0d76ad4d2e676b6e
F20110403_AABVOH tian_j_Page_071.tif
8a0986623e3fe4677a276ef590152b3e
9e95f64f713db615c41feece829e037549608f8e
F20110403_AABVNU tian_j_Page_058.tif
617036be903786abfff1b5164af040cb
aec68a01d6aaff46fb76c41ed3753561dfa5c1da
F20110403_AABVOI tian_j_Page_072.tif
8e3d5b23ae95c91738402003233d9091
89f61d23ce0043a66a8ca9c4146503b71a8cb76c
F20110403_AABVOJ tian_j_Page_074.tif
b328e90d696f775c585e57c67c2787ba
9c3e5875d23fbb39cc08a4b24354a1ee4ee78af4
F20110403_AABVNV tian_j_Page_059.tif
30fea06021bd2b19976ad282cdbcdad9
4becd5a6b4e2f29870fce874a6f2617dfd15c1a3
F20110403_AABVOK tian_j_Page_075.tif
925ffc93f4e30c59e8ecfe324262b589
dbf4fc7ba0e478981d6133ce1d7f543bab73a1d0
F20110403_AABVNW tian_j_Page_060.tif
02fe511099295bd97602aa0a05c71f89
b47e2950d8033018aefa7a2f3ecfa5bc14531862
F20110403_AABVPA tian_j_Page_092.tif
86bd0bef4f15bb49cdd07c16129fd4c8
39b5aaa89eb55aef59919a9bdd2af9b9dc1cf095
F20110403_AABVOL tian_j_Page_076.tif
65d191ff1abe7659f41a34ded43c1ed5
6721457ac38cc5b0c8544981e1914d1483279c60
F20110403_AABVNX tian_j_Page_061.tif
5a82f1f6d34eb97d9599ef0816fc1dcb
4dc7d2f3f2d380fce76f87d83da50c15462cc937
F20110403_AABVPB tian_j_Page_093.tif
cab6db8bbdb324498262ff110053208a
1b88271ed936345059d43aa9aaeaa44be12207fe
F20110403_AABVOM tian_j_Page_077.tif
3e9359d516240d590d93fa193dbe8493
4d2fa533512fe8eaa8ebe80e1fd399399e3d7b8e
F20110403_AABVNY tian_j_Page_062.tif
bb39d06277814e32b0d4fab373cd8561
d8bcf7915ad9ac0188b54e4541a04b808849f97a
F20110403_AABVPC tian_j_Page_094.tif
bb6e0b674f905c73c0e5153df1022550
19a3c9255164ef8d8942bb94e4468b9e0d911d00
F20110403_AABVON tian_j_Page_079.tif
11ce21bd93f4dcd8c05e19a40f743aa5
dbc45d414df5720e3f1a0fa9619f54a06f03a8ca
F20110403_AABVNZ tian_j_Page_063.tif
bc1e26eaf448d43c96f35739f0a8ff8b
bc24899192d226bbb47b1c6788a2c536b876ee72
F20110403_AABVPD tian_j_Page_095.tif
af58b46233296c60bc91b359ef7c1ce2
fe2f6d35b59dcd2df083adb76b09c9bba3d3db6f
F20110403_AABVOO tian_j_Page_080.tif
6bd866907b324bafb1a85bbf45e6ef17
adf8078e9859f8a662773d8ad01edf79bfaa4b65
F20110403_AABVPE tian_j_Page_096.tif
88310a2ce38d6518d725a0b463e3a164
c48364778934db25aafdabd3f9cdac8c4342d2bd
F20110403_AABVOP tian_j_Page_081.tif
3c7238c777ce88e4b3ca8bd08dfc01d3
ee98ec5d387b2cd486546f0eb5c62dedcfe0279e
F20110403_AABVPF tian_j_Page_097.tif
f4a4c81da3e27e89067c4fbd879c0ca8
df9ec6730f6e67aaf0d686583d004f5b16873123
F20110403_AABVOQ tian_j_Page_082.tif
1399eb722a4619f623ba81328b8cf429
225e31ec0d9b3e245414d66ce2f299d992a4de14
F20110403_AABVPG tian_j_Page_099.tif
a08186e8119cf1f838010b125e77a7a1
de916df179890fad2f0ad2c1fcec7bb118bfce09
F20110403_AABVOR tian_j_Page_083.tif
25657b094b1fcda1b31777f1fbcc762f
a858ee1e9a1c222657e5d1d2640920b89cfc75e2
F20110403_AABVOS tian_j_Page_084.tif
3a584026f8b578068dd226be9e7fb979
89a053583c239592313a3979b34dd64db3fbb453
F20110403_AABVPH tian_j_Page_100.tif
570e8ad728cedbc2795702fab1b2aa21
8c7d1ad0697d871aa9966b4538f2838f47db3eda
F20110403_AABVOT tian_j_Page_085.tif
116cdcd508778ec6465fdcb5f74cfedd
4f94dc1456d1b15ac56c9f24b21a9fc0b02c54bf
F20110403_AABVPI tian_j_Page_101.tif
69cadde0fb784cd2a454beaa54b541a8
6f1d8144f62f0815158156731821fb450332ff6b
F20110403_AABVOU tian_j_Page_086.tif
814d442c6053ae8907c3ef5385153cb0
e9441808032ed4274e5d8e15a3c63aebb9516d88
F20110403_AABVPJ tian_j_Page_102.tif
09a9dfa59df6e1ae618b7214c8af33e4
60f5492887ea6f168e5940c7e9e2a4afa12050c5
F20110403_AABVOV tian_j_Page_087.tif
5b24fe53b563126748e38139d7b53e87
7142fa0f5e6851d9c0d98eed8c7370141b6c9b08
F20110403_AABVPK tian_j_Page_103.tif
72654d22478cfcba489459a0134e35f2
ca5a7638f38076096f64f5c3278bd8dc5c9e942b
F20110403_AABVOW tian_j_Page_088.tif
a5c818e9b64392513efd93b9a05e3416
fc95418a56365d6009aa81b7db8b16fcb5eff46f
F20110403_AABVPL tian_j_Page_104.tif
527eefacad8d39f69189e2ba3aa2131f
2a86e98f6578320c3c4f7f7809acb129a9eae2b1
F20110403_AABVOX tian_j_Page_089.tif
988252ceffd188c2ea369fb916082b24
b6fcbfc8426a47e814451672ec5fb431872a8805
19552 F20110403_AABVQA tian_j_Page_007.QC.jpg
e7722ca74c1d3f5bbcc384a4d3abd1fe
d1a9f55c5e0f7b9c925bf6a4f8bdbe768acd1365
F20110403_AABVPM tian_j_Page_105.tif
d92efb65e526a9186bc23a6030d4a7c7
3cf8bd6951bad33bab9ef57e16635477111e3edd
F20110403_AABVOY tian_j_Page_090.tif
d9a5bb45ba62d02c1bcc9ece2e2061c5
b9183e22f6abdf35067aaf023b014f615738a4d6
54989 F20110403_AABVQB tian_j_Page_008.jpg
0bbb78462b6404477194e5c02e9fce43
5ccb008963fcfb8aee993e7ba0040aa6cd597606
F20110403_AABVPN tian_j_Page_106.tif
4f132bc342686d433287f605b9661c97
aaaec1413363866dd20ee0f511f952ac474fbf8d
F20110403_AABVOZ tian_j_Page_091.tif
f15e89730f43b0f45fbebe6c5e11a1d4
f6312a1cd6f6ff3a064115e95563747ede9d96a6
15613 F20110403_AABVQC tian_j_Page_008.QC.jpg
6ad868b229dc80393edf2de06ebbb5aa
85a9eb84107dde45f8537f135ea37f5156fbdfd9
F20110403_AABVPO tian_j_Page_107.tif
59fb0a729d3c01ff23c8d87535b5a813
73c562f50a15042e2ed24d626718032e15dfa32f
81418 F20110403_AABVQD tian_j_Page_009.jpg
6ed9d000f95c28345b1ef7bb4ad90a58
01abee914f925806662fb8cf4017d523dc69096d
25669 F20110403_AABVPP tian_j_Page_001.jpg
6a357002b93e732c8996fb978a036b9f
79f297ef90c07750ee54153ed5741a496a198274
27922 F20110403_AABVQE tian_j_Page_009.QC.jpg
88f6dcd318e14ce4c5f02dcc8a0d0931
d503a5a42329640314f27836b58f85828a62bf76
4001 F20110403_AABVPQ tian_j_Page_002.jpg
627d99abe5c7d503698e8186ca49618c
7dea6439d1184bfc1a4632030f422c853a0d701e
29922 F20110403_AABVQF tian_j_Page_010.jpg
5a3c17d6c07b08624c5b7efd4e001123
7babe56797b005d85ecebdf02658cdf65138e728
1433 F20110403_AABVPR tian_j_Page_002.QC.jpg
f1db42f0e9534df524aa61e2ca6e596d
a0e827daa5d9502c215745dbfe5dfd2d36acab75
9766 F20110403_AABVQG tian_j_Page_010.QC.jpg
c75b61463a52e114b07579c3afd293c2
128f8d038de1071efdf370991edc909b67abc116
67975 F20110403_AABVPS tian_j_Page_003.jpg
93cd6075edc02f2139a116b6bb423e0d
a95273b3e7504f7fca5fbca92100429a99ab5df4
78771 F20110403_AABVQH tian_j_Page_011.jpg
c2ccacf282adbfd8906059d91ec90a21
e99023c4a453613fc33f8b13c84a5607785ff236
15846 F20110403_AABVPT tian_j_Page_003.QC.jpg
0ff4ac1bf10d5150482df77039f4a494
da7ac7394d8738db6a9a086c936633a1611ea855
94811 F20110403_AABVPU tian_j_Page_004.jpg
4650a0087a4970067583d41574e15b8a
bf44dea75d18782d48bb1d344d44da82c52cbd12
20765 F20110403_AABVQI tian_j_Page_011.QC.jpg
bbefb57821194e595d963f27a05cece7
6046636efd5cdf2349b8d3d47182c2f304b7138e
23632 F20110403_AABVPV tian_j_Page_005.jpg
6aa8570a05f6f0d8b629c0b5e7ef9614
7bc22f8befbe83c5ff515b56aa1f71e96cb0a256
90849 F20110403_AABVQJ tian_j_Page_012.jpg
49bbf9b7585f891cee52208ebe34e6b6
4cca21860c87c57bfc3e55e9f536896b6cb8fe67
6559 F20110403_AABVPW tian_j_Page_005.QC.jpg
dcccd834ef0f9b60eafe385064c56be6
b297c3e6db395ce276d39d165c6e84a98e59d1b4
34510 F20110403_AABVQK tian_j_Page_012.QC.jpg
a0a0d52bb9ae8283f3dd0162ed977656
661c5a688cc9bb9a9c39775c950b26331966c34e
34139 F20110403_AABVPX tian_j_Page_006.jpg
e7a3276bd5af5aaf837903ba333d4a8b
9fd3c6f1a4b685fa58d412ebbaf36c9c51427f95
95231 F20110403_AABVRA tian_j_Page_023.jpg
3b311be35b083878c8a75d90300b87f5
dd01d8cd028274e7eb8bd2ed06f2447f79e04cc9
34365 F20110403_AABVQL tian_j_Page_013.QC.jpg
929430cbf161a24b52d2889ac521539f
f12d8ccb35c70bec38ae38fef0946a9ee988f2e0
10257 F20110403_AABVPY tian_j_Page_006.QC.jpg
462d94858c2e34437111dc3bff27bb9b
0d4b0f49a2cf7d28063760210a43fa2a0e32fad7
28285 F20110403_AABVRB tian_j_Page_023.QC.jpg
5b81bd7764b1c5b09d1636a23640172d
1faa26457f45c77302eea64fb75679f5e5d1a711
15585 F20110403_AABVQM tian_j_Page_014.QC.jpg
21c687539e93893b59bd78ae7eb36b14
0b31725f63d81d75c297f8b943fc1e99c094578c
67213 F20110403_AABVPZ tian_j_Page_007.jpg
46179f41a0ae1d381b99c4b12549b836
866c793ffba2337d69655c54c9830c833e5d89b2
92173 F20110403_AABVRC tian_j_Page_024.jpg
cbf5e6aaadd0e59350a1567388677d96
76271500fe103cbc15ccfe99a4b0280485b45c4e
19188 F20110403_AABVQN tian_j_Page_015.QC.jpg
78605a076623786d69cf22d47eb0446e
ab3110e57cbd59b006aad6df2c20909d5f99bf48
34525 F20110403_AABVRD tian_j_Page_024.QC.jpg
ad7745759c636b2e06b435dabb61fe7d
6fccda7a9946ec0f8970d0515b3f4585967daed4
78276 F20110403_AABVQO tian_j_Page_016.jpg
611e6e1d8a5e39f8a41fdc3b653066f7
cbea0d305519a022465d1a3f2b5b70fc909b0e24
75725 F20110403_AABVRE tian_j_Page_025.jpg
753019993310557f1d886c6fb8c9a638
bb19d22e01375ea072e04699d981db553872f4a8
22611 F20110403_AABVQP tian_j_Page_016.QC.jpg
2e3a6e882c33c1f7f28daf7a084e310e
cf02719384bca3b596d27706f63fe2cd7475877c
27299 F20110403_AABVRF tian_j_Page_025.QC.jpg
0f446f8e47f8afc4bef339688ad5be4d
abd2010d4456bc2368ef38d075fd8ba4101bdd54
86771 F20110403_AABVQQ tian_j_Page_017.jpg
3212b572e37eaa54acfe42a235ad6ff2
effc75127444732c46b74dcb13c2b8790131f658
85068 F20110403_AABVRG tian_j_Page_026.jpg
9418558f4f7455e41d0a0450571fd3dd
0e34a17bf6aabf1f4295bea49cc9b64e2c961e1d
32576 F20110403_AABVQR tian_j_Page_017.QC.jpg
43910b447df116be5b9cc3fcb7565318
855e05a1283acb3e61730fe63fed8f47150c91e3
31639 F20110403_AABVRH tian_j_Page_026.QC.jpg
9e8c063ec38a020230d873c5c34c7f6c
de3023238889863e3bd6c8a7e85ca3489ea19847
77946 F20110403_AABVQS tian_j_Page_018.jpg
73e855768a697670842214aa4ca106b7
6e07225ebd45f35a86a5a5be8112538825d0114e
78475 F20110403_AABVRI tian_j_Page_027.jpg
f389b0823c125688976b89a7c4e57ac5
963ef938cbbed52a21c9929da41581a22b10e9fd
103681 F20110403_AABVQT tian_j_Page_019.jpg
5cc0124f7b74912c42fbc24fcebcb611
7a813262cd314fbbf4338dca3e100cb1d9220e76
29032 F20110403_AABVQU tian_j_Page_019.QC.jpg
db518e2cd1ae86d1f14206e429cc3d31
4e5dd44f2eb4aac0165d1725062c68415933e67b
29398 F20110403_AABVRJ tian_j_Page_027.QC.jpg
886844edd33656d23859b27e0a8951b0
7973649ceea89b7796d5acafb6aba17d354d8198
99003 F20110403_AABVQV tian_j_Page_020.jpg
d049c1ab818162148b857380d4e3c1b8
11435f66e8757206c4115361a48a88a9f82295cf
88041 F20110403_AABVRK tian_j_Page_028.jpg
c5f1ba8dd20c301052a3c610558a8cf8
2e38e89672be20a392225fc6e347ec4507388cfe
30083 F20110403_AABVQW tian_j_Page_020.QC.jpg
6f0f0bd66f49a89c1aa6edc17498d75f
8d26291975c99217f478cf59aa8abd303e7e5b7a
29587 F20110403_AABVSA tian_j_Page_040.QC.jpg
9e5ea941f208f9697d92867b3fadb523
5605a96540d9dd5725bd54238387a77e1cce8499
33408 F20110403_AABVRL tian_j_Page_028.QC.jpg
6f0e5518980ae279cc13993e5b526550
51ba6aab715ce9465d263b3eb326bad2eabe49ee
106403 F20110403_AABVQX tian_j_Page_021.jpg
5d83d7e84b96be1f70a7f8f5a50c35e7
acdb2de69c8e27946652d284f191e70717a3f1ad
19585 F20110403_AABVSB tian_j_Page_042.QC.jpg
158bf2986ca77030ce0dc9553fe48a09
90a831a11c127904ed6e909376fa365d5af523a9
83306 F20110403_AABVRM tian_j_Page_029.jpg
c93bbc7b4617f79c5e08195bf1ffd347
71bff193e75f8e226051e9619db241dd021077c2
91959 F20110403_AABVQY tian_j_Page_022.jpg
aa4dffa38dfebf2761e1561b40f13d76
0020c5e694dd943c3f5f083cd3a2bb7ce8a1520d
23471 F20110403_AABVSC tian_j_Page_043.QC.jpg
9913a7369dc1cff3445ee9b10645a7a4
50d3f02c22abbb1c474b9572585953433f74e8eb
31306 F20110403_AABVRN tian_j_Page_029.QC.jpg
e7b3ccdaaccd5287c12e63f4ebeaa2f8
4067fe7cc3ecae8e4b1a005bb6c7d381313ffc1b
33700 F20110403_AABVQZ tian_j_Page_022.QC.jpg
01db442d02d4dbc691d95d939a3c0abd
1901df3d49b7f4486cf748a3a9d71f7830d02aa0
79861 F20110403_AABVSD tian_j_Page_044.jpg
d7684ae0720b3cc84bd3540ce7ef8411
d10b69bc263ed07264dc275c96b5f17378b21370
86310 F20110403_AABVRO tian_j_Page_030.jpg
42f37b6826f7018cf9b7e6ac4143dc0a
244066d744af80150fdf902c5f2cadfce01d0049
29667 F20110403_AABVSE tian_j_Page_044.QC.jpg
5a63c69da996fd9095478f610be00dad
eb6a48b8d2d8aed4ae084bb71dbd4ecee42d2a7f
32495 F20110403_AABVRP tian_j_Page_030.QC.jpg
a8124c9ab587c028f25be636f912fb5f
3d7626fbf3a7f11c41282e5e30b044a351162d26
76188 F20110403_AABVSF tian_j_Page_045.jpg
764b47da38fdbdca1c7f6906ce252f62
3e7e52dcd1a7de1a0e7e8da6402f933885e5d6ea
77428 F20110403_AABVRQ tian_j_Page_032.jpg
27312adf7d56627d183267127088fd68
bc0c46dbd83e2e79a7242e3243bc6f47f4f6a5fa
23747 F20110403_AABVSG tian_j_Page_045.QC.jpg
58a6f27eef80f1074eb98b157b53435e
ede0de136cb7cac1603b48777ee5477884c5253a
81593 F20110403_AABVRR tian_j_Page_033.jpg
063d05f54d9b073beb06621551649c55
d718730f95663e4bf6216a47b38c9274977af3bb
136934 F20110403_AABVSH tian_j_Page_046.jpg
8509cc2186c9bc90f39f054bb4095fd4
ac684232a0cc7117b49b943021a4e8a556010bd6
82281 F20110403_AABVRS tian_j_Page_034.jpg
e79c42da3dc122ef3bec70fdf1bd1f2f
5705618935baf3c337c4558df22538d87d691f1c
38456 F20110403_AABVSI tian_j_Page_046.QC.jpg
e39fd81e61b3240316b46cb86c574cd4
3beab7c64ff204e4708e251fab2dbfe82f85c7d8
30445 F20110403_AABVRT tian_j_Page_034.QC.jpg
c03b9217698db88b3cd63bb5cdf5a85c
5b7dabb8f212dcaa5479fa3df25d527416765428
111339 F20110403_AABVSJ tian_j_Page_047.jpg
23094e9adff8711b5a04546f8f7109d5
0f9a18db7d2c14fb8bbcc32c3d05e29f60926360
91914 F20110403_AABVRU tian_j_Page_035.jpg
1f9c9631ca33b4d924c802ccaea8f65e
c08b18a792f3634add9a83423e40ed6f13174770
33464 F20110403_AABVRV tian_j_Page_035.QC.jpg
bb8216c8c0a630ded41fe6aff1ea376f
e09022d0af70aded9e041e4920ab2eb27769f516
37522 F20110403_AABVSK tian_j_Page_047.QC.jpg
a3d35a9ab59244695c3909293fd29a91
59f4d86ec3558d15e3eb27c7deff1a55515ed392
24845 F20110403_AABVRW tian_j_Page_036.QC.jpg
0b0310340261fa021c71689de31cea57
5d632b45f7d5fbbbf1e3b5f7d5c8191f9a903284
30708 F20110403_AABVSL tian_j_Page_048.QC.jpg
781c94f10e6165562f42a1439c06377f
9351b764d543ec23d9f63d9cda700b0a2c3dfc2c
24546 F20110403_AABVRX tian_j_Page_038.QC.jpg
5632d512db269c70291c3fcf99529a4c
9f81dd988f3903c8ff1038a2971806b39ece072c
17800 F20110403_AABVTA tian_j_Page_058.jpg
2c48fe4dbcf65b9e478b5dcc8fe7f1e6
715e83d4acb99317940652999f667a088abe4bce
69016 F20110403_AABVSM tian_j_Page_049.jpg
fc562f89a62d387be5332b9fe4f7d618
64c759d01e0b600875db69ac5543470f2aa0e740
25652 F20110403_AABVRY tian_j_Page_039.QC.jpg
109ff2c5f2aa96f65513546dd190f783
1e19c2210b769d4e463ea392d36dbba1a5f6cf81
6029 F20110403_AABVTB tian_j_Page_058.QC.jpg
662770652b535bcac4aff51040c3e3fd
dc034693b7aebec1935d052b402bb76ee42ba651
87911 F20110403_AABVSN tian_j_Page_050.jpg
8c45afcb0debe1bec86c6544fcd4b3ba
614c1d9c0df982cf536d83a26ae18707d6677814
80173 F20110403_AABVRZ tian_j_Page_040.jpg
dee1e12d77b74445fe555345792f96b0
c577d154f3ade95a149676bad3e1b4565683ed19
77533 F20110403_AABVTC tian_j_Page_059.jpg
0209aa4cbe4152dd048c9405905edddf
d5ffb1c7f734a93a5ef466ef0e9396bd9341138d
89509 F20110403_AABVSO tian_j_Page_051.jpg
1741aeaeb9a4793bcaba3fc8dd780f00
2593baebd9227310b840d9b79d7fc14bdcead727
21797 F20110403_AABVTD tian_j_Page_059.QC.jpg
1a0bbf66f5525de8e56a7e267795580a
7ed77ee9e1f69c6dc20812621f2192b8cf86f17a
33984 F20110403_AABVSP tian_j_Page_051.QC.jpg
2522459f0cb82d8c5ca379ba750f8bfb
92206354acf4ff0d44aed0f0aa8e753dbed9e4cb
83720 F20110403_AABVTE tian_j_Page_060.jpg
957990ca4539c0d84907629970bb304b
afade87002461b49210e9414e30ff93263c09326
71686 F20110403_AABVSQ tian_j_Page_052.jpg
f85ecfb4e0f9290cbf860aa35e0f195b
cca247c53235b4e85d7e74db33e7b3ac67ece0f1
26495 F20110403_AABVTF tian_j_Page_060.QC.jpg
01f065d5bb72cdf0b394581daff0a3ae
d96344834850ca7b81fde17c3dd71cd4c26511aa
82439 F20110403_AABVSR tian_j_Page_053.jpg
0ad6a778df909c7c4e475c287b2902f7
633c843f3e6a08c644ec8c2b9ab06f6a51bcfad8
64338 F20110403_AABVTG tian_j_Page_061.jpg
3d5cd200645950e955f3f412376c3d99
6719b133a8e906162b6978e4639cb45e219ab8ba
21981 F20110403_AABVTH tian_j_Page_061.QC.jpg
fcc4881121cae1daa784942692785108
b04b396041434ad63c2b59b541276a109bcda47b
30099 F20110403_AABVSS tian_j_Page_053.QC.jpg
74b9fcdcf5bbe713cb1ef2e964c92426
3adea00f78ef351d81aec5c8d816d1fbfb3170c1
72034 F20110403_AABVTI tian_j_Page_062.jpg
8f2cc5490d316b7970d6f848cfd6df4a
ba230ad6915df47a455e0921fad77f9b22abdb39
88985 F20110403_AABVST tian_j_Page_054.jpg
59490f807b8decc89c57549690bf7651
802459f812f933b20fc569b68e50fcb82762b6d0
23640 F20110403_AABVTJ tian_j_Page_062.QC.jpg
3e97a20f2111a8830e6d9ba94064925c
31f4307479af695909d37cd67c573d001932c9ef
32190 F20110403_AABVSU tian_j_Page_054.QC.jpg
648e79220259087525006215f5db239f
c6433f62f5cbb5790fa8a23993e2e071ec520585
72019 F20110403_AABVTK tian_j_Page_063.jpg
fdb5290f8033915e2aacdc3667fc2ed1
069ffdcc26f68790c3dd9d33249ca82098351891
87493 F20110403_AABVSV tian_j_Page_055.jpg
f97494d1df3d9059c35a2f214542fb33
9ab39a66e182b684f029807ec3eee6c67ea410cb
32603 F20110403_AABVSW tian_j_Page_055.QC.jpg
3903343881febd0d5fd1dd651ca63a5b
3670b1cca530ea5573bddb1fef593f2414bd9497
15358 F20110403_AABVUA tian_j_Page_072.QC.jpg
ffcfea1cf40c91adacf4bfeebde61226
ea602740383f358e052ef3b109dc5f6362ed739b
26955 F20110403_AABVTL tian_j_Page_063.QC.jpg
90083b2f51565d597e2ece2c1d189278
5005d1509ada11e96096935849dced1c9af77a81
80892 F20110403_AABVSX tian_j_Page_056.jpg
ca2ef20ee6c6c6aeaf5d264c49500af2
557962f37ddfce5774f6674a21d33c0c9182191a
21910 F20110403_AABVUB tian_j_Page_073.QC.jpg
087cec7c5a568ed43be9e38220e958ae
c1739171de113a63661b01b1ec1ca0825659434c
60452 F20110403_AABVTM tian_j_Page_064.jpg
6bbf6212d6592b22afa9c9644c506dad
2b46b7ce51a8aa6cd4e5cd9c0163a5244e3e0eaf
28747 F20110403_AABVSY tian_j_Page_056.QC.jpg
2d3d0d4745cc66431e2bc7de4dfde9db
d32850a835cb1f4efba3432d1d358c3fa3bd6427
85389 F20110403_AABVUC tian_j_Page_074.jpg
1543c261c37de56381470ec8f6825e9d
6656d1d8c4170b42d2f33cbf12257bb74c57470f
32307 F20110403_AABVTN tian_j_Page_065.jpg
c1377a92664ab7d9159706dddf531b9f
8012a6bc85cf8a6d658d0347bfabfd723ef85aae
108852 F20110403_AABVSZ tian_j_Page_057.jpg
f3c510e116d74e3b5ee905b5e6488dcb
3db1e4d7aea16ebf491851bf842f3c836092e5cd
31686 F20110403_AABVUD tian_j_Page_074.QC.jpg
ed06c79e8d72843c50aec52f4f23e3b3
c0f57362db93a05fe8e1533ec14a4f532aba83d6
11208 F20110403_AABVTO tian_j_Page_065.QC.jpg
49274731ab884d0862d304bfe15ee2e3
01b3ac2b9d264eb486a8149652e3e25559f2affb
82465 F20110403_AABVUE tian_j_Page_075.jpg
a3802f42033b83beee99f01677154217
22b4d8bb309f6e84b3e2a6f006a0afc92321a1d7
11592 F20110403_AABVTP tian_j_Page_066.QC.jpg
3fcc06dc2c7f414fe5de27a28cc4142f
eb0a0d379d956b2620c74c707b55d247f114c3ee
31154 F20110403_AABVUF tian_j_Page_075.QC.jpg
7c0fdfc4996b50ceb82d0f8e9f72624d
61a214d0f68744b60a4051cc377fb570305af91a
60246 F20110403_AABVTQ tian_j_Page_067.jpg
c34fd9bb55722a8b1acc0a4c087a0cf4
7571da307c6d5a52f1be86ff30bd097fffa9b7c9
61303 F20110403_AABVUG tian_j_Page_076.jpg
efc8270cb3998418f0d1924a625879ae
557fd3a86f0bda07302a1c970596164856c08fbf
21550 F20110403_AABVTR tian_j_Page_067.QC.jpg
261c93a359b823d51431de0c99e5969b
655ef8b3dadd2521613129982f1b87e025c8e124
6648 F20110403_AABWAA tian_j_Page_009thm.jpg
f8a5f344aa80e9407f7fd4d0da0b2de9
632a7c78fcf1a982a8c1ebee8ec2fd00de746e00
19137 F20110403_AABVUH tian_j_Page_076.QC.jpg
cf58d9f81115a946505e7bde914c0056
ef4e9685a10ee24320c30c243a5af235e1288a21
85373 F20110403_AABVTS tian_j_Page_068.jpg
bdcb7eb120033871fa983abebdee4115
0a1983cc7ad0bbd41b2a4c01a9270e9900518163
3224 F20110403_AABWAB tian_j_Page_010thm.jpg
a704cc5e88cfa567dfe6573f0925f8bd
0a3677c3121f29a2a9ed1d8d69ea89fa360eff95
69244 F20110403_AABVUI tian_j_Page_077.jpg
ced291f923e60dbb0a41980eaffa916e
d214259d96b5901faca6653c3f558194827fc305
28701 F20110403_AABVTT tian_j_Page_068.QC.jpg
bed015fb32f94f756eada54af850f45a
323af78da249bc699e6f5398af7d18eaec4188e2
6811 F20110403_AABWAC tian_j_Page_011thm.jpg
13d15414a67e420d3c2e5d2ab3c92977
3f13ba81b7bf1f47566cb8ba06ed167d9ebd4b9e
24264 F20110403_AABVUJ tian_j_Page_077.QC.jpg
c611b4ea3af2c3315b7cfd3622b5a12d
89acdfffa4829eec9c3eda8ee6910875285b52c1
66319 F20110403_AABVTU tian_j_Page_069.jpg
6c9a0c4b063dcab47bb6e6488ba29689
9c0f1681771f167480fc36fb1348ed2b5a51cd3a
8386 F20110403_AABWAD tian_j_Page_012thm.jpg
480eec099e3dafb2eb428e11b671e054
523c1666e57382aee7241beaa59bae8d2884d6f1
64762 F20110403_AABVUK tian_j_Page_078.jpg
6268c54244ad9f3212fb5441cf8d63aa
1f26093992ad0361b3d422ef762b277d44c55b59
19816 F20110403_AABVTV tian_j_Page_069.QC.jpg
73bd2c8b68eb54d3d500bc63017f169e
915d4421879c9b10efa49cd5eac9bee3acc97592
8564 F20110403_AABWAE tian_j_Page_013thm.jpg
59a104a46ecb1a26c47e9124855f10f9
e220a398b961d1fba706e829e83467568b2dd586
20967 F20110403_AABVUL tian_j_Page_078.QC.jpg
dc5d4b1e8272f8f3f92b62eff5ee832b
19bc4be61ff79c5c7f78bbec91ed19f9767362b4
36591 F20110403_AABVTW tian_j_Page_070.jpg
b406405adeaccd4d6e3f9def89842fce
47645b55f48ddcca97c0b604fe5883757d6e41f2
4700 F20110403_AABWAF tian_j_Page_014thm.jpg
59df849c8be9b64a435e47f6d355878b
da6fec2234b06c77016c737ace891a1eae430b18
53435 F20110403_AABVTX tian_j_Page_071.jpg
d6e3da5805554240c7e23774ac885e33
637da5895627641a5aa03adb3cf5bdf19267af48
6211 F20110403_AABWAG tian_j_Page_015thm.jpg
19e9db71fb42af56d2f76dc6f1389e3a
cb1c5f49fb688e2c15a95ba413af08aafac4cdb6
89476 F20110403_AABVVA tian_j_Page_090.jpg
9a8d2246ab9cbd2597262a88eba25c33
e1c4df25a7b8064c211fae5c7114abc52b55c1bc
30049 F20110403_AABVUM tian_j_Page_079.QC.jpg
29dba50c5c7cfe592c6a2335a9b5ae07
d8c44b1a419911f7fa603f2ff2baba56cdd5473e
19602 F20110403_AABVTY tian_j_Page_071.QC.jpg
64b693ba7f98cdecb4fb71de72187095
a79dce1cb07e46c0e6badd38f71d9e390d4b8a1e
7081 F20110403_AABWAH tian_j_Page_016thm.jpg
1e5c4d1abda6283a0cb77fa697bb49c3
f53e91bcedfd9eb3004fce574d1d8911e00e7cbe
32911 F20110403_AABVVB tian_j_Page_090.QC.jpg
59b5cf58de109e6d5333869bf06a4e08
b05145cf01ce631d552e9518917a27135e5d08b8
69015 F20110403_AABVUN tian_j_Page_080.jpg
49e5a7ff87cb6d044a89fb183f0b03fc
ddb2f2950a0e6fb3735fcea32fa50f19b7d1b912
50709 F20110403_AABVTZ tian_j_Page_072.jpg
72a6138da23a4f4027f8ce98179185d9
f9e3f497e6d0be90efd048f2969094b853be33fe
6825 F20110403_AABWAI tian_j_Page_018thm.jpg
79d548b036d619a85973efe90bbec0db
9890a00edae97a388f07649cb8c3beefce1c9f45
75845 F20110403_AABVVC tian_j_Page_091.jpg
6b855aed950e2b90d68fde380ed42d12
5f72ff018420e8b2f88f0af1fc9bc1e77e3d8ee4
81155 F20110403_AABVUO tian_j_Page_081.jpg
d40b48045b17750862344673c97ab2e5
f7ef160abc0b30a1ee3e9cddd16bd72905c4538d
8162 F20110403_AABWAJ tian_j_Page_019thm.jpg
c482cd01112a51b76d87d6889898e68c
b1a600f17530d78eb1700b1bf09e99d00eaf6b9e
21951 F20110403_AABVVD tian_j_Page_091.QC.jpg
06be87cba78ba457fc678e666107914a
8b78ec83275b4f5af90e4fa83f2a1715a303961f
23950 F20110403_AABVUP tian_j_Page_081.QC.jpg
26f4ff7573668890270b0c975b158a80
c3027c94fbcb686e8b5bffadf9f24a7c65ef32eb
8069 F20110403_AABWAK tian_j_Page_020thm.jpg
fb0fbe6ee8024dc8e70357a017fe24b1
89a83b292dd568a7b58fc75f84191bcc8c9ecc4b
79849 F20110403_AABVVE tian_j_Page_092.jpg
08e4908acbc8d32042c144635d583ff5
6eff7a6bfa82a0fa73019256ad1f73ef867d915e
36102 F20110403_AABVUQ tian_j_Page_082.jpg
42f824d3ab4f7f00532f73ee5a26e169
761794d95020faf3fb6746468af357cf53da913c
8332 F20110403_AABWAL tian_j_Page_021thm.jpg
41b0374e753c2122b997e5f61513939f
6ad2fb3898854bdd7871629918859215179fc821
29273 F20110403_AABVVF tian_j_Page_092.QC.jpg
c5b3025175b2b90a0acc6564e77e24a0
c5900842ab926fc9d045c52f84eefad4fa140b46
11161 F20110403_AABVUR tian_j_Page_082.QC.jpg
f5d88bca0638fd03a2136e19e56e3d79
c029c0d876ad84f095959c856a0417a9c11da528
7580 F20110403_AABWBA tian_j_Page_039thm.jpg
4d0b98d15f925c329248358dc045d2b1
e3f295a34c13ad3d1810d9edc4681148e5c3a781
8006 F20110403_AABWAM tian_j_Page_022thm.jpg
55c7fc33f12e24c9425befb5ce964305
9560fe18ae63c7e4ba1b50cc48191794ca14d02f
88585 F20110403_AABVVG tian_j_Page_093.jpg
e06800d753f18a3539189d19743adf2a
ee50970126a311c4e09bbd936c2a480abe88b030
84777 F20110403_AABVUS tian_j_Page_083.jpg
b3ccff21673b1c61a7572a900c59d380
46060d4d3d5b7f3f41a12b652489c9a016c6d8b4
7762 F20110403_AABWBB tian_j_Page_040thm.jpg
305c220388a3e73a8ea953e2cee4b6c8
769c5f7a9da11efb1210722e50188f4e016f73ad
7942 F20110403_AABWAN tian_j_Page_023thm.jpg
b9d079473d38a9575f4def7a80322057
5c5985267f2789d4ab25fabc31677dc6db6fd3e6
32619 F20110403_AABVVH tian_j_Page_093.QC.jpg
2cb3d04599334d8b6421afeedd8c928a
a3345a11356a92c2103ddb809ac81811a309705c
71403 F20110403_AABVUT tian_j_Page_084.jpg
7a2da7edbb520f79cc77fc321f2cdc40
cf6028a057b710dd9761bd343850ff56af8f7850
7757 F20110403_AABWBC tian_j_Page_041thm.jpg
dd0d75333a78a8a52b689e865eb22204
4663daa5b950ea0625ebf16a8c8a0d61ccabaf05
8249 F20110403_AABWAO tian_j_Page_024thm.jpg
6c271922d4c5b91d407e24e29b2dd592
6f5a8adc23fc5be913a4f42653f1438caf4029b4
55870 F20110403_AABVVI tian_j_Page_094.jpg
441004361bab54cf2eda79414441074a
ae71e9525d7f10355b54171334c0b1069ff49bcf
92166 F20110403_AABVUU tian_j_Page_086.jpg
77adc719b6882c1785b07f4840469db9
9c6a3299381b963487da314359b09002776dde0d
5784 F20110403_AABWBD tian_j_Page_042thm.jpg
d23f115ce08a71fdf94c6b42dfbe76e5
4f238bee9d63efdfd796548c62772457af0f2c81
7132 F20110403_AABWAP tian_j_Page_025thm.jpg
bcaf0d38b89d154fbd2d4a85dfe13a50
f953426b611ac17dd0e5d53a77bc44d7d45b992f
20280 F20110403_AABVVJ tian_j_Page_094.QC.jpg
05914ce18e2aea98d398baab3d66cb61
ddacdd1d6821320a3a48c90907b7eb32c369df30
72543 F20110403_AABVUV tian_j_Page_087.jpg
54e38f031d053b279a4d6ff6880ceee8
5b98d9ad564ddfd7091d984362623cd32180ebb9
6397 F20110403_AABWBE tian_j_Page_043thm.jpg
399da2ca6a028a0e7350e016cfccecb7
c892bdabe17c56db7dfbdf2df2141adf4dabea1f
7811 F20110403_AABWAQ tian_j_Page_026thm.jpg
cd997ef5ebaa068a2f50c6b4cbfdbfd1
80f1410c8d5e3387f0413fc009d8ffee0566b6f7
97741 F20110403_AABVVK tian_j_Page_095.jpg
63db791d5874b9586b1886f0044a9d8f
3a24dddafb1f2aad74207b1ca00fc4c358326af4
23077 F20110403_AABVUW tian_j_Page_087.QC.jpg
a7c13c5c5cd059e2ad73f3b0b042b3b9
7d906e16ac794d4d3d3d6d6e48f8e43e9c3cdb46
7676 F20110403_AABWBF tian_j_Page_044thm.jpg
975e20e9739cbb8553ae837b7aa0fe12
46f348585f2a8cfa05b929e603c073db57e84cc2
8248 F20110403_AABWAR tian_j_Page_028thm.jpg
12bf0ba60b3bdf5dfa4962659f55734f
b65bd9cb29f96373840671439d52c2d098f7f38e
29681 F20110403_AABVVL tian_j_Page_095.QC.jpg
bac1f761814b42dd5327622df2d9a32c
168509fe3217b16956ad52f06fbb78c2304cf95a
76790 F20110403_AABVUX tian_j_Page_088.jpg
fe944b3e3e711b2e1128e590e3583a04
b4596349abefe27906c3d4eab393d871745f339a
7430 F20110403_AABWBG tian_j_Page_045thm.jpg
b44922b4c0190d116f2aa3823dd14ab8
dcb9d281a65b028b2cd7e848cb1192fca278c88c
27850 F20110403_AABVWA tian_j_Page_103.QC.jpg
32add51a8719f85bf8b48e92ce53aa04
000562af6224103cdb37496b13de23a8fe53b966
8079 F20110403_AABWAS tian_j_Page_029thm.jpg
5b7399b2c00aad59f7d20ec89906b606
b64e416c65efe6f6c950a0b8e22eee87a1ed3a55
19464 F20110403_AABVVM tian_j_Page_096.QC.jpg
116ff7a99c8f2f375bf3ea4be1f2c383
dcc7a748e859a55c5f8c9dcaf6eea707afd40242
80253 F20110403_AABVUY tian_j_Page_089.jpg
5e11faa5041afabf835b6e180b1ec20b
187ffbd9537dec212f4bfc3af30f86ac7ca1143e
9234 F20110403_AABWBH tian_j_Page_046thm.jpg
1573f75e8ab2e1aedf77e060847def43
1f3733a931014ea4d105dfae26f40f66ce8a8f62
83216 F20110403_AABVWB tian_j_Page_104.jpg
be2a734637ec1277abc0c04cbe33ed3a
ccc1a39602d135e60dbe4c9dcbb25d6f977873a8
7924 F20110403_AABWAT tian_j_Page_030thm.jpg
dc5619f202943a53f633518cc71c08dd
09e62325820d21c1f55a55d28434408c3f890882
25467 F20110403_AABVUZ tian_j_Page_089.QC.jpg
36a5a1641af8beb8697b98ac4f424aae
6eba253c728503aabbb3748cb9a75d8a1b0e8a59
8794 F20110403_AABWBI tian_j_Page_047thm.jpg
8aaf50959fe782f53d92ad7b2e3164ae
f5af4f9c34c9e93d4f197150f453f202b14d9d83
25904 F20110403_AABVWC tian_j_Page_104.QC.jpg
25967a590da50344cb7564d6cc00beaf
a915aa02299409fcc38ce97ba6632c1a592c8bf2
8002 F20110403_AABWAU tian_j_Page_031thm.jpg
c11d8e2a4f5e06720da04e632423174f
397c13e690e78e0bd309267f152693bfe3b49b73
49656 F20110403_AABVVN tian_j_Page_097.jpg
d18dc1b8f94521c9e915d0d00c1e1211
65e3febc9813a82859ef180a5c6f734a02952c88
8047 F20110403_AABWBJ tian_j_Page_048thm.jpg
810e41060828c7bdd2f9bb3b2f9e8043
c8ba7f1a412a811889a6bcf2c0e06b7bed722c42
88135 F20110403_AABVWD tian_j_Page_105.jpg
1d846279a6ab88d93f66b76a96367fa6
e69c2a46593aa968d320fab554c938d5437d919f
7801 F20110403_AABWAV tian_j_Page_033thm.jpg
8b77470ff7c3b3c5aeceb1f704c37b69
77a528f69584c462da024d97e85069b70ea80c48
17301 F20110403_AABVVO tian_j_Page_097.QC.jpg
fa979c5fce5300ae2f0b017c0bf7e0cc
81b1782b03e2492a76caa26915e86039f3caca5c
6009 F20110403_AABWBK tian_j_Page_049thm.jpg
5887600f97d75d692d7662ffef79af2f
d1e80d2ab3246e19392b64d87d6606e4df9ef747
27540 F20110403_AABVWE tian_j_Page_105.QC.jpg
481d406b36f887fe329b5438474345dc
8acf4375d1cc83a0ae6072fea2a4211420f8be9e
8023 F20110403_AABWAW tian_j_Page_034thm.jpg
0c2e38c178d8e2d7d0bb186edf9d586a
3e37df213601233e06437418fa00d2023a7b03e4
35285 F20110403_AABVVP tian_j_Page_098.jpg
5c0da5cb9502d61f13e8eccef83c9fbd
c1d21602427cb040377f130661134eddb480b16b
8220 F20110403_AABWBL tian_j_Page_050thm.jpg
a2cff340cdc2bc71f749353d4fd94561
850cba96f61b5ea127efde3e7c66d722fbbfa11b
102624 F20110403_AABVWF tian_j_Page_106.jpg
4caf4ef854a116f83d243e80d8b6c1ab
b69c5ec484e3008ebf616b60a84acf8aa33306a6
12138 F20110403_AABVVQ tian_j_Page_098.QC.jpg
07a9f405911ee54af04c795325279dce
952e5a1e9a435c439fc007425a7f79263969338c
8350 F20110403_AABWBM tian_j_Page_051thm.jpg
0f7d2d5a109504b5fda0fb0a38398220
92c6e32b5a6aecc50824ee5aa5a8e1617b09cb71
32334 F20110403_AABVWG tian_j_Page_106.QC.jpg
5e40252be8232494f725bb0cfe6d72f5
01218f2d8d581a58e54bac539e77f8d397f54852
6231 F20110403_AABWAX tian_j_Page_036thm.jpg
ac17cd8823798fa0e3ee818ede2e28bf
77bd731a6a31d15ebff3f323e7c5d3f45dfb1087
70433 F20110403_AABVVR tian_j_Page_099.jpg
08a918835703f246db3067d29ec5f3ca
3d20a3e7ce928f9310ef5bf00dbae096166200ad
3377 F20110403_AABWCA tian_j_Page_065thm.jpg
dfb8eabb61762dc4855b4954999e6bb4
ea6845d26d5ce36443d3b9b44ae4ac679e431d8e
7009 F20110403_AABWBN tian_j_Page_052thm.jpg
1998ae628330b37289367e516d02e986
57e5727ef6477970120284b6df0e0153df1242d5
26097 F20110403_AABVWH tian_j_Page_107.jpg
2f2a6cce03cbed38e2b9afa3e7c03115
9f999ff727f4d86f32f49d1e2c3334c7f6ab48d3
6610 F20110403_AABWAY tian_j_Page_037thm.jpg
abaa2215468b2cef53edf3e4203a9882
b0ecf64a8baa3176d38c94a42ebc453e5ad0a611
24071 F20110403_AABVVS tian_j_Page_099.QC.jpg
4be7d7674db6eb13fa1d1b8861a01a5c
708e8042f50697d47bf9c397c004204d2bff823e
3554 F20110403_AABWCB tian_j_Page_066thm.jpg
1d7ae6ca5b284764dc6bcfd068ee8aeb
2a245a5b19247be4c97bbd7e72fc223c5bcd2c33
7660 F20110403_AABWBO tian_j_Page_053thm.jpg
ad419eef9631733ec56275764f6a0d35
d86ac30fa84631f56ca392d435dffa248140eca9
9961 F20110403_AABVWI tian_j_Page_107.QC.jpg
87da6feae6deb4116825d41e75650b5f
fd3243eef7421a4449614b106bcb95c9c1cbd5c3
7405 F20110403_AABWAZ tian_j_Page_038thm.jpg
bd8835f6cdf22448917a64c8a6c3e67c
f07af0b0897802248d15d7eb8a7d3f563152effc
77793 F20110403_AABVVT tian_j_Page_100.jpg
aee4cfcc06d92a6602c85cccd0f53bce
7b9513d12d311bab07a798452ba795dc0e2e1b5d
5595 F20110403_AABWCC tian_j_Page_067thm.jpg
1026507d5798fc775fa5ccfd08b93a1a
f607de27f3e93829cdf0c74fcbf3bee574fe709f
8110 F20110403_AABWBP tian_j_Page_054thm.jpg
d90b502d7cb931a003fbb081d53a70f9
2b0e0030ecd192268a8913dedfc5c75e67b05c32
228606 F20110403_AABVWJ tian_j_Page_001.jp2
6f5d73a27d4fa79a66ba669dca535c7d
c72387a2a3fafae903264722894c773da237232d
20899 F20110403_AABVVU tian_j_Page_100.QC.jpg
b51e24b1e7897ab6cd942b70e769033e
fabbda80820911dd0772eb4a5e96109eaf992b39
8149 F20110403_AABWCD tian_j_Page_068thm.jpg
51bde9f866d809a9efbc0617045b7bd5
34de555617cafa349f75bbdd5858534183b806b1
8198 F20110403_AABWBQ tian_j_Page_055thm.jpg
212f219a7b56be5fc5d05beb31f27ae2
c81c16e7bb57612a876daa0dcaa515d0eabff4dd
21770 F20110403_AABVWK tian_j_Page_002.jp2
9eaf23c875812a4d0d197a8a3b7fe915
8888370cffed7b33565bf5c124286e2e4f1c8f59
81889 F20110403_AABVVV tian_j_Page_101.jpg
021e65edeedbf1667e791e3a225e364c
7f026fe9c1d187e94cd1cfcc0ec8922ed720f776
6643 F20110403_AABWCE tian_j_Page_069thm.jpg
62e0eeef861f5e1684374fd97e8fbb84
142b8df559bcbdb15591eebd284a056b87fac6b5
7888 F20110403_AABWBR tian_j_Page_056thm.jpg
e80acdc2f002f4e7aef7ea871391db7b
05fde92b97f9180e90c452775ba0b43d97d6df46
679423 F20110403_AABVWL tian_j_Page_003.jp2
8905facc983b994e4adba1dee543be75
04db577c210ea9f2984505a523f19443ce6189f6
26651 F20110403_AABVVW tian_j_Page_101.QC.jpg
59afb2678bd90b40e086be6ec55a375a
f36f93cb831bd4edd979427dd14bff9957030207
3929 F20110403_AABWCF tian_j_Page_070thm.jpg
43c432a699309c1639deaa4def1495d2
f39adde361c1c2e58fc33d36efcd5f0341c285e7
1051960 F20110403_AABVXA tian_j_Page_021.jp2
900cdc2ad90862b524aeff5ebbd23cfa
2cd227ce04e8c36eebffa42c980062a279ebd5ae
8443 F20110403_AABWBS tian_j_Page_057thm.jpg
1318c516491bb2764072f8b13b5c72fb
9e0fc7f621145cc7ba8199528016e534933efcba
965678 F20110403_AABVWM tian_j_Page_004.jp2
232ba750f6d78e7bc64f420f3987c462
8277fd9be229daa4f85d1ea2bef2fbf45e03ebd5
96673 F20110403_AABVVX tian_j_Page_102.jpg
8314559abb94ec90cc5e09d78e458773
3ed709f7b9c880b36905f43887640424c13f1dde
4957 F20110403_AABWCG tian_j_Page_072thm.jpg
1fb886ea454ddb1687fe35032d0073d5
7d9d2b9c3dfff13e9ac79b4cde273bf90030a2ea
1051970 F20110403_AABVXB tian_j_Page_022.jp2
d2b27512af60d10fe9ac98c0f2cd46d5
6c62decc9ebb161e465af926961eb9a12c603646
1777 F20110403_AABWBT tian_j_Page_058thm.jpg
92eb4525ceed6c102f64228b15112207
42fdc794eb814ffd80600ebe4424cf94852d6dc8
225481 F20110403_AABVWN tian_j_Page_005.jp2
32f7e4350ad559b14678b08389c00542
c130cdca09a43808b9a973412dc0b06501db4390
29561 F20110403_AABVVY tian_j_Page_102.QC.jpg
6432a1e365fe592f11f4138e3f3a996e
6dba420638ee36c35325f56fc0e606296f345361
7304 F20110403_AABWCH tian_j_Page_073thm.jpg
c0044870856dc427cec1a035f376f47b
d7ff39d98296b3ef6856cb33dcb4d94c13b9adf1
904600 F20110403_AABVXC tian_j_Page_023.jp2
e16a3a07cbbf99a5ff7c1eed3e7faeaf
ef1b40f5b03619ab76f2f295f6c2e53686bd0b62
7177 F20110403_AABWBU tian_j_Page_059thm.jpg
a03f8c478985730e575b593f43acd621
0793a1bdc38ad4c52bd0e52b9739b34925d88b99
87184 F20110403_AABVVZ tian_j_Page_103.jpg
4c0fe2a0850be9fff5dc06f3936d5fb7
21cb6c1afd45bc4b4edd2e115654ecc2a72bc5f9
7964 F20110403_AABWCI tian_j_Page_074thm.jpg
8c317fe14148c454ea295c4eacf77bfa
2a9443d481318ac68cd421a5bf7e1938dc3bb055
1051962 F20110403_AABVXD tian_j_Page_024.jp2
7767eb82c7624e7e1a8a7f9d9ed4ab48
6f95701e73e31eacfae9fed83dedc694b5f5778b
7714 F20110403_AABWBV tian_j_Page_060thm.jpg
4f1c5b384019866170bac93a8bdae3b6
694639eae37d2b5699efa3a8be8ad332fb387577
341455 F20110403_AABVWO tian_j_Page_006.jp2
439ebdfb8ac1df8997f0f7d86d052f00
60eb080074c9ac58c6f5f05f68285602362c5518
6190 F20110403_AABWCJ tian_j_Page_076thm.jpg
cc78f3a6559d7fe0496e9ba19f11f5b3
473e9fdbc9f26f1b7148fdd1706cc0ab02a37a03
860056 F20110403_AABVXE tian_j_Page_025.jp2
840e42545f8363c51ee30f19fde85795
5f52afc59c4855e31722a486b41bb82f17099cd4
6440 F20110403_AABWBW tian_j_Page_061thm.jpg
ce8a50d7113fd3053dfdc7173f64cc7e
23a99352acaeb6f14bc507526654961a5b4afb5b
578248 F20110403_AABVWP tian_j_Page_008.jp2
cd83e7580b24bc9a63d9b9091cda96c9
68a3ba35e38a58f6e6f9067906c3bb822e02d65a
6497 F20110403_AABWCK tian_j_Page_077thm.jpg
17c5ef0d07dfd71614d20636675a5116
d5dc60bca49497d94eb4487229a509db68b6d24f
1001248 F20110403_AABVXF tian_j_Page_026.jp2
a7d8ef489357cfd8aee6a6b719553b70
d9667f00d05210eef256315ecf445ae52c1d4810
5496 F20110403_AABWBX tian_j_Page_062thm.jpg
d3bac267051454604b05afdba0c3e56d
4a08a8957f143679a543fd5341e1429ba74fae69
819613 F20110403_AABVWQ tian_j_Page_009.jp2
7d983b855c1baf4f3666f9c7ab102dc9
01a5e3ef6471adef7b578fb8b4c361546e7eb69f
7569 F20110403_AABWCL tian_j_Page_079thm.jpg
1fa26d89e4f0a78e3a9de67cf7abd7ee
5d7d43919dc5daf8c1e6acf28713f69324cb8f93
920217 F20110403_AABVXG tian_j_Page_027.jp2
6b121891b7d1669a0771575b6606a547
1ef1bfc6fdaed4e522dcfadfc6b25c93a44e9b1b
350233 F20110403_AABVWR tian_j_Page_010.jp2
bb307cd435652cd8cfc4974f7bfff876
04569911722e802d21890fb92f39aca4f2b9e2e3
6034 F20110403_AABWDA tian_j_Page_099thm.jpg
8cc4d8ca03036b3932580127d8c55ded
5bce6376607cdcfc554d448dda6b392383d6bba6
6530 F20110403_AABWCM tian_j_Page_080thm.jpg
316ab6f5bd2084a2f1eda509654039e6
92fe4f6047d720badef529c801d25e81f4fc1681
1050962 F20110403_AABVXH tian_j_Page_028.jp2
dca487e5dfa9a0228ad3996091ef31dd
f36eb34e2863ceb46e57ab70d7df3487d1a35964
6783 F20110403_AABWBY tian_j_Page_063thm.jpg
d021847802461b05b370d039daa5a68f
3eb214f8045dcddd1cf4ceadd411f3c5019c8f74
842918 F20110403_AABVWS tian_j_Page_011.jp2
2b357ba0fecb4160161bbfa6baf1870e
773fd116adfc3fcf3c1a3381a30ae267ce454fc6
6670 F20110403_AABWDB tian_j_Page_100thm.jpg
b22a24c19b35db6bfdb397050e7c3749
28abaab56acd72776701d03c8fef7eb6992ff2ff
5729 F20110403_AABWCN tian_j_Page_081thm.jpg
9a4f3c641e3dbdbabac28053b3bbf8cd
209d15a10548d7b65a0d4e08bb73e661ab0205f3
994192 F20110403_AABVXI tian_j_Page_029.jp2
2831fb388ed67ba6d3dc49311a57ca11
6952d0fa3357a5b44f692286ca0c66c47b6ce758
5114 F20110403_AABWBZ tian_j_Page_064thm.jpg
43772ef2b6468e9cf3662576b9315feb
5dda3fec2f8f176de064222654b00ed634bf43be
1051967 F20110403_AABVWT tian_j_Page_012.jp2
776902c37ede3abce0e26855a64428d5
a1c085be0803089c26b8faf7512ff348631a60e2
7958 F20110403_AABWDC tian_j_Page_102thm.jpg
3129161139f33b830a65d545ca2f8bcc
195c0de54d8ee0d2cbc86229cc2612f7e801cc57
3418 F20110403_AABWCO tian_j_Page_082thm.jpg
c44ccb5f9ad7740a269e22a8421aabbc
a4429da3d6824cc23aec84eaf70c1ac5a312f3d2
1015609 F20110403_AABVXJ tian_j_Page_030.jp2
af19ca3caf9de0ff1c1890f598c8fc5f
ebf87cb77239b2c3be0829b7999a12eac8580512
1051980 F20110403_AABVWU tian_j_Page_013.jp2
7f95058662000edb17cf9b6c1dca2c42
618a461dcc3e50a6310c90c58bbe08284c31a501
8013 F20110403_AABWDD tian_j_Page_103thm.jpg
e2f7daee3b1e7e2862be976f645f2f2e
d0703ee73cbdb58bc1180547a6c43c73ea483f3f
7297 F20110403_AABWCP tian_j_Page_083thm.jpg
af1bd3713ee0946f573bd7c4285a92c6
b7789dbb43524cb8ce289ff1c3caf3cc11897aae
1024489 F20110403_AABVXK tian_j_Page_031.jp2
92b3b3a21d89a4fd1fe4d6457e6b4754
06ca7475f98d1cda58d307e2166d51182c283902
549270 F20110403_AABVWV tian_j_Page_014.jp2
7c7a5b48290d31afe43f31c9071a9810
929726a8b7339dcf7ac7f59b46f05bb2c25f0d73
7606 F20110403_AABWDE tian_j_Page_104thm.jpg
0f246858cd84c28ef89f952fa91c85a3
58d1e0613b2637899de47bfb36ead04b5b049f55
8504 F20110403_AABWCQ tian_j_Page_086thm.jpg
9c297d13930e54ad8b76e20f8795982b
fafba1bb64d7fc4a98d35f876a0e4a0a45fcab57
912885 F20110403_AABVXL tian_j_Page_032.jp2
9e33dbf4cf598cdf1dbcd0477ef4d54d
8d2e3c4ec2698207423d7d7014922ccf3dea1267
783397 F20110403_AABVWW tian_j_Page_015.jp2
7692e757e4e9ea1787bc2d025090b99f
e394c6e7af16cb495a44f1909bd427353fa61b0e
7763 F20110403_AABWDF tian_j_Page_105thm.jpg
b44b080c5e5d166377171f94df3fe79b
b365cc836a66742acdeb5e56ea627a420dfdc9c6
7159 F20110403_AABWCR tian_j_Page_087thm.jpg
9ee67b46ae2eb4e020976ba44085849a
f592507c589aadbb27bf2d893a5fd8a7f851877b
958136 F20110403_AABVXM tian_j_Page_033.jp2
0a3a6438aa6a4122d4b229cb5b7a623d
4a8228381dd16e2f37b1c3c09f1e8b937e1d184b
1027711 F20110403_AABVWX tian_j_Page_017.jp2
9c8f334ae393982090be1f29002ee87f
fc201747d58239738522cfacdb33a707f869ef38
8303 F20110403_AABWDG tian_j_Page_106thm.jpg
eca07d4513293c3ebbd1e7bcc1b21847
6022dc89b88f83d415da44bf46c0b1fa3b0567f7
835624 F20110403_AABVYA tian_j_Page_052.jp2
bc6232791c11a97f48a19a45e194cf0a
bd7a47a5fd6daf992b81a92db9654e22a9f5e2d7
7227 F20110403_AABWCS tian_j_Page_088thm.jpg
9500a50372a6b3c0d837f6dba6dca105
d60f80d9b66f0662a2ba5407eba1ea733b37c0d2
981209 F20110403_AABVXN tian_j_Page_034.jp2
fcc65e8b1c2864fa6a38845851faf503
34df9fc5c643be33b5b50a1a5e8f5360b7026c6a
804928 F20110403_AABVWY tian_j_Page_018.jp2
000a73339ce11bd8da635b732054a7cb
f8a01452c5044c5b916ded36a8839e6554d995ed
2461 F20110403_AABWDH tian_j_Page_107thm.jpg
a7ec5d9c399597e4d36fbb1d5cf78e02
b0c4558aa4e5176401356d89bcf284897c748c47
1017869 F20110403_AABVYB tian_j_Page_054.jp2
97f6dfc2536a59ec08318448a6c42f25
65772d76fc6184820f9fcdce5d979cf1e6f7be25
7491 F20110403_AABWCT tian_j_Page_089thm.jpg
d3eb1b3c274d50c2ecfb1026551ebcfc
0aa7ef3630377a439305f892aad533d8b926b4b3
913183 F20110403_AABVXO tian_j_Page_038.jp2
6028f0169ed9390715338cbe51c6f34c
c506c437fcd3e9ca9bc3b136ec8801717faaa8f8
1051966 F20110403_AABVWZ tian_j_Page_019.jp2
7b3a7d029b89209001cf90b53709d56f
a009fa69bc491e6f2fbfd1e30af086af106504a0
98 F20110403_AABWDI tian_j_Page_002.txt
8285501987214aae4b5a87fead9010f2
6b2f5f4affa7b270d45a0db4a875cc885d186c6b
1033258 F20110403_AABVYC tian_j_Page_055.jp2
60ed8ffe2687e789ec94fa592b36af93
3e566fcb5a588e4d2c47de87a53905b8484237db
7203 F20110403_AABWCU tian_j_Page_091thm.jpg
8e1a9a3e35ffe3abaf20b5ec312001de
32c43d9038e0666e3c8f70d506ab40c778ec3358
2979 F20110403_AABWDJ tian_j_Page_003.txt
57605b87f651b0b505dd1aae5b6037da
1ac51717f4dd9b37d8b154386d3eada812ad5f46
956685 F20110403_AABVYD tian_j_Page_056.jp2
b381dbbc6554b3d0fdb116b2e2bd8f28
83a1b2ba3b5bedf39a8faf231bbf75e9618d1556
7669 F20110403_AABWCV tian_j_Page_092thm.jpg
ba2e5a791d008739e58bb913b6551ab6
1c2351df466473582dc61a385d092f8166e27869
3459 F20110403_AABWDK tian_j_Page_004.txt
1dac3469ad27fb658a7362d3e68a5255
29fdd3a6246791b9c6f2eaa9ac02ae901cf6df18
1051982 F20110403_AABVYE tian_j_Page_057.jp2
284ac86ab0f64a12de15ffea9c1223ae
ca14ee675b0bd9914c378ad340c2b1c10a19a6c0
8290 F20110403_AABWCW tian_j_Page_093thm.jpg
7e33e34bfbaff127ab0204b3501b0ea3
738884fc5ea3099a4613686eda8b2bb1f61b0b36
968318 F20110403_AABVXP tian_j_Page_039.jp2
642c61321fd6fe8bc972c113f29e6a29
ee07f2176ec7fc59219de3e4e54f753879bc32a5
721 F20110403_AABWDL tian_j_Page_005.txt
b24acbc192fe73df4265d43ee3ca672b
148f0a33439bdb7197a8488a817aaa3995b0c456
164541 F20110403_AABVYF tian_j_Page_058.jp2
f38880455cdc02ead836db2f6fa5a8f0
095d6776df94defed7659047700d812333de57ea
7418 F20110403_AABWCX tian_j_Page_095thm.jpg
0284e1a067b8826d92b62ef0d9798ea4
e94282bffed85d8284e89ff9cb53b8e98f8ab597
939284 F20110403_AABVXQ tian_j_Page_040.jp2
bafe75c6b78e058b4ab7a160b4834525
20edbf1b062bf99c3ec68c67ca71b569e0b8d7f2
1530 F20110403_AABWEA tian_j_Page_023.txt
d99a1509c19f238ac9e9e106ca7db0ee
63013747d61741e33c6336d8c481d6ad91557b8a
1962 F20110403_AABWDM tian_j_Page_007.txt
f986d293121402e3437f3eb9ed0a7df9
fbb397bc5152d25c221502a1e62df3fbd843cf5d
829975 F20110403_AABVYG tian_j_Page_059.jp2
510375d3d747d97d6e3bf3aec492c6dc
36842880370aa101f64da7f7f62ff190beff2917
5780 F20110403_AABWCY tian_j_Page_096thm.jpg
75a9bf1eb7b692dc39b1bbb2b9948698
3adaaa481f782fc9e6399eed8aaa1cb87ef9f6f3
999860 F20110403_AABVXR tian_j_Page_041.jp2
f4604b5b4b475600e96e1055ed5a1629
50bc30351076b85f6a6a53aac58db95eb79212ba
1919 F20110403_AABWEB tian_j_Page_024.txt
70ba4a395be89082b224daf2d33803d3
85b45b237b7b1e34c3c849b8657ec10e88c31c78
1739 F20110403_AABWDN tian_j_Page_008.txt
034848f211ef1b2b6029265815049fe8
99bca43e2956dbb97a4d11b93cd5d2fe4856b7f5
635032 F20110403_AABVYH tian_j_Page_061.jp2
9b701313b4ebbb99c00bbb30f17fcc06
2bbb17a886ccf601e23fd5832067f68d636fb696
707613 F20110403_AABVXS tian_j_Page_042.jp2
e8d895e2150cf7ac408b571ab5e275e8
eac9417f09210e1093ee26713f69b7b1cb1f6c14
1487 F20110403_AABWEC tian_j_Page_025.txt
b0bcc877d5578571161a1e0189844498
bb8a12f28063963abd2ddd2359aef734c6286398
F20110403_AABWDO tian_j_Page_009.txt
9ee118b81ad8cbeb3280e15ab32e576a
9c398b584473aff7da70724e3d13a1cb460da804
764470 F20110403_AABVYI tian_j_Page_062.jp2
c9b57335652fff078cc305f211914d72
b25ebdf1a8d0fc5c868922a8dcc338318818dc1d
4263 F20110403_AABWCZ tian_j_Page_098thm.jpg
26e810a8084097e907a2c535583ef26f
02d15e14d926bd0a2b73393266a66474ad743949
924265 F20110403_AABVXT tian_j_Page_044.jp2
a67c9324e2047124db6654e7defc6890
ac4b3c19ff4389cb44edf868884639aebc9123a6
1753 F20110403_AABWED tian_j_Page_026.txt
6bb83f479740728131186b06917cc798
9c5d708e3e2a6ec8415585acca1101fe65c82b8f
586 F20110403_AABWDP tian_j_Page_010.txt
67d125a64257f5a66341fce3a821d808
0636a07e7fa965375540413afeec8f6cef7c7d89
731297 F20110403_AABVYJ tian_j_Page_063.jp2
68871f1a54c8d082bbe3324801b21432
92af2a2914f8baeb6d0b586c92603d8b752e1a79
1051985 F20110403_AABVXU tian_j_Page_046.jp2
03c57e5ecb8076e06eb43f994a951873
068d13bf597531f103fbc4608e8344c05599495f
1598 F20110403_AABWEE tian_j_Page_027.txt
9ae0635f4cee026dab727ecf8c16eb9d
15328ffe0edafa3cb149eabcb28ace9433e5a9f7
F20110403_AABWDQ tian_j_Page_011.txt
5a08984670158274ae159983589c377d
81d10deaef2b5ff27eff00815d9d0e1623ef53f9
637354 F20110403_AABVYK tian_j_Page_064.jp2
b85c2cbb6914da940817427c87c774a1
172567f84aa154261628f26b11ea503e7c7100c9
F20110403_AABVXV tian_j_Page_047.jp2
e52963b376754e1f03e4500b8902d111
804d87d08cd7fcac3201a121886dc3c8ed6a9f40
1843 F20110403_AABWEF tian_j_Page_028.txt
88c37f83491c46b5a6501337ef173f54
1248ccdfefe52050326eb1a3bdc469a3d25166a6
1875 F20110403_AABWDR tian_j_Page_012.txt
2c303da50810a6abfc36bc6b4104a2a1
c4ff4df2988880ca074baa23a44820c62d9560c7
307809 F20110403_AABVYL tian_j_Page_065.jp2
f235383c8fc48209b23a7e4201338a65
5d1859414221b7c2ba60b2a9dabaf4b32b6eee35
1051979 F20110403_AABVXW tian_j_Page_048.jp2
17061f36ea3ce8fd54aceaf71919b4b3
cd761059e5ed187ed738e8fd5d998397d6330b8a
F20110403_AABWEG tian_j_Page_030.txt
9bd1f55e3b82b0ecbe4139bbd8ba36d9
201932c67ac5790a1b924a0a4b761a67a0e7484d
906307 F20110403_AABVZA tian_j_Page_083.jp2
e445a0d3719b038ab5896c6317f06ead
77e5d40e1e667cf4e1b00e61ef36eaa2a7ae8200
943 F20110403_AABWDS tian_j_Page_014.txt
c9930641ef2bb48ed0551c6487767932
b6c5a549950be84ec5006496357e4fabf4dd2257
374997 F20110403_AABVYM tian_j_Page_066.jp2
0231f77eab9bd8d6617618474c7a443a
c4addc38da5d59d5ff1ef8669648d2dc3439dcb2
667467 F20110403_AABVXX tian_j_Page_049.jp2
c9fdf1b56292da22bfc69af6491b695e
2191e044201ffdc0f4cb478992c52e6c98b3ca4a
F20110403_AABWEH tian_j_Page_031.txt
adc1464f3aca3326e854c07019d696b4
19743488133d7abc0c8fa1afa10dc971dca242c9
1046959 F20110403_AABVZB tian_j_Page_085.jp2
9b68a30d80086802b19b8799005dd4aa
b960cbf756d6ff28af6dc0bc322e78e6e085b1a5
1427 F20110403_AABWDT tian_j_Page_015.txt
00e7c04d508eb897e8bd08ae6f4e8996
6273c0450073914197d1f3360369940ba9db89c3
583702 F20110403_AABVYN tian_j_Page_067.jp2
44468fb924ada8227a776d72b205678d
c5c252bd4707d987bcaacc875f1240911cd974d7
1045692 F20110403_AABVXY tian_j_Page_050.jp2
a3b9ac0095f0fcced5dc2dfcc96863d8
eb6d51e7b81acbcc11c1684ebb5302ee411bcf72
1603 F20110403_AABWEI tian_j_Page_032.txt
ddf1f03d4d27aee618c4ab200abdceea
9c0da2758f92f73bd4c90ee9350c858120013b7e
1051934 F20110403_AABVZC tian_j_Page_086.jp2
22da3b5dceafd225f579e6e0cc250b5f
8eeb64de0c2695bea064ac2d95ab7214ba2d081e
1510 F20110403_AABWDU tian_j_Page_016.txt
610b2bf60a6d0709ec44f50db6620f30
f3a34a45945b6632e7c65ef53a2ca116342006cc
927880 F20110403_AABVYO tian_j_Page_068.jp2
e3b0d499ea2bd1a5f619fab97a702447
e118245f7847d22cddcbf1094dab8632ee8b4951
1050394 F20110403_AABVXZ tian_j_Page_051.jp2
cf430e298dc9c17c398199aa1001584e
ffb16f43e42c3d256a27e64e4412e9079b274995
1695 F20110403_AABWEJ tian_j_Page_033.txt
c33648a5c5ae369574d7e9638e0fabdb
183f22fbeec31a2d6ab10b0f05bfbcf23955c000
842459 F20110403_AABVZD tian_j_Page_087.jp2
87a3d1e080bf6dfbf34b1153c96917a0
8bf639ba4a85f22ba04b8008955161979f38bd9f
1781 F20110403_AABWDV tian_j_Page_017.txt
42ad2e3d2774bcc4c81bcee394028709
40c6ef4b585648a34354f37c86a3c90e4f1b3d55
337977 F20110403_AABVYP tian_j_Page_070.jp2
441965a7447b4cc6b0fe3895a775fe16
adbbb4c2745930ed3aab4bde776deb9034067aba



PAGE 1

A SPEED ADAPTIVE MOBILE INTERNET PROTOCOL OVER WIRELESS LOCAL AREA NETWORK By JUN TIAN A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2005

PAGE 2

Copyright 2005 by Jun Tian

PAGE 3

TABLE OF CONTENTS page LIST OF TABLES........................................................................................................vi LIST OF FIGURES.....................................................................................................vii ABSTRACT..................................................................................................................ix CHAPTER 1 INTRODUCTION................................................................................................1 2 RELATED WORK................................................................................................5 Network Layer Handoff Management..................................................................5 Mobile IP.........................................................................................................6 Agent Discovery.........................................................................................8 Registration...............................................................................................10 Tunneling..................................................................................................12 Hierarchical MIP...........................................................................................15 Cellular IP......................................................................................................16 Routing......................................................................................................17 Handoff.....................................................................................................17 Paging.......................................................................................................19 HAWAII.........................................................................................................20 Wireless LAN.....................................................................................................24 Technology Overview....................................................................................24 The IEEE 802.11 Established Standards.......................................................25 Standard 802.11.........................................................................................26 Standard 802.11b.......................................................................................28 Standard 802.11a.......................................................................................29 Standard 802.11g.......................................................................................31 Pending Specifications Within the 802.11 Suite.......................................33 The IEEE 802.11 Wireless LAN Architecture...............................................33 Wireless LAN Station...............................................................................34 Basic Service Set (BSS)............................................................................34 Independent Basic Service Set (IBSS)......................................................34 iii

PAGE 4

Infrastructure Basic Service Set(BSS)......................................................35 Extended Service Set (ESS)......................................................................35 Wireless LAN Handoff Management.................................................................35 Wireless LAN Handoff Management Frames...............................................35 IEEE 802.11 Handoff Procedure...................................................................37 Techniques to Reduce IEEE 802.11 Handoff Time.......................................39 Low Latency Handoff Mechanisms for MIP over 802.11 Network...................41 L2 Triggers.....................................................................................................42 Pre-Registration.............................................................................................42 Post-Registration............................................................................................43 Location Tracking...............................................................................................44 Other Related Work............................................................................................46 3 PERFORMANCE OF MIP OVER WLAN AT DIFFERENT SPEEDS.............49 MIP over Wireless LAN Handoff Procedure......................................................49 RAMON Testbed................................................................................................50 Hardware Architecture...................................................................................51 Software Architecture....................................................................................52 Performance Evaluation.....................................................................................53 Emulation Scenario and Result......................................................................53 Experimental Result Analysis........................................................................57 4 QUANTITATIVE ANALYSIS OF THE MIP OVER WIRELESS LAN HANDOFF LATENCY..........................................................................................................63 Layer 2 Handoff Latency....................................................................................63 Layer2 Movement Detection Phase...............................................................64 Layer2 AP Searching Phase...........................................................................65 Layer2 Reassociation Phase..........................................................................66 Layer 3 Handoff Latency....................................................................................66 Agent Discovery............................................................................................66 Registration....................................................................................................68 Layer 4 Handoff Latency....................................................................................69 Quantitative Analysis of the Handoff Latency...................................................70 5 SPEED ADAPTIVE MIP AND ITS PERFORMANCE EVALUATION...........73 Traditional MIP over WLAN Handoff Procedure..............................................73 Algorithm of Speed Adaptive MIP.....................................................................77 iv

PAGE 5

Implementation of Speed Adaptive MIP............................................................82 Home Agent...................................................................................................82 Mobile Node..................................................................................................84 Foreign Agent................................................................................................86 Evaluation of Speed Adaptive Extension for MIP.............................................87 6 SUMMARY AND FUTURE WORKS...............................................................90 LIST OF REFERENCES.............................................................................................91 BIOGRAPHICAL SKETCH.......................................................................................97 v

PAGE 6

LIST OF TABLES Table page 2-1 Characteristics specified by the 802.11 standard.........................................................28 2-2 Characteristics specified by the 802.11b standard.......................................................29 2-3 Characteristics specified by the 802.11a standard.......................................................31 2-4 Characteristics specified by the 802.11g standard.......................................................32 2-5 Comparison of characteristics specified within the IEEE 802.11 suite.......................33 3-1 Average throughput at different speeds and AP distances..........................................58 4-1 Handoff latency distribution of MIP over WLAN......................................................71 5-1 Average throughput for speed-adaptive MIP..............................................................89 vi

PAGE 7

LIST OF FIGURES Figure page 2-1 Macro and Micro mobility..........................................................................................6 2-2 Three functional entities of MIP.................................................................................8 2-3 IP in IP encapsulation and minimal encapsulation....................................................13 2-6 802.11 wireless LAN handoff procedure..................................................................39 3-1 RAMON testbed architecture....................................................................................51 3-2 Dynamic MIP sample scenario..................................................................................53 3-3 Time-sequence graph at speed 20m/s and AP distance 1000m.................................54 3-4 Throughput graph at speed 20m/s and AP distance 1000m......................................54 3-5 Time-sequence graph at speed 80m/s and AP distance 1000m.................................55 3-6 Throughput graph at speed 80m/s and AP distance 1000m......................................55 3-7 Time-sequence graph at speed 10m/s and AP distance 500m...................................56 3-8 Throughput graph at speed 10m/s and AP distance 500m........................................56 3-9 Time-sequence graph at speed 40m/s and AP distance 500m...................................57 3-10 Throughput graph at speed 40m/s and AP distance 500m......................................57 3-11 Average throughputs vs speeds...............................................................................59 3-12 Time-sequence graph at AP distance 1000m with speed 20m/s without handoff...60 3-13 Time-sequence graph at AP distance 1000m with speed 80m/s without handoff...60 3-14 Average throughput vs handoff rate........................................................................62 vii

PAGE 8

4-1 Handoff procedure with message exchange..............................................................67 4-2 LCS handoff latency for MIP....................................................................................67 4-3 ECS handoff latency for MIP....................................................................................68 4-4 Handoff procedure with handoff latency distribution...............................................72 5-1 Traditional MIP Handoff Procedure..........................................................................74 5-2 FA Set size vs handoff rate........................................................................................79 5-3 Normal vendor/organization specific extension........................................................80 5-4 SA-MIP handoff procedure.......................................................................................81 5-5 Function flowchart of registration in HA..................................................................84 5-6 Registration request message format.........................................................................85 5-7 Registration request message extension format........................................................85 5-8 Function flowchart of sending registration request...................................................86 5-9 Function flowchart for FA handling registration request..........................................87 5-10 Time-sequence graph at speed 60m/s and AP distance 1000m...............................88 5-11 Time-sequence graph at speed 80m/s and AP distance 1000m...............................88 5-12 Average throughput vs. handoff rate.......................................................................89 viii

PAGE 9

Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy A SPEED ADAPTIVE MOBILE INTERNET PROTOCOL OVER WIRELESS LOCAL AREA NETWORK By Jun Tian December 2005 Chair: Abdelsalam (Sumi) Helal Major Department: Computer and Information Sciences and Engineering. This dissertation presents two novel contributions in the area of mobile network communication. The first is the performance/moving speed relationship of Mobile Internet Protocol(MIP) over Wireless Local Area Network(LAN). In this dissertation, the rapid mobility of MIP over Wireless LAN is emulated on a testbed. The performance of MIP over Wireless LAN at different moving speeds is evaluated. The result shows that current MIP protocol is not suitable for rapid moving environments. This dissertation analyzes the emulation results and depicts the relationship between the performance and the moving speed of the mobile devices. This relationship is used in a novel protocol, which is the second contribution, to improve the performance of MIP over Wireless LAN in rapid moving environments. The second contribution is the Speed Adaptive Mobile IP. In the Speed Adaptive Mobile IP, Mobile Nodes registration message is extended by speed ix

PAGE 10

extension. With the speed information popularized in the mobile IP network, the behavior of the Speed Adaptive Mobile IP will automatically adapt to the speed of the Mobile Node so that the performance of the Speed Adaptive Mobile IP wont decline dramatically in a rapid moving environment. At the same time, the Speed Adaptive Mobile IP only uses reasonable resources that are enough for seamless handoff. The emulation result shows that the Speed Adaptive MIP greatly improves the performance of MIP over Wireless LAN in rapid-moving environments. x

PAGE 11

CHAPTER 1 INTRODUCTION The population living on the world wide internet is exploding. According to the analysis of Internet usage across more than 50 countries, the latest report from Computer Industry Almanac(CIA) Inc.'s shows that as of the end of March 2004, there are 945 millions of internet users world wide. The report also indicates 1.12 billion Internet users projected for the end of 2005, and 1.46 billion for 2007. A significant number will be using wireless devices such as Web-enabled cell phones and PDAs to go online. In America, 27.9% of 193 millions of internet users are using wireless internet. At the end of 2007, 46.3% of 263 millions will be wireless internet users. Throughout history, the economic wealth of people or a nation has been closely tied to efficient methods of transportation. The transportation speed is becoming faster and faster. A person can drive a car on high way at speed of 70mph. Some high speed trains such as France TGV, Japanese bullet, German maglev can travel at speeds of over 300km/hour(186mph). Could those people surf the internet, communicate with families and enjoy an online movie while traveling at high speeds? Could the current network infrastructure support rapid mobility? While TCP/IP successfully overcomes the barriers of time and distance in a wired network, mobile IP is a promising technology to eliminate the barrier of location for the 1

PAGE 12

2 increasing wireless internet usage. Third generation (3G) services combine high speed mobile access with IP-based services. With access to any service anywhere, anytime, from one terminal, the old boundaries between communication, information sharing, media distribution will disappear. 3G enables users to transmit voice, data, and even moving images whenever and wherever. But, 3G networks are not based on only one standard, but a set of radio technology standards such as cdma2000, EDGE and WCDMA. Mobile IP [Perk02] can be the common macro mobility management framework to merge all these technologies in order to allow mobile users to roam between different access networks. These radio technologies only need to handle Micro mobility issues such as radio specific mobility enhancements. Mobile IP is different from other efforts for doing mobility management in the sense that it is independent to any specific access technology[Mobi03]. Wireless local area networks (WLAN) have experienced incredible growth over recent years. WLANs provide wireless users with an always-on, wireless connection to each other, to local area networks (LAN), to wide area networks (WAN), and to the Internet. The major benefit of WLANs over wired network is its flexibility and mobility [Kapp02]. There are currently two major WLAN standards, and both operate using radio frequency (RF) technology. The two standards have heretofore been colloquially referred to as 802.11b and 802.11a. 802.11b operates in the radio frequency (RF) band between 2.4 and 2.485GHz while 802.11a operates between 5.15-5.35GHz and 5.725-5.825GHz. The performance of both 802.11b and 802.11a decreases as your distance from the antenna increases. This degradation is neither linear nor granular. Instead, each wireless

PAGE 13

3 specification has a handful of pre-defined bandwidth levels at which it can operate (802.11b has four, while 802.11a has seven). Take 802.11b as an example. Within a closed office, the bandwidth will drop from 11, 5.5, 2 to 1mbps when the distance increases from 25, 35, 40 to 50 meters. For outdoors, the bandwidth will drop from 11, 5.5, 2 to 1mbps when the distance increases from 160, 270, 400 to 550 meters. So if you want to keep a high throughput, you have to reduce the distance between access points. For example, to keep 5.5mbps when outdoors, the distance between two access points should be no more than 500 meters. The smaller the cell the higher the bandwidth you get. The use of current cellular/PCS high data rate services for data networking is not economically feasible due to high usage costs. The success of WLAN lies in the following factors. First, WLAN uses license-free band. 802.11b and 802.11g use Industrial, Scientific, and Medical (ISM) 2.4GHz radio band while 802.11a operates in the 5 GHz National Information Infrastructure (UNII) radio band. Second, WLAN offers reasonably high available data rates. 802.11b can transmit data up to 11 Mbps while 802.11g and 802.11a can provide data rate up to 54Mbps. Finally, there are lots of commercially available WLAN products around the world. Even though WLAN has been designed and used for mostly indoor applications, the possible use of WLAN technologies for high mobility outdoor applications, such as, telemetry, traffic surveillance, rescue operations, and outdoor data networking can provide reasonably high data rates at minimal operational costs. For outdoor applications WLANs provide support for link-layer handoff, which is used to switch a mobile node (MN) from one access point (AP) to another. For WLANs

PAGE 14

4 connected by an IP backbone, Mobile IP[Perk02] is the protocol for location management and network-layer handoff. These attractions led us to investigate the performance of MIP over WLAN in outdoor rapid moving environments. In this dissertation, Chapter 2 introduces related research in the area of mobile network protocols, wireless LAN standards, layer 3 and layer 2 handoff mechanisms and location tracking technologies. Chapter 3 introduces a protocol evaluation testbed, RAMON. The performance of MIP over wireless LAN and its relationship to speed are shown in Chapter 3 as well. Chapter 4 breaks down the handoff procedure of MIP over wireless LAN and presents a quantitative analysis of the handoff latency. A speed adaptive MIP protocol is proposed in Chapter 5 and the performance for this protocol is evaluated. Chapter 6 summarizes the dissertation and presents future works.

PAGE 15

CHAPTER 2 RELATED WORK Mobile computing and networking try to provide users confident accesses to the Internet anytime, anywhere. One big challenge for mobile computing and networking is how to manage global and seamless roaming among various access technologies. Mobility management contains two components: location management and handoff management [Akyi99]. In wireless network, there are two kinds of roaming, interdomain and intradomain roaming. Interdomain roaming, also called macromobility, refers to roaming among different domain of systems. Intradomain roaming, also called micromobility, refers to roaming among different cells in the same domain or system. In this chapter we will introduce network layer handoff management of macro/micro mobility, wireless LAN protocol standards and technologies to reduce handoff latency for wireless LAN and Mobile IP network. At the end of this chapter, some research works on location tracking will be introduced. Network Layer Handoff Management Macro Mobility protocols aim to handle global moving of users. An example is mobile IP[RFC3344]. Micro-mobility protocols are used to handle local moving (e.g., within a domain) of mobile hosts without interaction with the Mobile IP enabled internet. 5

PAGE 16

6 Hierarchical MIP, Cellular IP, IntraDomain Mobility Protocol(IDMP), HAWAII are examples of micro mobility protocols. Figure 2-1 shows the macro and micro mobility. Home Network INT ERNET FA Micro mobility handoff Macro mobility handoff Micr o mobility domain FA Home Network INT ERNET Micro mobility handoff Macro mobility handoff HA Figure 2-1 Macro and Micro mobility Mobile IP IP mobility support for IPv4 is specified in RFC3344. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. It allows a node to continue using its 'permanent' home address no matter where the node physically attached to. Therefore, ongoing network connections to the node can be maintained even as the mobile host is moving around the internet. Mobile IP defines three functional entities where its mobility protocols must be implemented: Mobile Node(MN), Home Agent(HA) and Foreign Agent(FA). MN is a movable device whose software enables network roaming capabilities. FA is a router that may function as the point of attachment for the MN when it roams to a foreign network, delivering packets from the HA to the MN. Mobile IP works by allowing the MN to be associated with two IP addresses: a home address and a dynamic,

PAGE 17

7 Care-of Address(CoA). Home address is fixed IP address the MN gets from its home network. The CoA is the termination point of the tunnel toward the MN when it is on a foreign network. CoA changes at each new point of attachment to the Internet. HA is a router on the home network serving as the anchor point for communication with the MN; it tunnels packets from a device on the Internet, called a Correspondent Node(CN), to the roaming MN. (A tunnel is established between the HA and a reachable point for the MN in the foreign network.). The HA maintains an association between the home IP address of the MN and its CoA, which is the current location of the MN on the foreign or visited network. The MNs movement is invisible to the CN. Figure 2-2 shows the three functional entities and routing of datagrams transmitted from a MN away from home. When a MN moves, it finds an agent on its local network by the Agent Discovery process. It listens for Agent Advertisement messages sent out by FAs or HAs. If it doesn't hear these messages it can sent Agent Solicitation message to ask for it. From the Agent Advertisement message, the MN determines whether it is on its home network or a foreign one. The MN works like any fixed node when its on its home network. When the MN moves away from its home network, it obtains a CoA on the foreign network. The MN registers each new CoA with its HA while away from home. This may be done either directly between the MN and the HA, or indirectly using the FA as a conduit. The packets from CN are tunneled by HA to FA then to the CoA. The packets from MN to CN are either directly routed to the CN or reverse-tunneled from FA to HA then to the CN.

PAGE 18

8 HA FA Global Internet MN CN Figure 2-2 T h ree functional entities of MIP MIP has three m a in processes, Agent discovery, registration and tunneling. Agent disco v ery The Mobile IP agent discovery process m a kes use of ICMP Router Advertisem ent Protocol(RFC 1256) and add one or more MI P extensions. H A s and FAs periodically broadcast a router advertisem ent ICMP m e ssa ges with an advertisem ent extension. The router advertisem ent portion of the m e ssage includes the IP addre ss of the router. The advertisem ent exten s ion include s add ition a l inf o r m ation such as lif t tim e, care of -addr ess, etc. A MN listens for these agent adv e rtisem ent m e ssages. If a MN needs to get a care-of address and does not want to wait fo r that l ong tim e, the MN can broadcast or m u lticast an agent so lic itation ( also a n ICMP m e ssage) a nd th en lis tens f o r the ag ent a dvertisem ent m e ssages. Another im portant rule of agent di scovery process is m ove m e nt detection. This can be done in two ways. One way is to m a ke use of Lifetim e field in the agent advertisem ent m e ssage. When a MN receives an agent adve rtisem ent from a FA that it is currently using or that it is now going to regist er to, it reco rds the lifetim e field as a tim e r If the tim er expires b e f o re th e agent receives ano t her adv e rt is em ent f r om the agen t, th en

PAGE 19

9 the node assumes that it has lost contact with that agent. In this situation, the MN may choose to wait for another advertisement or to send an agent solicitation. Another way is to use network prefix. The MN checks whether any newly received agent advertisement is on the same network as the current care-of address of the node. If it is not, the MN assumes that it has moved and uses the new advertisement. The MN can also get a collocated care-of-address acquired from a Dynamic Host Configuration Protocol (DHCP) server. In this case, the MN acts as its own FA. The agent advertisement extension consists of the following fields: Type: 16, indicates that this is an agent advertisement. Length: (6 + 4N), where N is the number of care-of addresses advertised. Sequence number: The count of agent advertisement messages sent since the agent was initialized. Lifetime: The longest lifetime, in seconds, that this agent is willing to accept a registration request from a mobile node. R: Registration required. Registration with this foreign agent (or another foreign agent on this link) is required even when using a co-located care-of address. B: Busy. The foreign agent will not accept registrations from additional mobile nodes. H: This agent offers services as a home agent on this network. F: This agent offers services as a foreign agent on this network. M: This agent can receive tunneled IP datagrams that use minimal encapsulation. G: This agent can receive tunneled IP datagrams that use Generic Routing Encapsulation (GRE). r: Set as zero; ignored on reception. T: Foreign agent supports reverse tunneling. Care-of Address(es): The care-of address or addresses supported by this agent

PAGE 20

10 Registration When a MN realizes that it is on a foreign network and has acquired a care-of-address, it needs to notify the HA by sending a registration request message so that the HA can forward IP packets between MN and CN. There are two kinds of registration messages, registration request and registration reply, both sent to User Datagram Protocol (UDP) port 434. The MN sends the request to the FA, which then relays the request to the home agent. If the MN is using a collocated care-of-address, the MN sends its request directly to the HA, using collocated care-of-address as the source IP address of the request. The registration request message consists of the following fields: Type: 1, indicates that this is a registration request. S: Simultaneous bindings. When set, the mobile node is requesting that the home agent retain its prior mobility bindings. The home agent will forward multiple copies of the IP datagram, one to each care-of address currently registered for this mobile node. B: Broadcast datagrams. Indicates that the mobile node would like to receive copies of broadcast datagrams that it receives if it were attached to its home network. D: Decapsulation by mobile node. The mobile node is using a collocated care-of address and will decapsulate its own tunneled IP datagrams. M: Indicates that the home agent should use minimal encapsulation. G: Indicates that the home agent should use GRE encapsulation.

PAGE 21

11 R: Sent as zero; ignored on reception. T: Reverse Tunneling requested. X: Set as zero; ignored on reception. Lifetime: The number of seconds before the registration is considered expired. A value of zero is a request for deregistration. Home address: The home IP address of the mobile node. Home agent: The IP address of the mobile node home agent. Care-of address: The IP address for the end of the tunnel. The home agent should forward IP datagrams that it receives with the mobile node home address to this destination address. Identification: A 64-bit number generated by the mobile node, used for matching registration requests to registration replies and for security purposes. Extensions: authentication extension must be included, and other optional extensions. The registration reply message consists of the following fields: Type: 3, indicates that this is a registration reply. Code: Indicates result of the registration request. 0 for registration accepted, 77 for invalid care-of address, etc. Lifetime: If the code field indicates that the registration was accepted, the number of seconds before the registration is considered expired. A value of zero indicates that the mobile node has been deregistered. Home address: The home IP address of the mobile node. Home agent: The IP address of the mobile node home agent. Identification: A 64-bit number used for matching registration requests to registration replies. Extensions: authentication extension must be included, and other optional extensions. The identification field of the registration request and reply messages and the authentication extension are used to protect replay attack. The Identification value enables

PAGE 22

12 the mobile node to match a reply to a request. Two methods are described in RFC 3344: timestamps mandatory ) and "nonces" (optional). An authentication extension consists the following fields: Type: Used to designate the type of this authentication extension. 32 for MN-HA, 33 for MN-FA, 34 for FA-HA. Length: 4 plus the number of bytes in the authenticator. Security parameter index (SPI): An index that identifies a security context between a pair of nodes. This security context is configured so that the two nodes share a secret key and parameters relevant to this association (for example, authentication algorithm). Authenticator: The value used to authenticate the message. The default authentication algorithm uses HMAC-MD5[RFC2104] to compute a 128-bit message digest of the registration message. Tunneling After a successful registration, the home agent must be able to intercept datagrams destined to the mobile node and tunnel them to the mobile nodes care-of-address. The tunneling can be done by one of several different encapsulation algorithms, IP in IP encapsulation [RFC2003], Minimal encapsulation [RFC2004] and GRE encapsulation [RFC1701]. By default, home agents and foreign agents must support tunneling datagrams using IP in IP encapsulation. Any mobile node that uses a collocated care-of address must support IP in IP encapsulation. In IP-within-IP encapsulation, the original entire IP datagram becomes the payload in a new IP datagram. The original IP header is unchanged except to reduce Time To Live (TTL) by 1. The outer IP header is a full IP header. Two fields are copied from the inner IP header: The version number, 4, which is the protocol identifier for IPv4, and the type of service field. Figure 2-3 is the IP in IP encapsulation and minimal encapsulation format.

PAGE 23

13 Figure 2-3 IP in IP encapsulation and minimal encapsulation Minimal encapsulation results in less overhead but is little complicated than IP in IP encapsulation. It can only be used if the MN, HA, and FA all agree to use it. With minimal encapsulation, a minimal forwarding IP header is inserted between the original IP header and the original IP payload. The original IP header is modified to form a new outer IP header. The minimal forwarding IP header includes the following fields: Protocol: Copied from the protocol field in the original IP header. It identifies the protocol type of the original IP payload. S: If 0, the original source address is not present, and the length of this header is 8 octets. If 1, the original source address is present, and the length of this header is 12 octets. Header checksum: Computed over all the fields of this header. Original destination address: Copied from the Destination Address field in the original IP header. Original source address: Copied from the Source Address field in the original IP header. This field is present only if the S bit is 1. The field is not present if the encapsulator is the source of the datagram.

PAGE 24

14 The new outer IP header is modified from the original IP header. The modified field are as following. Total length: Incremented by the size of the minimal forwarding header (8 or 12). Protocol: 55, indicts the following header is minimal IP encapsulation header. Header checksum: recomputed over all the fields of this header. Source address: The IP address of the encapsulator, typically the home agent. Destination address: The IP address of the end of the tunnel, the care-of address. Mobile IP is a macro mobility management protocol. MIP-based mechanisms use a flat hierarchy, whereby every change in the MNs point of attachment requires a global binding update. Frequent global binding updates can not only incur high latency, thereby making rapid handoffs impossible, but also significantly increase the overall signaling overhead, especially when the number of MNs increases. Various solutions have been proposed to solve this problem. All these solutions implicitly or explicitly use a concept of micro-mobility regions where registrations with the home agent are not necessary if the MN is moving within these regions. Only if the MN moves between micro-mobility regions, registrations with the HA would be required. Micro-mobility management protocols are designed to reduce the high handoff latency of Mobile IP by handling mobility within micro-mobility regions. The micro-mobility protocols can be categorized in two types: Hierarchical Tunneling and Mobile-Specific Routing [Camp02]. Hierarchical tunneling schemes rely on a tree-like structure of FAs. In Hierarchical tunneling schemes HA delivers encapsulated traffic to the root FA. Each FA on the tree decapsulates and then re-encapsulates data packets while they forward the data down the FA tree towards the

PAGE 25

15 MNs point of attachment. As the MN moves between two FAs, location updates are made at the optimal point in the tree, which is the common root of the two FAs. Hierarchical Mobile IP[Soli02]) is an example of Hierarchical tunneling scheme. Mobile-Specific Routing schemes avoid the overhead introduced by decapsulation and re-encapsulation in hierarchical tunneling schemes. These proposals use mobile specific routes to forward packets toward a MNs point of attachment. Examples of micro-mobility protocols that use mobile-specific routing include Cellular IP and HAWAII. Hierarchical MIP The Hierarchical Mobile IP (HMIP) employs a hierarchy of FAs to locally handle Mobile IP registration. In this protocol MNs send mobile IP registration request messages to update their respective location information. The Registration messages establish tunnels between neighboring FAs along the path from the mobile host to a gateway foreign agent(GFA). Packets addressed to mobile hosts travel through these tunnels from the GFA to MN. Figure 3-4 illustrates the operation of Hierarchical Mobile IP. The red dash arrow is a regional registration, which only need to reach a local entity, GFA. The blue real arrow is a normal F A H A F A F A F A F A F A INT E R N E T F A GFA MH F A MH MH CN Fi g ure 2-4Hierarchical MIP

PAGE 26

16 registration, which have to traverse the whole network to the HA. For the purposes of managing hierarchical tunneling the location register is maintained in a distributed form by a set of Mobility Agents (MA), i.e. GFAs. Each MA reads the original destination address of the incoming packets and searches its visitor list for a corresponding entry. The entry contains the address of the next MA one level lower in the hierarchy. Such entries are created and maintained by registration messages transmitted by MNs. [Soli02] Cellular IP The Cellular IP (CIP) protocol[Cam99] from Columbia University and Ericsson supports fast handoff and paging techniques. Cellular IP inherits features found in cellular networks, such as, seamless mobility, passive connectivity and paging, for mobile IP hosts. It uses Mobile IP to provide interconnectivity between a set of Cellular IP access networks, which in turn provide a cellular internetworking environment. The Cellular IP access networks will be connected to the Internet via gateway routers. In that case, host mobility between gateways(i.e., Cellular IP access networks) will be managed by Mobile IP, while mobility within access networks will be handled by Cellular IP. MNs attached to the network use the IP address of the gateway as their Mobile IP care-of address. The data packets from CN to MN will be first routed to MN's HA and then tunneled to the gateway. The gateway "detunnels'' packets and forwards them toward base stations. Inside the Cellular IP network, data packets are routed directly to the MN. Data packets from MN to CN are first routed in the cellular IP network to the gateway and from there on to the

PAGE 27

17 HA[Camp00]. The following presents an overview of the Cellular IP routing, handoff and paging algorithms Routing In Cellular IP, location management and handoff support are integrated with routing. To minimize control messaging, regular data packets transmitted by mobile hosts are used to refresh host location information. Uplink packets are routed from MN to the gateway on a hop-by-hop basis. The path taken by these packets is cached in base stations, which is call route cache. Cellular IP uses mobile originated data packets to maintain reverse path. This path is used to route downlink packets addressed to a mobile host. When the mobile host has no data to transmit then it periodically sends empty IP packets to the gateway to maintain its downlink routing state. The loss of downlink packets when a mobile host moves between access points is reduced by customized handoff procedures. Cellular IP supports two types of handoff scheme, hard handoff and semi-soft handoff. Handoff The Cellular IP hard handoff algorithm is based on simple approach that trades off some packet loss in exchange for minimizing handoff signaling. Hard handoff causes packet losses proportional to the round-trip time and to the downlink packet rate. Mobile hosts listen to beacons transmitted by base stations and initiate handoff based on signal strength measurements. To perform a handoff, a mobile host tunes its radio to a new base station and sends a route-update packet. The route-update message creates routing cache

PAGE 28

18 mappings on route to the gateway hence configures the downlink route to the new base station. Cellular IP semi-soft handoff exploits the notion that some mobile hosts can simultaneously receive packets from the new and old base stations during handoff. During semi-soft handoff a mobile host may be in contact with either the old and new Base Stations and receives packets from them. Packets intended to the mobile host are sent to both Base Stations, so when the mobile host eventually moves to the new location it can continue to receive packets without interruption. To initiate semi-soft handoff, the moving mobile host transmits a route-update packet to the new Base Station and continues to listen to the old one. The S flag is set in this route-update packet to indicate semi-soft handoff. Semi-soft route-update packets create new mappings in the Route and Paging Cache similarly to regular route-update packets. When the semi-soft route-update packet reaches the crossover node where the old and new path meet, the new mapping is added to the cache instead of replacing the old one. Packets sent to the mobile host are transmitted to both Downlink neighbors. When the mobile host eventually makes the move then the packets will already be underway to the new Base Station and the handoff can be performed with minimal packet loss. After migration the mobile host sends a route-update packet to the new Base Station with the S bit cleared. This route-update packet will remove all mappings in the Route Cache except for the ones pointing to the new Base Station. The semi-soft handoff is then complete. If the path to the new Base Station is longer than that to the old Base Station or if it takes non-negligible time to switch to the new Base Station,

PAGE 29

19 then some packets may not reach the mobile host. To overcome the problem, packets sent to the new Base Station can be delayed during semi-soft handoff. This way a few packets may be delivered twice to the mobile host, but in many cases this results in better performance than a few packets lost. Introduction of packet delay can be best performed in the Cellular IP node that has multiple mappings for the mobile host as a result of a semi-soft route-update packet. Packets that belong to flows that require low delay, but can tolerate occasional losses, should not be delayed. Semi-soft handoff minimizes packet loss providing improved TCP and UDP performances over hard handoff. Distinguishing idle and active mobile hosts reduces power consumption at the terminal side. The location of idle hosts is tracked only approximately by Cellular IP. Therefore, mobile hosts do not have to update their location after each handoff. This extends battery life and reduces air interface traffic. When packets need to be sent to an idle mobile host, the host is paged using a limited scope broadcast. A mobile host becomes active upon reception of a paging packet and starts updating its location until it moves to an idle state again. Paging If a mobile host has not received data packets for a system specific time active-state-timeout, it becomes idle. The idle mobile hosts allow their soft-state routing cache mappings to be time out. Idle hosts transmit empty IP packets(paging-update packets) at regular intervals(paging-update-time) to the gateway. Paging-update packets are sent to the base station that offers the best signal quality. Paging-update packets are

PAGE 30

20 also routed on a hop-by-hop basis to the gateway. Base stations may optionally maintain paging cache. A paging cache has the same format and operation as a routing cache except for two differences. First, paging cache mappings have a longer timeout period called paging-timeout. Second, paging cache mappings are updated by any packet sent by mobile hosts including route-update packets and paging-update packets. This results in idle mobile hosts having mappings in paging caches but not in routing caches. If the base station has no paging cache, it will forward the packet to all its interfaces except for the one the packet came through. Paging cache is used to avoid broadcast search procedures found in cellular systems. Base stations that have paging cache will only forward the paging packet if the destination has a valid paging cache mapping and only to the mapped interface(s)[Camp00]. HAWAII The Handoff Aware Wireless Internet Infrastructure (HAWAII) protocol [Ramj99][Ramj02] proposes a separate routing protocol to handle intra-domain mobility. All issues related to mobility management within one domain are handled by a gateway called a domain root router. A MN entering a new foreign agent domain is assigned a collocated care-of address. The MN retains its care-off address unchanged while moving within the foreign domain, thus the HAs does not need to be involved unless the MN moves to a new domain. In this case, packets for the MN are intercepted by its HA first. The HA tunnels the packets to the domain root router serving the MN. The domain root router routes the packets to the MN using the host-based routing entries. When the

PAGE 31

21 MN moves between different subnets of the same domain, only the route from the domain root router to the BS serving the MN is modified, and the remaining path remains the same. Thus, during an intra-domain handoff, the global signaling message load and handoff latency are reduced. HAWAII path setup messages There are three types of HAWAII path setup messages: powerup, path refresh, and path update. On power up a mobile host sends a Mobile IP registration request message to the corresponding base station. The base station then sends a HAWAII path setup power-up message to the domain root router which is processed in a hop-by-hop manner. This has the effect of establishing host specific routes for that mobile host in the domain root router and any intermediate routers on the path towards the mobile host. The domain root router finally acknowledges this path setup power-up message to the base station which finally notifies the mobile host with a Mobile IP registration reply. If a router knows multiple paths to the domain root router, it can use any of them but it always has to use the same route for a specific host. The routing entries in the routers are soft-state, i.e. they have to be refreshed periodically by path setup refresh messages, which are sent independently by each network node and which can be aggregated. This increases the robustness of the protocol to router and link failures. The mobile host infrequently sends periodic path refresh messages to its base station to maintain the host based entries. The base station and the intermediate routers, in turn, send periodic aggregate hop-by-hop refresh messages towards the domain root router. Path setup messages are sent to only

PAGE 32

22 selected routers in the domain, resulting in very little overhead associated with maintaining soft-state. While the mobile host moves within a domain, maintaining end-to-end connectivity to the mobile host requires special techniques for managing user mobility. HAWAII uses path setup update messages to establish and update host-based routing entries for the mobile hosts in selective routers in the domain so that packets arriving at the domain root router can reach the mobile host with limited disruption. The choice of when, how, and which routers are updated constitutes a particular path setup scheme. HAWAII Path Setup Schemes The HAWAII handoff procedures are only activated when the mobile hosts next hop IP node is changed during the handoff. [Ramj02] assumes base stations have IP routing functionality and uses a tree-based topology for clarity, but the schemes will also provide for non-tree-based topologies. [Ramj99] defines two schemes for implementing Handoff procedures within the domain, the forwarding and the non-forwarding scheme. The cross-over router is defined as the router closest to the mobile host that is at the intersection of two paths, one between the domain root router and the old base station, and the second between the old base station and the new base station. Non-forwarding path update scheme The non-forwarding path set-up is a two way Update handshake process. It is initiated by the Mobile Station sending an Update to the new Base Station. The path setup

PAGE 33

23 Update message consists of the Mobile Station IP address, the old and new Base Station address, and some other informations. The following is the algorithm: Step 1: Update the Cache with the combination of the IP address of the Mobile Station and the port on which the Update was received. This builds an element in a reverse chain in the direction from the current node towards the new Base Station. If the current node is the old Base Station, it sends an acknowledgement to the Mobile Station directly via the air interface. This completes the procedure and the old Base station will not receive further datagrams for the Mobile Station. The path from the gateway to the new Base Station will be refreshed, the rest (from the Crossover router to the old Base Station) will not and times out shortly. Step 2: (recipient is not the old Base Station) The node extracts the forwarding port for the old Base Station from the routing table, and forwards the Update. Step 1 is then revisited. Forwarding path update scheme The forwarding path set-up is initiated by the Mobile Station. Its also a two way Update handshake process. The Mobile Station sends the old Base Station an Update message, which consists of the Mobile Station IP address, the old and new Base Station addresses, and some other informations. The following is the algorithm: Step 1: If the node receiving the Update is the new Base Station, it sends an acknowledgement to the Mobile Station directly via the air interface, and updates the Cache with the IP address and port number for the Mobile Station. This completes the

PAGE 34

24 procedure, leaving two Soft-state paths. One leading from the old to the new Base Station, and the other from the gateway, via the Crossover router, to the new Base Station. The second path will be refreshed while the first will time out shortly. Step 2: (recipient is not the new Base Station) The node extracts the forwarding port for the new Base Station from the routing table, and updates the Cache with the IP address of the Mobile Station and this port number. Step 1 is then revisited. The Forwarding path set-up scheme packets in transit towards the old router are then forwarded from the Old Base Station to the new Base Station until the flow is diverted at the Crossover router. The non-forwarding scheme is optimized for networks where the Mobile Station can listen/transmit to multiple base stations simultaneously, as in the case of Code Division Multiple Access (CDMA) networks. The forwarding scheme is optimized for networks where the Mobile Station can listen/transmit to only one base station, as in the case of a Time Division Multiple Access (TDMA) network. Both schemes ensure no BSS internal loss of in transit datagrams during handoff. Wireless LAN Technology Overview Over recent years, the market for wireless communications has experienced incredible growth. Wireless technologies have quickly found a significant place and popularity in business and the computer industry. Their major motivation and benefit is increased flexibility and mobility. Unlike a wired LAN, which requires a wire to access the network, a Wireless LAN connects computers and other components to the network via an

PAGE 35

25 Access Point (AP). Wireless LANs offer several fundamental benefits including user mobility, rapid installation, flexibility and scalability. However, there are some primary limitations [Gast02]. The speed of wireless networks is constrained by the available bandwidth. Radio waves can suffer from a number of propagation problems that may interrupt the radio link, such as multi-path interference and shadows. On Wire LAN, sniffing is much easier because the radio transmissions are designed to be processed by any receiver within range. Security is still a prime concern. The IEEE 802.11 Working Group was formed in September of 1990. Their goal was to create a wireless LAN specification that will operate in one of the Industrial, Scientific, and Medical frequency(ISM) ranges. The first 802.11 standard was released in 1997. The latest version is the 1999 edition. The official name of 802.11 is IEEE Standards for Information Technology -Telecommunications and Information Exchange between Systems -Local and Metropolitan Area Network -Specific Requirements -Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. The 802.11 protocols address the Medium Access Control (MAC) and Physical (PHY) layers independently. The MAC layer handles moving data between the link layer and the physical medium. Figure 2-5 shows how the OSI model matchs up to the 802.11 standards. The 802.11 Established Standards The 802.11 suite has the four established standards: 802.11, 802.11b, 802.11a and 802.11g. The IEEE is continuing to work on new standards that will extend the physical layer options, improve security, and add quality of service (QoS) features. In the following several sections, we will brief introduce these four standards [80211].

PAGE 36

26 Session Tr a n s p o r t Network Data Link Physical Lo g ical Link Control Medium Access (MAC) Physical (PHY) Presen tatio n App licatio n ISO/OSI 7-layer model IEEE 802.11 Fi g ure 2-5OSI model vs.IEEE802.11 standard Standard 802.11 802.11 was the first IEEE standard used for wireless data networking applications with maximum data transfer rates at 2 Mbps in the 2.4 GHz radio band. Within 802.11, two different modulation schemes are supported that can be used to transmit data signals. The first modulation scheme is frequency-hopping spread spectrum(FHSS). This transmission technique is used in WLAN transmissions where the data signal is modulated with a narrowband carrier signal that hops in a random sequence from frequency to frequency as a function of time over a wide band of frequencies. This technique reduces the chances of interference. The other modulation scheme is direct-sequence spread spectrum (DSSS). In this method of transmission, the signal does not hop from one frequency to another but is passed through a spreading function and distributed over the entire band at once. DSSS

PAGE 37

27 usually provides slightly higher data rates and shorter delays than FHSS, because the transmitter and receiver don't have to spend time retuning. DSSS avoids interference by configuring the spreading function in the receiver to concentrate the desired signal but spread out and dilutes any interfering signal. A data signal at the sending station is combined with a higher data rate bit sequence, or chipping code, that divides the user data according to a spreading ratio. The chipping code, a redundant bit pattern for each bit that is transmitted, increases the signals resistance to interference. If one or more bits in the pattern are damaged during transmission, the original data can be recovered due to the redundancy of the transmission. Although the 802.11 standard supports both modulation schemes, the two types of spread spectrum technologies are not compatible. The number of channels used by 802.11 compliant products depends on the modulation scheme used. More specifically, FHSS-based products use 79 channels of the Unlicensed National Information Infrastructure (UNII) band, whereas DSSS-based products use either 3 non-overlapping channels or 6 overlapping channels of the Industrial, Scientific, and Medical (ISM) radio band. Some of the common characteristics specified by the 802.11 standard are listed in Table 2-1.

PAGE 38

28 Table 2-1 Characteristics specified by the 802.11 standard Characteristic 802.11 Description Application Wireless data networking Data Rate 12 Mbps Typical Operating Frequency Band ISM band: 2.4 to 2.4835 GHz. Modulation Mechanism FHSS or DSSS, CRC-16 in header Channels available 79 channels with FHSS; 3 or 6 channels with DSSS Coverage 40m to 400m Mobility Roaming between APs by mobile IP Security 128-bit WEP Link Layer Carrier Sense Multiple Access With Collision Avoidance (CSMA/CA) with request to send (RTS)/clear to send (CTS) Standard 802.11b IEEE 802.11b[80211b] is the first enhancement 802.11 standard to be ratified in 1999. 802.11b uses the same radio signaling frequency(2.4GHz) as the original 802.11 standard. The 802.11b standard specifies operation on three channels in the 2.4.4835 GHz spectrum. 802.11b can transmit data up to 11 Mbps but will scale down to 1 Mbps based on conditions. 802.11b uses DSSS modulation scheme to transmit data signals through the 11 available channels(3 non-overlapping). This unlicensed portion of the radio band shares space with many low-power signals from home electronics, including microwave ovens, cordless telephones, Bluetooth-enabled devices, and garage-door openers. 802.11b compliant products have a range of up to 400 meters in ideal conditions and will be compatible with the products that meet the new 802.11g standard when it is finalized. Some of the key characteristics specified by the 802.11b standard are shown in Table 2-2.

PAGE 39

29 Table 2-2 Characteristics specified by the 802.11b standard Characteristics 802.11b Description Application Wireless data networking Data Rate (Mbps) 1, 2, 5.5, 11 Typical Operating Frequency Band ISM band: 2.4 to 2.4835 GHz Channels available 11 (3 non-overlapping) Modulation Mechanism DSSS Coverage (m) 40 to 400 Mobility Roaming between APs by mobile IP devices Security 128 bit WEP Link Layer CSMA/CA with RTS/CTS Pros of 802.11b lowest cost; signal range is best and is not easily obstructed. Cons of 802.11b Speed and channel restriction are significant limitations of 802.11b compliant networks. Interference within ones own 802.11b network becomes more likely as the number of users and APs increase. Similarly, interference is more likely as 802.11b compliant networks are deployed near each other. 802.11b products share the bandwidth with other low-power signals, and thus, problems may arise when the technology is used near some electronic devices such as microwave ovens, Bluetooth-enabled devices, and cordless telephones. Standard 802.11a 802.11a[80211a], a High-speed Physical Layer in the 5 GHz band standard for WLANs, was completed in September 1999. It is offered in the 5 GHz radio (UNII) band, and operates on 8 channels; however, the available radio spectrum in some countries permits the use of 12 channels. The additional number of channels used in the higher spectrum yields less interference from neighboring APs. The Federal Communications Commission (FCC) has divided the total of 300 megahertz (MHz) frequencies used by

PAGE 40

30 802.11a WLANs into 3 distinct 100 MHz domains, each with a different legal maximum power output. The low band operates in the 5.15.25 GHz range and has a maximum output power of 50 milliwatts (mW). The middle band is located in the 5.25.35 GHz range, with a maximum of 250 mW. The high band uses the 5.725.825 GHz range, with a maximum of 1 Watt. Because of the high power output, most devices transmitting in the high band are building-to-building bridge products. The low and medium bands are more suited to in-building wireless products. 802.11a transfers data at rates of up to 54 Mbps in the available radio spectrum, which is up to five times faster than 802.11b compliant networks. More commonly, however, 802.11a compliant networks communications are at the 6 Mbps, 12 Mbps, or 24 Mbps data rates. As the distance between the user and the AP increases, the data rate decreases. 802.11a compliant networks use Orthogonal Frequency Division Multiplexing (OFDM) modulation to provide these data rates. OFDM is a type of digital modulation in which a signal is divided into separate channels at different frequencies. Table 2-3 show the major characteristics of 802.11a standard. Pros of 802.11a speed as 5 times as 802.11b; supports more simultaneous users; regulated frequencies prevent signal interference from other devices Cons of 802.11a shorter range signal that is more easily obstructed; shorter range costs more APs to cover the same area as an 802.11b network; consume more power than 802.11b products.

PAGE 41

31 Table 2-3 Characteristics specified by the 802.11a standard Characteristic 802.11a Description Application Wireless data Networking Data Rate (Mbps) 6, 9, 12, 18, 24, 36, 48, and 54 Mbps. Rates of 6, 12, and 24 Mbps are mandatory for all products. Typical Operating Frequency Band UNII band: 5.15-5.25 GHz, 5.25-5.35 GHz, and 5.725-5.825 GHz Channels Available 12 non-overlapping Modulation Mechanism OFDMOrthogonal Frequency Division Multiplexing Coverage (m) < 100 Mobility Roaming between APs by mobile IP devices Security 128-bit WEP, 64-bit WEP, 152-bit WEP Link Layer CSMA/CA with RTS/CTS 802.11a was ratified after 802.11b was already penetrating the market, so even though it offers higher speed and frequency, it may not be worth the switch for users who have already invested in 802.11b technology. Because 802.11a and 802.11b utilize different frequencies, the two technologies are incompatible with each other. Some vendors offer hybrid 802.11a/b network gear, but these products simply implement the two standards side by side. 802.11g IEEE 802.11g was ratified as a standard in Jun. 2003. It operates in the same 2.4 GHz range as 802.11b but offers the same speed up to 54 Mbps as 802.11a does. This standard features increased data transmission rates while maintaining interoperability with 802.11b compliant products. The standard uses the same modulation scheme OFDM as 802.11a to achieve data rates from 22 Mbps to up to 54 Mbps; however, 802.11g products will be backward compatible with 802.11b products that use the modulation scheme DSSS. The backward compatibility feature allows an 802.11b compliant client adapter

PAGE 42

32 card to interact directly with an 802.11g compliant AP. Communications between 802.11g and 802.11b devices are limited to data rates up to 11 Mbps. The common characteristics specified by the 802.11g standard are shown in Table 2-4. Table 2-4 Characteristics specified by the 802.11g standard Characteristics 802.11g Description Application Broadband Wireless LAN Access Data Rate (Mbps) 6, 9, 12, 18, 24, 36, 48, 54 Typical Operating Frequency Band ISM band: 2.4 to 2.4835 GHz Channels available 3 non-overlapping Modulation Mechanism OFDM/DSSS Coverage (m) 20 to 400 Mobility Roaming between APs by mobile IP devices Security 128 bit WEP Link Layer CSMA/CA with RTS/CTS Pros of 802.11g fast speed as up to 54mbps; supports more simultaneous users; signal range is better than 802.11a and is not easily obstructed Cons of 802.11g costs more than 802.11b; just like 802.11a, appliances may interfere on the unregulated signal frequency when the technology is used near some electronic devices such as microwave ovens, Bluetooth-enabled devices, and cordless telephones. Table 2-5 provides a comparison of the primary 802.11 standards.

PAGE 43

33 Table 2-5 Comparison of characteristics specified within the IEEE 802.11 suite Characteristics 802.11 802.11a 802.11b 802.11g Spectrum Band ISM: 2.4 to 2.4835 GHz UNII: 5.15-5.25 GHz, 5.25-5.35 GHz, and 5.725-5.825 GHz ISM: 2.4 to 2.4835 GHz ISM: 2.4 to 2.4835 GHz Modulation Scheme FHSS or DSSS OFDM DSSS OFDM or DSSS Number of Channels (non-overlapping) 79 channels with FHSS; 3 or 6 channels with DSSS 12 3 3 Optimum Data Rates (Mbps) 2 54 11 54 Range (meters) 400 100 400 400 Date established July 1997 September 1999 July 1999 June 2003 Compatibility 802.11 only 802.11a 802.11b 802.11b/g Operability North America, Europe, Asia North America, Europe, Asia North America, Europe, Asia North America, Europe, Asia Pending Specifications Within the 802.11 Suite IEEE 802.11a, 11b, 11g are major standard of wireless networking. There are various other standards which were developed to improve the transmission of data and promote the effective communication. The following are current standards which enhance and expand the functionality of the overall 802.11 protocol.[STD802] IEEE 802.11c: Defines wireless bridge operations IEEE 802.11d: Defines standards for companies developing wireless products in different countries. IEEE 802.11e: Defines enhancements to the 802.11MAC for QoS. IEEE 802.11f: Defines Inter Access Point Protocol (IAPP) IEEE 802.11i: Improved encryption IEEE 802.11j: 802.11 extension used in Japan. IEEE 802.11n: New standard expected to be completed in 2005 that is expected to support up to 100Mbps.

PAGE 44

34 The IEEE 802.11 Wireless LAN Architecture The 802.11 architecture is comprised of several components and services that interact to provide station mobility transparent to the higher layers of the network stack. The major components and services in Wireless LAN are as followings [Jain03]. Wireless LAN Station The wireless LAN station (STA) is the most basic component of the wireless network. A station is any device that implements the MAC and PHY functionality of the 802.11 protocol. Typically the 802.11 functions are implemented in the hardware and software of a network interface card (NIC). A station could be a laptop PC, PDA, or an Access Point. Stations may be mobile, portable, or stationary and all stations support the 802.11 station services of authentication, de-authentication, privacy, and data delivery. Basic Service Set (BSS) 802.11 defines the Basic Service Set (BSS) as the basic building block of an 802.11 wireless LAN. The BSS consists of a group of stations. The Topologies could be Independent Basic Service Set (IBSS), Infrastructure Basic Service Set(BSS) or Extended Service Set (ESS) Independent Basic Service Set (IBSS) The most basic wireless LAN topology is a set of stations, which have recognized each other and are connected via the wireless media in a peer-to-peer fashion. This form of network topology is referred to as an Independent Basic Service Set (IBSS) or an Ad-hoc network. In an IBSS, the mobile stations communicate directly with each other. Every

PAGE 45

35 mobile station may not be able to communicate with every other station due to the range limitations. There are no relay functions in an IBSS therefore all stations need to be within range of each other and communicate directly. Infrastructure Basic Service Set(BSS) An Infrastructure Basic Service Set is a BSS with a component called an Access Point (AP). The access point provides a local relay function for the BSS. All stations in the BSS communicate with the access point and no longer communicate directly. All frames are relayed between stations by the access point. This local relay function effectively doubles the range of the IBSS. Extended Service Set (ESS) An extended service set is a set of infrastructure BSSs, where the access points communicate among themselves to forward traffic from one BSS to another to facilitate movement of stations between BSSs. Wireless LAN Handoff Management Wireless LAN Handoff Management Frames The 802.11 standard defines various frame types that stations (NICs and APs) use for communications, as well as managing and controlling the wireless link. Every frame has a control field that depicts the 802.11 protocol version, frame type, and various indicators for WEP is on/off, power management is on/off, etc. In addition all frames contain MAC addresses of the source and destination station, a frame sequence number, frame body and frame check sequence (for error detection). 802.11 control frames assist in

PAGE 46

36 the delivery of data frames between stations. Data frames carry protocols and data from higher layers within the frame body such as RTS, CTS, ACK. Management frames enable stations to establish and maintain communications. Here we only introduce the management frames which relative directly to handoff management. [Jim01] Authentication frame: 802.11 authentication is a process whereby the access point either accepts or rejects the identity of a radio NIC. The NIC begins the process by sending an authentication frame containing its identity to the access point. With open system authentication (the default), the radio NIC sends only one authentication frame, and the access point responds with an authentication frame as a response indicating acceptance (or rejection). With the optional shared key authentication, the radio NIC sends an initial authentication frame, and the access point responds with an authentication frame containing challenge text. The radio NIC must send an encrypted version of the challenge text, using its wired equivalent privacy (WEP) key, in an authentication frame back to the access point. The access point ensures that the radio NIC has the correct WEP key (which is the basis for authentication) by seeing whether the challenge text recovered after decryption is the same that was sent previously. Based on the results of this comparison, the access point replies to the radio NIC with an authentication frame signifying the result of authentication. Deauthentication frame: A station sends a deauthentication frame to another station if it wishes to terminate secure communications. Association request frame: 802.11 association enables the access point to allocate resources for and synchronize with a radio NIC. A NIC begins the association process by sending an association request to an access point. This frame carries information about the NIC (e.g., supported data rates) and the SSID of the network it wishes to associate with. After receiving the association request, the access point considers associating with the NIC, and (if accepted) reserves memory space and establishes an association ID for the NIC. Association response frame: An access point sends an association response frame containing an acceptance or rejection notice to the radio NIC requesting association. If the access point accepts the radio NIC, the frame includes information regarding the association, such as association ID and supported data rates. If the outcome of the association is positive, the radio NIC can utilize the access point to communicate with other NICs on the network and systems on the distribution (i.e., Ethernet) side of the access point. Reassociation request frame: If a radio NIC roams away from the currently associated access point and finds another access point having a stronger beacon

PAGE 47

37 signal, the radio NIC will send a reassociation frame to the new access point. The new access point then coordinates the forwarding of data frames that may still be in the buffer of the previous access point waiting for transmission to the radio NIC. Reassociation response frame: An access point sends a reassociation response frame containing an acceptance or rejection notice to the radio NIC requesting reassociation. Similar to the association process, the frame includes information regarding the association, such as association ID and supported data rates. Disassociation frame: A station sends a disassociation frame to another station if it wishes to terminate the association. For example, a radio NIC that is shut down gracefully can send a disassociation frame to alert the access point that the NIC is powering off. The access point can then relinquish memory allocations and remove the radio NIC from the association table. Beacon frame: The access point periodically sends a beacon frame to announce its presence and relay information, such as timestamp, SSID, and other parameters regarding the access point to radio NICs that are within range. Radio NICs continually scan all 802.11 radio channels and listen to beacons as the basis for choosing which access point is best to associate with. Probe request frame: A station sends a probe request frame when it needs to obtain information from another station. For example, a radio NIC would send a probe request to determine which access points are within range. Probe response frame: A station will respond with a probe response frame, containing capability information, supported data rates, etc., when after it receives a probe request frame. IEEE 802.11 Handoff Procedure An IEEE 802.11 Handoff occurs when a STA moves out of the range of one AP, and enters another BSS. During the handoff, management frames are exchanged between the station (STA) and the AP. Also the APs involved may exchange certain context information (credentials) related to that STA via Inter Access Point Protocol(IAPP). The handoff procedure can be divided to two steps[Mish03] [Shin04], discovery and reauthentication. Discovery: this step involves the handoff initiation phase and the scanning phase. When the STA is moving away from the current AP, the signal strength and the

PAGE 48

38 signal-to-noise ratio of the signal may degrade and initiate the scanning phase. Scanning is to try to find a new available AP to associate with. There are two can of scanning mode: passive or active. In passive scanning mode, the STA listens to each channel of the wireless medium for beacon frames broadcasted by AP. Using the information obtained from beacon frames the STA can elect to join an AP. In active scanning, apart from listening to the beacon frames, the STA send probe request frames on each channel and listens to probe responses from the APs. The basic procedure of the active scanning includes the following steps [80211], as summarize by[Shin04] : Using the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) channel access mechanism gain control of wireless medium. broadcast a probe request frame. Start a probe timer. Listen to the channel for probe responses. If no response has been received by minChannelTime, scan next channel. If one or more responses are received by minChannelTime, stop accepting probe responses at maxChannelTime and process all received responses. Repeat the above steps to scan next channel. After all channels have been scanned, all information received from probe responses are processed so that the STA can select one AP to associate. Reauthentication: The reauthentication process involves authentication and reassociation to the new AP. The STA sends a authentication request to the new AP, informing the AP of its identity. The new AP sends back an authentication response, indicating acceptance or rejection. After successful authentication, the STA sends a reassociation request to the new AP and waits for a reassociation response containing an acceptance or rejection notice. Figure 2-6, taken from [Shin04], shows the IEEE 802.11 handoff process.

PAGE 49

39 Figure 2-6 802.11 wireless LAN handoff procedure Techniques to Reduce IEEE 802.11 Handoff Time A lot of researches have been done to analyze and reduce the handoff latency of wireless LAN. [Mish03] conducts experiments to accurately measure the handoff latency in an in-building wireless network. The measurements are done on two co-existing wireless networks, and using three wireless NICs from different vendors. It analyzes the handoff latencies by breaking down the whole process into discovery and reauthentication phases to assess the contribution of each phase to the handoff latency. The experiment results show that the discovery phase (scanning time) is the most time consuming part of the handoff process, taking over 90% of the total handoff latency. The variations in the

PAGE 50

40 probe-wait time account for the large variations in the overall handoff latency. The reauthentication phase contributes only a few milliseconds. [Mish04] use of an efficient data structure, neighbor graphs, which dynamically captures the mobility topology of a wireless network as a means for pre-positioning the stations context ensuring that the stations context always remains one hop ahead. This caching mechanism is based on the IAPP protocol in order to exchange the client context information between neighboring APs. The cache in the AP is built using the information contained in an IAPP Move-Notify message or in the reassociation request sent to the AP by the client. By exchanging the client context information with the old AP, the new AP does not require the client to send its context information in order to reassociate, hence reducing the reassociation delay.Its experimental and simulation results show that the use of neighbor graphs cache reduces the layer 2 handoff latency due to reassociation by an order of magnitude from 15.37ms to 1.69ms. [Kim04] propose a selective scanning algorithm which depends on the use of neighbor graphs. This approach requires changes in the network infrastructure and use of IAPP. The scanning delay is defined as the duration taken from the first Probe Request message to the last Probe Response message. This definition does not take into consideration the time needed by the client to process the received probe responses. [Shin04] also propose a selective scanning algorithm and a caching mechanism. This caching data structure is maintained at the client side and no changes are required in the existing network infrastructure or the IEEE 802.11 standard. All the required changes are

PAGE 51

41 done on the client side wireless card driver. And [Shin04] considers the time required for processing the probe responses received by the client. This processing time represents a significant part of the scanning delay especially when the number of probe responses received increased significantly. Sangheon Pack and Yanghee Choi in [Par02] and [Park02] proposed a fast handoff scheme using the pre-authentication method based on IEEE 802.1x model. In their proposal, when a mobile host handoff, it performs authentication procedures not only for the current AP but for a set of multiple APs. Multiple APs are selected using a Frequent Handoff Region (FHR) selection algorithm considering users' mobility patterns and their service classes. The FHR is a set of adjacent APs. It is determined by the APs' locations and users' movement patterns. Namely, the FHR consists of APs with which mobile hosts are likely to communicate to in the near future. Since a mobile host is authenticated for FHR in advance, the handoff latency due to the reauthentication can be minimized. Low Latency Handoff Mechanisms for MIP over 802.11 Network. The HMIP, Cellular IP (CIP)[Cam99] and (HAWAII) [Ramj02] protocol we talked in Section 2 of this chapter are handoff management protocols without considering underlying layers. This clean separation between Layer 2 and Layer 3 protocol stack allows those protocols to run on most layer2 technologies. The disadvantage of this clean separation is lower performance. In MIP over wireless LAN network, the MN may only keep connectivity with one AP, hereby one FA. So the MN can only start the registration process after completion of the L2 handoff. [Malk02] proposed two mobility protocols,

PAGE 52

42 pre-registration and post-registration, that aim at low latency Layer 3 handoff based on Layer 2 information or called Layer2 trigger. In pre-registration, MN may communicate with the new FA while still being connected with the old FA. In post-registration, the data can be delivered to the MN at the new FA before the registration process has completed. Here we briefly depict these two method summarize by [Blon04]. L2 Triggers A L2 trigger is a signal related to the L2 handoff process. There are there kind of L2 triggers mentioned in [Malk02]: anticipation triggeran early notice of an upcoming change in the L2 point of attachment of the MN. Line Down trigger (L2-LD)indicates that the L2 link between the MN and the old AP is lost. Line Up trigger (L2-LU)indicates that the L2 link between the MN and the old AP is established. A trigger initiated at the old FA is referred as a source trigger and a trigger initiated at the new FA is referred as a target trigger. Pre-Registration Pre-Registration allows the old FA and new FA to utilize information from layer 2 (the L2 "trigger") to set up a kind of "pre-registration" prior to receiving a formal Registration Request from the Mobile Node.. The network assists the MN in performing an L3 handoff before the L2 handoff is completed. Both the MN (mobile-initiated) and the FAs (network-initiated) can initiate a handoff.

PAGE 53

43 A mobile-initiated handoff occurs when the L2 anticipation trigger is received at the MN informing it that it will shortly move to the nFA. The L2 trigger contains information such as the nFAs IP address identifier. A network-initiated handoff can be initiated by a source trigger at the oFA (source-initiated handoff) or by a target trigger at the nFA (target-initiated handoff). A source-initiated handoff is initiated at the oFA by a received L2 trigger that informs the oFA of a MNs upcoming movement from oFA to nFA. A target-initiated handoff is initiated at the nFA by a received L2 trigger that informs the nFA of a MNs upcoming movement from oFA to nFA. Post-Registration The Post-Registration handoff method is based on a network-initiated model of a handoff. The Post-Registration occurs after the L2 handoff has been completed. This approach uses a bi-directional edge tunnel (BET) to perform a low latency change in the L2 point of attachment of the MN without requiring any involvement of it. A handoff occurs when the MN moves from the oFA, where the MN performed a Mobile IP registration, to the nFA. The MN delays its registration with the nFA, while maintaining connectivity using the BET between the oFA and nFA. There are two different Post Registration handoff schemes, Source and Target Trigger Post Registration, depends on what kind of L2 is using. An FA becomes aware that a handoff is about to occur at L2 through the use of an L2 trigger. Two types of triggers can be received: a source trigger at the oFA and a target trigger at the nFA.

PAGE 54

44 The FA receiving the trigger sends a Handoff Request (HRqst) to the other FA. The FA receiving the HRqst sends a Handoff Reply (HRply) to the first FA. This establishes a BET. The L2-LD (Link Down) trigger at the oFA and at the MN signals that the MN is not connected anymore with the oFA. When the oFA receives the L2-LD trigger, it begins forwarding the MN packets through the forwarding tunnel to the nFA. When the nFA receives the L2-LU (Link Up) trigger, it begins delivering packets tunneled from the oFA to the MN and forwards packets from the MN. When the MN receives the L2-LU, it decides to initiate the Mobile IP Registration process with the nFA by soliciting an Agent Advertisement or continues using the BET. Once the Registration process is complete (through the exchange of a Regional Registration Request and a Regional Registration Reply with the GFA), the nFA replaces the role of oFA. Location Tracking The ability to determine a users location in an existing 802.11 wireless network can provide many useful services for wireless users. Such services include: location sensitive content delivery, such as being able to send documents to a vicinal printer; creation of real-time roadmap, asset tracking (locating a valuable device), etc. Some location mechanisms use additional devices such as GPS, some not. The Global Positioning System (GPS) is a worldwide radio-navigation system consists of a constellation of 24 satellites and their ground stations. GPS uses these "man-made stars" as reference points to calculate positions accurate to a matter of meters. In fact, with advanced forms of GPS the accuracy can be better than a centimeter[Trim04].

PAGE 55

45 A GPS device, through triangulation of multiple signals received and determination of propagation (how long it took the signal to go from the satellite to the GPS device), is able to accurately determine a users location to within a meter. The problem with GPS is that the device must have a clear line of sight between itself and the satellite. This means the technology is unusable in heavily forested areas, urban environments with tall buildings and indoor environments. Some works has been done to use the popular 802.11 network infrastructure to determine the user location without using any extra hardware. Generally, suck kind of system needs to measure the signal quantity as a function of distance and one or more reference point such as the APs in the wireless LAN. The signal strength decays logarithmically with distance in an open space. But in indoors, the wireless channel is very noisy and the radio frequency (RF) signal can suffer from reflection, diffraction, and multipath effect [Yous03], which makes the signal strength a complex function of distance. To overcome this problem, WLAN location determination systems may constructs radio-maps during offline by sampling the signal at selected locations in the area of interest and tabulate the complex function. When the system need to determine the location, the vector of samples received from each access point is compared to the radio-map and the nearest match is returned as the estimated users location. [Yous04] divided the radio map-based techniques into two broad categories: deterministic techniques and probabilistic techniques. Deterministic techniques, such as RADAR system in [Bahl00] and Location Information Privacy Model in [Smai01],

PAGE 56

46 represent the signal strength of an access point at a location by a scalar value, for example, the mean value, to estimate the user location. Probabilistic techniques measure the signal quantity as a function of distance from the APs and store information them into a radio map and use probabilistic techniques to estimate users location. [Cast01] [Ladd02] [Roos02] [You04] [You03] are all using probabilistic techniques. RADAR, An In-Building RF-based User Location and Tracking System, was developed in Microsoft Research. In RADAR, the signal strength is measured when transmitting beacon packet between the mobile host and AP. They take sample of radio signals and build up a radio map for the area interested during offline phase. RADAR uses 3 APs as reference point of its location, which is called triangulation. During location phase, it matchs the real time signal strength with the radio map and determines the users location. The match is done by linear search. Horus system from the University of Maryland is an RF-based location determination system [You04] [You03]. It is implemented in the context of 802.11 wireless LANs. The system uses the stored radio map to find the location that has the maximum probability given the received signal strength vector. In [Yous04], they also proved formally that probabilistic techniques give more accuracy than deterministic techniques. Other Related Work IEEE802.11 standard was originally devised to replicate in a wireless fashion the structures of the wired LANs. Only recently the idea of utilizing IEEE802.11 technology

PAGE 57

47 for high mobility scenarios has been taken into account and the range of WLAN based applications has been enriched. In [Mani03], Pierpaolo Bergamo from UCLA and Don Whiteman from NASA, experimentally studied the behavior of an IEEE802.11 wireless network when the nodes are characterized by mobility up to the speed of 240 km/h. The authors studied the survivability and the performance of a connection under various aggressive mobility conditions. These studies may be adapted for data telemetry from mobile airborne nodes to fixed networks or between airborne nodes. In [Sing02], authors assessed the performance of WLANs in different vehicular traffic and mobility scenarios. The network throughput and the quality of the wireless communication channel, measured on IEEE 802.11b compliant equipment, are observed to degrade with increasingly stressful communication scenarios. [Amic02] presents a project using a WiFi-like network for military telemetry applications. For military telemetry, aircrafts and/or cars equipped with IEEE802.11 enabled devices will communicate with a fixed backbone infrastructure. The authors of [Amic] focused on aspects like frequency selection and network security. In [Thor], authors developed their own frequency hopping transceiver working at 900 MHz for telemetry purposes. In [Bamb], authors assured through analytical considerations that these kinds of transceivers can guarantee an impressive tolerance to rapid moving environments. A review on recent research on MIP shows a great amount of efforts contributed to reducing MIP handoff latency. Malki [Malk02] proposed two mobility protocols, preand post-registration, using L2 trigger. In preregistration, MN may communicate with both oFA and nFA. In post-registration, data are cached in nFA before the registration is completed. Fast-handover [Kood02] for Mobile IPv6 network combines the about two methods. But they all depend on L2 information. S-MIP[Hsie03], uses MN location and

PAGE 58

48 movement patterns to instruct the MN when and how handoff should be carried out. [Wijn04] also uses MNs movement model to predict handoff. But all these efforts didnt consider the speed factor of MN, which may cause problems when the MN moving rapidly.

PAGE 59

CHAPTER 3 PERFORMANCE OF MIP OVER WLAN AT DIFFERENT SPEEDS MIP over Wireless LAN Handoff Procedure MIP over wireless LAN provides more flexibility and mobility to mobile IP network. Unlike a traditional wired mobile IP network, which requires a wire to connect a computer to the network, wireless LAN users can access IP network from nearly anywhere without losing connectivity. Mobile IP is designed independently for all Layer 2 technologies, so it can run on any layer 2 infrastructures. But such kind of independency also costs more overhead. Figure 3-1 is the handoff procedure of MIP over two wireless LAN. When a MN moves from wireless LAN1 to wireless LAN2, it performs a layer2 802.11b handoff between Access Point 1 (AP1) and Access Point 2(AP2). After the layer2 handoff, the MN begins a layer3 handoff, which is MIP handoff. Suppose there is a communication, for example a TCP stream, between MN and CN. After the layer2 and layer3 handoff, it will require a significant time interval to recover the communication. This time internal is called layer4 handoff latency, which is also a part of the whole handoff cost. Equation 1 gives the life-cycle of MIP over wireless LAN handoff procedure: Fi g ure 3-1 MIP handoff 49

PAGE 60

50 t handoff = t L2handoff + t L3handoff + t L4handoff (Equation 1) Where t handoff is the total handoff latency of MIP over wireless LAN, t L2handoff t L3handoff t L4handoff are the handoff cost of Layer2, Layer3 and Layer4 separately. In the following section, we introduce an emulation testbed, RAMON, which is used to evaluation the performance of MIP over WLAN and to analyze the handoff latency of the MIP handoff procedure. RAMON Testbed In order to evaluate the performance of MIP over WLAN, we build up a MIP emulator RAMON[Hern02] RAMON is a Rapid Mobile Network emulator. Its a testbed combining software and hardware components to produce a realistic experimentation environment that can test the behavior and performance of actual mobile systems. The testbed provides the wireless and wired infrastructure to allow experimental testing of wireless and wired mobile network protocols. Figure 3-2 is the architecture of RAMON. RAMON consists of a Pentium II pc as Emulator, a circuit board as Controller, three JFW Industries Attenuators with Antennas, three Cisco 350 Access Points, three FAs, a HA and one or more MNs. All the FAs, HA and MN, which are the major entities of MIP, are running Linux kernel 2.4.20 and are installed with HUT dynamic MIP implementation version 0.8.1. The Attenuators are program controllable devices. The Emulator manipulates the Attenuators by the Controller to control the signal strength coming out from the Access Points. By increasing or decreasing the signal strength of one AP, we can emulate the MN moving towards to or away from the AP. By varying the increasing or

PAGE 61

51 decreasing speed of the signal strength, we can emulate the speed change of the MN. The emulation program running on the emulator can dynamically change the IP addresses for each AP and FA so that every physical AP(and FA) in Figure. 3-2 can emulator multiple logical AP(and FA) in Figure 3-3. Antenna1 FA1 AP1 192.168.1.1 HUB1 192.168.1.3 Attenuator1 Antenna2 Figure 3-1 RAMON testbed architecture Hardware Architecture The hardware architecture of RAMON includes two PCsone is emulator, one is home agent o The emulator has four Ethernet cards. IP addresses are Eth0: 192.168.1.2 mask 255.255.255.0 Eth1: 192.168.2.2 mask 255.255.255.0 Eth2: 192.168.3.2 mask 255.255.255.0 Eth3: 192.168.4.2 mask 255.255.255.0 Controller FA2 AP2 192.168.2.1 HUB2 192.168.2.3 Attenuator2 COM Antenna3 FA3 192.168.3.1 HUB3 AP3 192.168.3.3 Attenuator3 Emulator 192.168.1.2 192.168.2.2 192.168.3.2 192.168.4.2 COM 192.168.4.1 HA 10.3.3.14 Internet MN 192.168.4.5

PAGE 62

52 o The HA has two Ethernet cards. IP address are Eth0: 10.3.3.14 mask 255.255.255.0 Eth1: 192.168.4.2 mask 255.255.255.0 3 IBM ThinkPad laptopsas 3 foreign agents o FA1 : eth0: 192.168.1.1 mask 255.255.255.0 o FA2 : eth0: 192.168.2.1 mask 255.255.255.0 o FA3 : eth0: 192.168.3.1 mask 255.255.255.0 3 CISCO AIRONET 350 Aps, IP addresses are o AP1: 192.168.1.3 o AP2: 192.168.2.3 o AP3: 192.168.3.3 o The backup configuration files of these 3 APs are saved in the emulator. 3 Omnidirectional 3dbi Cushcraft Antennas one control boardcontrol the attenuator to emulate the signal fading 3 JFW Industries 50p-1230 Attenuators one Laptop-as mobile host o MN eth0: 192.168.4.5 Software Architecture Emulator: o Linux Kernel 2.4.7-10. o Modules IPIP o Script emulator to create Virtual interfaces and routing table o Emulation object file to run the emulation HA: o Dynamics HUT mobile IP home agent package: dynhad. o NAT o Modules IPIP FA: o Dynamics HUT mobile IP foreign agent package: dynfad. o Modules IPIP o Script FA1, FA2, FA3. simulate the action of foreign agents. o DynX.1 dynfad.conf configure files. MN: o Dynamics HUT mobile IP foreign agent package: dynmnd. o Dynmnconf1 dynmnd.conf configure file. o Tcpdump to capture data o Ethereal tool for analysis.

PAGE 63

53 Performance Evaluation Emulation Scenario and Result Using RAMON, we emulate HUT dynamic MIP in the following scenario in Figure 3-3: Figure 3-2 Dynamic MIP sample scenario In this scenario, a rapid moving MN will travel trough 8 APs. Each AP is wired to a FA. The distance between every two APs is d= 250m, 500m or 1000m. The moving speed of MN is V, varying from 10m/s to 80m/s. In our experiments, we used ftp to transfer a large file from the CN to the MN. During the ftp transfer, we tracked down TCP sequence numbers by using the tool tcpdump. We analyze the tcpdump data by using ethereal. Here we only give the experiment results for d = 500m and 1000m, v = 10m/s to 80m/s. Figure 3-4 and figure 3-5 are the time-sequence graph and throughput graph at speed 20m/s and AP distance 1000m. Figure 3-6 and 3-7 shows the time-sequence graph and throughput

PAGE 64

54 graph at speed 80m/s and AP distance 1000m. Figure 3-8 to figure 3-11 are those graphs at speed 10m/s, AP distance 500m and speed 40m/s, AP distance 500m. Figure 3-3 Time-sequence graph at speed 20m/s and AP distance 1000m Figure 3-4 Throughput graph at speed 20m/s and AP distance 1000m

PAGE 65

55 Figure 3-5 Time-sequence graph at speed 80m/s and AP distance 1000m. Figure 3-6 Throughput graph at speed 80m/s and AP distance 1000m.

PAGE 66

56 Figure 3-7 Time-sequence graph at speed 10m/s and AP distance 500m. Figure 3-8 Throughput graph at speed 10m/s and AP distance 500m

PAGE 67

57 Figure 3-9 Time-sequence graph at speed 40m/s and AP distance 500m. Figure 3-10 Throughput graph at speed 40m/s and AP distance 500m. Experimental Result Analysis To compare the performance of MIP/ WLAN at different speeds and different AP distances, we list the experiment data in table 3-1. In the table, the bytes transferred are the total bytes transferred from when the MN enters the first cell to when it moves out of the last cell. The average throughput is calculated by dividing bytes transferred by travel time.

PAGE 68

58 The total handoff time is the summary of the handoff latency of 7 times handoffs. The effective time is the time for effectively transferring data, which equals to the travel time minus the total handoff time. Table 3-1 shows the average throughput drops when the MNs speed goes up. At the same speed of 20m/s, the average throughputs are 196.97kB/s for d=1000m and 167.172kB/s for d=500m. At the speed of 40m/s, the average throughputs are 167.512kB/s for d=1000m and 93.877kB/s for d=500m. The table shows that if we double the speed and at the same time double the AP distance, the average throughput shows no suggestive difference. For example, at the speed of 40m/s and AP distance 1000m the average throughputs is 167.512kB/s. At the speed of 20m/s and AP distance500m the average throughputs is 167.172kB/s. Table 3-1 Average Throughput at Different Speeds and AP Distances. Speed (m/s) AP distance (m) Bytes transferred (kB) Travel Time (s) Average throughput (kB/s) Total handoff time(s) Effective time(s) PMaxavg (kB/s) Handoff Rate (FAs/s) 20 1000 78000 396 196.970 58 338 232.5 0.02 40 1000 33000 197 167.512 57 140 234.31 0.04 60 1000 16700 130.5 127.969 56 74.5 234.07 0.06 80 1000 9200 98.5 94.359 57 41.5 232.673 0.08 10 500 78500 397 197.733 58 339 233.01 0.02 20 500 33100 198 167.172 56 142 234.4 0.04 30 500 16600 129 128.682 56 73 232.86 0.06 40 500 9200 98 93.877 58 40 232.8 0.08

PAGE 69

59 The analysis of table 1 also shows: (1). The total handoff time doesnt change with speed. (2). Effective-time/total-travel-time ratio drops when the speed goes up. This is the reason why higher speed has lower throughput. Figure 3-12, the average throughput vs. speed graph, gives a more obvious view of this conclusion. Figure 3-11 Average throughputs vs speeds. In order to figure out the relationship between the performance of MIP over wireless LAN and the moving speed, we measured the throughputs of MIP over wireless LAN at different moving speeds and AP distances when there are no handoffs. We call this throughput, PMaxavg, the maximum average throughput without handoff. Here we only give the time-sequence graph at AP distance 1000m with speed 20m/s(left) and 80m/s(right). From figure 3-13, we get PMaxavg = 93000kB / 400s = 232.5 kB/s. From the right graph of figure 3-14, we get PMaxavg = 23500kB / 101s = 232.673 kB/s. The PMaxavg at different moving speeds and AP distances are listed in table 1.

PAGE 70

60 Figure 3-12 Time-sequence graph at AP distance 1000m with speed 20m/s without handoff Figure 3-13 Time-sequence graph at AP distance 1000m with speed 80m/s without handoff Let Pavg Average throughput Pmaxavg Average throughput without handoff Ttravel Total travel time

PAGE 71

61 Teffective Total effective time for ftp transmission Thandoff Total handoff time while traveling Khandoff The number of handoffs while traveling thandoff Average handoff time among 7 times of handoff Then, Pavg = (Pmaxavg / Ttravel ) x Teffetive = Pmaxavg (Ttravel Thandoff )/ Ttravel = Pmaxavg (1 Thandoff / Ttravel) = Pmaxavg( 1 Khandoff x thandoff / Ttravle) = Pmaxavg( 1 (Khandoff / Ttravle ) x thandoff )) Since thandoff doesnt change, The change of Pavg is caused by Khandoff/Ttravel ratio. We define MN handoff rate as rh = v/d, which is the ratio of the MNs speed and the cell size(AP distance). It means that how many APs or FAs the MN hands over in one second. rh is also equal to Khandoff / Ttravel. The relationship between the performance of MIP/WLAN and the moving speed is presented in Equation 2: Pavg = Pmaxavg( 1 rh x thandoff )) Equation 2 Where Pavg is the average throughput for the MN; PMaxavg is the average throughput without handoff. thandoff is the average handoff time for each handoff procedure.

PAGE 72

62 Since thandoff doesnt change, the change of Pavg is caused by handoff rate rh. At handoff rate 0.02 FAs/s, the average throughput is 197.35 kB/s. When the handoff rate goes up to 0.08 FAs/s, the average throughput drops to 94.118 kB/s. The graphs in Figure 3-12 can be combined into graph in Figure 3-15. Kbytes/sec 200 Figure 3-14 Average throughput vs handoff rate This chapter shows that the performance of MIP over WLAN is depends on the MNs handoff rate. In Chapter 5, we will propose an idea of how to make use of this throughput/handoff-rate relationship to improve the performance of MIP over wireless LAN in rapid moving environment. In the following chapter, we will take a deep view of the handoff latency by breaking down the handoff procedure of MIP over wireless LAN. 80 100 160 140 120 180 0 0.02 0.04 0.06 0.08 Handoff rate FA/s

PAGE 73

CHAPTER 4 QUANTITATIVE ANALYSIS OF THE MIP OVER WIRELESS LAN HANDOFF LATENCY Equation 1 in Chapter 3 shows that the life-cycle of MIP over wireless LAN handoff is the summary of Layer2, Layer3 and Layer4 handoff latency. In the following sections, we analyze the handoff characters of each layer and provide a quantitative analysis of the MIP over wireless LAN handoff latency. Layer 2 Handoff Latency In the case of IEEE 802.11b WLAN, Layer2 handoff is the change of APs. It causes an interruption of data frame transmission. Buffering and routing update make the handoff time for uplink and downlink traffic different. Some researches have been done to even this difference[El-Ho00][Ren99]. In our experiments, we only concern the downlink handoff time. In [Vela04], Hector Velayos splitting the Layer2 handoff time into three sequential phases: detection, search and execution. In our experiment, we also split it into three parts and name them as: movement detection, AP searching and reassociation. The Layer2 handoff involves three participating entities, the station(here is the MN), an old AP(oAP) and a new AP(nAP). The oAP is the access point which the station had layer2 connectivity prior to the handoff, while the nAP is the access point to which the station gets layer2 connectivity after the handoff. The handoff process among 2 APs also includes information exchanges. This information typically consists of the stations 63

PAGE 74

64 credentials and accounting information. The message exchange between APs can be done by Inter Access Point Prototcol(IAPP)[11F03] or via a proprietary protocol. The following is a detail analysis of three phases of Layer 2 handoff. Layer2 Movement Detection Phase In oAPs coverage, the station keeps frame transmission. There are three reasons for frames lose: collision, radio signal fading, or oAP is out of range. The station first assumes the lost frame is cause by collision. In 802.11b standard, collision is handled by Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) protocol. CSMA/CA is a basic protocol used to avoid signal collision and canceling. It works by requesting authorization to transmit for a specific amount of time prior to sending information. When collision happens, the sending device broadcasts a Request To Send (RTS) frame with information on the length of its signal. If the receiving device permits it at that moment, it broadcasts a Clear To Send (CTS) frame. Once the CTS is transmitted, the sending machine transmits its information. Any other sending device in the area that hears the CTS realize another device will be transmitting and allow that signal to go out uncontested. If the station tried to retransmit several times and still unsuccessful, then it assumes signal fading. This time the station sends out probe requests to probe the link. After several probe requests and without any response, the station assumes oFA is out of range and begin AP searching phase. In figure 10, from TCP point of view, when MN receives the last TCP package, it responses with TCP ACKnowledgement. After several

PAGE 75

65 unsuccessful transmission of TCP ACK, the MN assumes the oAP is out of range and starts a new AP searching phase. Layer2 AP Searching Phase After the station assumes oAP is out of range, it tries to find new potential APs to associate to. This is done by 802.11b MAC layer function: SCAN. There are two methods of scanning, active and passive. In passive scanning, the station listen to each channel for beacon frames(broadcasted periodically by APs every 10ms). The station takes note of the corresponding signal strengths while scanning. The beacons contain information about the AP, including service set identifier (SSID), supported data rates, etc. The station can use this information along with the signal strength to compare APs and decide upon which one to chose. In active scanning, the station broadcasts a probe request frame and waits for response. The time to wait for responses depends on the channel status. If the channel is idle during MinChannelTime, the station can receive prove response form the AP on that channel. If there is any traffic during this time, the station will wait for MaxChannelTime to allow the data in the channel be transmitted and wait for APs response. After gathers several response from APs in range, the station will compare and choose one to associate to. Active scanning enables a station to receive immediate response from APs, without waiting for beacon frames. However, it imposes additional overhead on the network. In our experiment, only after got 3 probe responses from an AP, the station regards that AP is stably in range. This is a default configuration of Orinoco Wireless card.

PAGE 76

66 Layer2 Reassociation Phase After choose one AP in phase 2, the station sends out a reassociation request to nAP. If the nAP can get the credentials and other state information from oAP through IAPP, there is no Authentication message exchange between the station and nAP. Or else, the station will send out authentication request to the nAP and wait for response. After authentication, nAP reassociates the station and sends reassociation response back. The above three phases complete Layer2 handoff. The layer2 handoff latency can be expressed in Equation 3. t L2handoff = t L2detection + t L2seraching + t L2reassociation (Equation 3) Where t L2detection t L2seraching and t L2reassociation are the time costs for Layer2 movement detection, Layer2 AP searching and Layer2 reassociation. Figure 4-1 shows these three phases in green arrows and are indexed as L2. Layer 3 Handoff Latency Only after the layer 2 link has been established, could the Layer 3 handoff starts, because the MN can only communicate with the FA on the same link. The Layer 3 handoff involves 2 phases, agent discovery and registration. Agent Discovery The well know agent discovery algorithms are Lazy Cell Switching(LCS) and Eager Cell Switching(ECS)[Perk98].

PAGE 77

67 Figure 4-1 Handoff procedure with message exchange Figure 4-2 LCS handoff latency for MIP The LCS method is a reactive handoff initiation strategy. In LCS the MN keeps receiving Agent Advertisement messages from the oFA and refreshes the lifetime of the CoA and stays in the original network until it moves and loses contact with oFA for the duration of three advertisement(FA broadcast Agent Advertisement message every 1

PAGE 78

68 second), which means oFA becomes unreachable. A handoff will be initiated if a nFA is discovered after this moment. If the nFA hasnt been discovered before the oFA becomes unreachable, the handoff latency will be much higher. An advantage of the LCS is to reduce the frequency of handoff when the MN hangs around among several FA. As to MIP over WLAN, because the MN can only keep physical link with one FA, the new agent cant be discovered before the old agent becomes out of range. Figure 4-2 is the LCS handoff latency plot for MIP. ECS is a proactive initiation strategy. It dictates an immediate MIP handoff as soon as a new agent is discovered. ECS is effective for the moving patterns that the MN rarely change its moving direction. Figure 4-3 is the ECS handoff latency plot for MIP. Figure 4-3 ECS handoff latency for MIP Registration When a MN realizes that it is on a foreign network and has acquired a care-of-address from the nFA, it needs to notify the HA so that the HA can forward IP

PAGE 79

69 packets between MN and CN. This is done by registration. The registration process involves four steps. The MN sends a registration request to nFA. The nFA relays this request to the GFA or HA. The HA either accepts or denies the request and sends a registration reply to nFA. If it accepts the request, it will build a tunnel downward to nFA(if FA decapsulation is used). The nFA relays this reply to the MN. If the registration reply is positive, it will build a tunnel upward to HA or GFA. If the MN is using a collocated care-of-address, it will register directly with the HA, which is not the case in this paper. The layer3 handoff latency can be splitted into Equation 4[Fiko01]. Figure 4-1 shows these two phases in red arrows and are indexed as L3. t L3handoff = t mipagentdicovery + t mipregistration (Equation 4) Layer 4 Handoff Latency TCP is a connection-oriented, end-to-end reliable protocol designed to support error recovery and flow control. Reliability is insured by a sliding-window acknowledgement and retransmission mechanism. All data sent by TCP must be acknowledged by the receiver. TCP maintains a variable-sized window of data that is unacknowledged for a given time. If the window is full, no data will be sent until an acknowledgement is received. TCP maintains a Retransmission Time Out (RTO) timer. If no ACK has been received when the RTO timer expired, TCP assumes that the data has lost and retransmits all of the data in the window. The retransmission follows the exponential back-off algorithm. According to this algorithm TCP doubles the timeout value on unsuccessful

PAGE 80

70 successive retransmissions[Hsie03]. In our case, during the Layer2 and layer3 handoff, the TCP doubles the retransmission timeout value several times. So even after the layer2 and layer3 handoff is over, TCP still have to wait for RTO to timeout to recover the retransmission. In figure 4-1, the dash blue arrows depict the TCP retransmission interval has been doubled. This latency is cost by TCP exponential back-off algorithm. So we call it TCP back-off delay ttcp-back-off. We define t L4handoff = ttcp-back-off (Equation 5) Quantitative Analysis of the Handoff Latency According Equation 1, 2, 3 and 4, the handoff latency distribution for MIP over WLAN is show in Equation 6. t handoff = t L2detection + t L2seraching + t L2reassociation + t mipagentdicovery + t mipregistration + ttcp-back-off ( Equation 6) We used RAMON introduced in Section 3 to emulate the same scenario as in Section 3. We did 20 times experiments to get the average handoff latency. The experimental result of the handoff latencies of MIP over wireless LANis listed in table 4-1. Table 4-1 gives 20 times of experiment data. Each row is one experiment. Each column is the time latency for that handoff phase. The data in the last column are the total handoff latencies for every experiment. The number in the bottom right cell is the average handoff latency.

PAGE 81

71 Table 4-1 Handoff latency distribution of MIP over WLAN Latency Exp # L2 movement detection L2 AP searching L2 reassociation MIP agent discovery MIP registration TCP backoff Handoff latency 1 1.033 0.061 0.005 2.996 0.073 5.058 9.226 2 1.064 0.044 0.009 1.945 0.042 6.01 9.511 3 1.133 0.063 0.006 3.023 0.052 5.345 9.622 4 1.032 0.100 0.008 2.563 0.050 5.323 9.076 5 1.044 0.065 0.003 2.756 0.052 5.125 9.045 6 1.131 0.057 0.004 2.578 0.043 5.004 8.817 7 1.009 0.056 0.010 2.436 0.060 5.625 9.196 8 1.120 0.060 0.006 3.001 0.704 5.002 9.893 9 1.023 0.059 0.026 2.213 0.054 4.998 8.373 10 1.039 0.076 0.005 3.008 0.053 5.006 9.187 11 1.100 0.045 0.030 2.770 0.041 5.728 9.714 12 1.013 0.049 0.010 2.545 0.042 4.768 8.427 13 1.021 0.051 0.009 3.001 0.065 5.202 8.896 14 1.006 0.043 0.017 2.600 0.046 5.312 9.024 15 1.104 0.069 0.006 2.598 0.047 4.544 8.368 16 1.003 0.064 0.013 2.674 0.062 4.806 8.622 17 1.110 0.054 0.010 2.783 0.054 5.705 9.716 18 1.100 0.064 0.006 3.012 0.057 5.602 9.841 19 1.302 0.056 0.009 2.349 0.070 5.71 9.496 20 1.098 0.044 0.004 2.404 0.062 5.172 8.784 Avg 1.074 0.059 0.010 2.660 0.086 5.253 9.142 Avg 1.143 2.746 5.253 9.142 We redraw figure 4-1 with handoff latency distribution in figure 4-4.

PAGE 82

72 Figure 4-4 Handoff procedure with handoff latency distribution

PAGE 83

CHAPTER 5 SPEED ADAPTIVE MIP AND ITS PERFORMANCE EVALUATION From above analysis of handoff latency distribution, we can see the largest part is TCP back-off latency ttcp-back-off. Because of TCP exponential back-off algorithm, if we reduce the L2 and L3 latency, ttcp-back-off will be reduce exponentially. In this chapter, we deal with L3 latency first. L2 and L4 latency will be considered in future works. Traditional MIP over WLAN Handoff Procedure The physical coverage of an IEEE 802.11-base wireless LAN is limited. To increase the coverage of a wireless network, one can deploy multiple wireless LAN cells or segments in an overlapped fashion where each cell is associated with an AP. AP serves as a layer-2 bridge between the high-speed wired network and the wireless LAN. As MNs move in and out of these overlapped cells, they can associate with the corresponding APs according to beacon signal strengths. In IEEE 802.11b-based networks, the intelligence to measure signal strength and switch among network segments is built into the wireless LAN NIC(Network Interface Card), which exposes various status and control information to the software device driver. To enable cellular-like networking structure, wireless LAN NIC need to be configured to run in the access point mode, which is also known as the infrastructure mode. Mobile IP provides MNs the ability to roam across wireless IP subnets without loss of network-layer connectivity. Any network application executing on 73

PAGE 84

74 a mobile host with mobile IP support can continue to run regardless of any change in the mobile nodes point of attachment. With mobile IP, mobile nodes do not need to reconfigure their IP addresses while migrating from home subnets to foreign subnets. A generic wired and wireless network topology with which mobile IP operates is shown in Fig. 5-1[Srik04]. Figure 5-1 Traditional MIP Handoff Procedure In this topology, there are one HA and several FAs running on the wired network. The MN is communicating with CN through the wireless link with AP1. The FAs periodically broadcast mobile IP advertisements on the wireless LANs(message 1, 2, 3 and 4 in figure 5-1). Because there no wireless link between the MN and AP2, AP3 and AP4, the mobile IP advertisements messages 2, 3 and 4 can not be transferred to the MN. The mobile IP advertisements messages 1 can reach the MN. Since MN already registered on FA1, message 1 will be discarded by the MN. Whenever the MN migrates from one subnet FA1 HA CN internet AP1 MN FA2 AP2 FA3 AP3 AP4 1 2 3 4 12 13 5 6 7 8 9 11 10 14

PAGE 85

75 to another (foreign) subnet, it first needs to establish wireless connection with the corresponding AP then starts receiving mobile IP advertisements from the corresponding FA. When an IEEE 802.11b-based wireless network is configured in infrastructure mode, the MN is associated with the AP, which is AP1 in figure 5-1, of the wireless LAN cell in which it currently resides. Each AP periodically broadcast beacon frames every 10ms in passive scanning mode((message 5, 6, 7 and 8 in figure 5-1). The beacons contain information about the AP, including service set identifier (SSID), supported data rates, etc. The station can use this information along with the signal strength to compare APs and decide upon which one to chose. If the MN chooses AP2, it initiates a link-layer handoff from AP1 to AP2. The MN sends a reassocation request message to AP2(message 9 in figure 5-1). If the nAP can get the credentials and other state information of the MN from AP1 through IAPP, there is no Authentication message exchange between the MN and AP2. Or else, AP2 will send out authentication request to the MN and wait for response. After authentication, AP2 reassociates the MN and response with a reassociation response message(message 10). In all known IEEE 802.11b cards, this link-layer handoff logic is built into the firmware of the NIC, and does not generate any interrupts to notify the higher-layer software. If the new wireless LAN cell belongs to the same IP subnet as the old wireless LAN cell(like AP3 and AP4 belongs to the same subnet to FA3), then to the IP layer and above on the mobile node there is no change in connectivity and the network applications continue without any disruptions. However, if the new wireless LAN cell

PAGE 86

76 belongs to a different IP subnet, then the MN can no longer communicate with CN until a network layer handoff is completed. In this case, the MN would eventually receive an advertisement from the FA2 through AP2(message 2 in figure 5-1). The mobile IP software running on the MN intercepts these advertisements and sends a registration request to FA2(message 11). This registration request is forwarded by FA2 to the HA(message 12). After the authentication(not show in figure 5-1) a registration reply is sent to the FA2(message 13) and is relayed to the MN(message 14). The mobile IP handoff is over and an IP-over-IP tunnel is established between the HA and FA2. From this point onwards, the HA, acts as a proxy for the MN, forwards all packets to FA2 over the tunnel. FA2 de-encapsulates the packets and forwards them to the MN. Similarly, all packets that the MN transmits to the CN are first received by FA2 and are tunneled over to the HA, which further routes them to the CN. This process is known as bidirectional tunneling. The above process of switching from FA1 to FA2 as the MN moves across adjacent wireless cells is called mobile IP handoff. After the moves to a new wireless LAN cell but before the associated mobile IP handoff completes, the mobile node is essentially cut off from the wired network. For a rapid moving MN, this mobile IP handoff latency greatly deduces the network performance. In extreme cases, the MN may even not be able to accomplish mobile IP handoff. For example, assume a rapid moving MN moves at speed V(m/s), the wireless LAN cell size is D(m) and the mobile IP handoff latency is T(s). If V x T > D, the MN can never register to the wired network. Therefore, it is critical to reduce the mobile IP handoff latency in rapid moving environments.

PAGE 87

77 Algorithm of Speed Adaptive MIP In Chapter 3, we define MN handoff rate as r h = v / d. It means MN move through how many APs or FAs per second. Chapter 3 also shows that the performance of MIP over WLAN is depends on the MN handoff rate among FAs. Figure 3-13 shows when the handoff rate is 0.02 FA/s, the average throughput is above 90kBytes/s. When the handoff rate rises to 0.08 FA/s, the average throughput drops to around 50kBytes/s. This means lower handoff rate has higher throughput. rh is also equal to the ratio of Khandoff/Ttravel. We rewrite the handoff rate r h = v / d in Equation 7. r h = Khandoff / Ttravel. ( Equation 7) Where Khandoff is the number of handoffs occurred during the MN traveling. Ttravel is MNs total travel time. In order to reduce handoff rate without changing total travel time, we can reduce the number of handoffs. The optimal is Khandoff = 0 Let N be total FA numbers on the way MN traveling. Lets assume somehow M is the number of FAs with whom the MN can communicate without L3 latency. The optimal is M=N. But it costs too many resources, especially when the number of active MNs is large. Also we dont know how long will the MN travel at the beginning. We call M the size of the FA Set with whom the MN can communicate without L3 handoff latency. From IP level of view, M is the number of FAs that MN has registered to and can communicate with at that moment.

PAGE 88

78 Now the question is: How to decide FA set size M How to guarantee MN can communicate with a FA set almost like to do with a single FA. The first problem SA-MIP needs to deal with is to decide FA set size M. In SA-MIP algorithm, M is decided by the following Equation. (Equation 8) r hhandofftM 1 where thandoff is the handoff time for every handoff procedure, and r h is the handoff rate. Here we use the experimental average handoff time 9.142s for thandoff. rh is dynamic. For example, at speed 40m/s, AP distance 500m, M = | 9.142 x 40/500 | + 1 = 2. At speed 80m/s, AP distance 500m, M = 3. The second problem is how to guarantee MN can communicate with a FA set just like it can do with one FA. Our solution is to let MN pre-register M potential FAs along the way MN traveling, at the same time multicast IP packets to those FAs in this FA set. So MN wont feel any handoff latency from the IP level of view. In Speed Apative MIP(SA-MIP), the set of FAs that MN can talk to without L3 latency is extended from one point at low moving speed to a line at high moving speed. The length of the line dynamically changes with the MN handoff rate as in figure 5-2. The behavior of SA-MIP will automatically adapt to the handoff rate of the MN so that the performance of SA-MIP wont decline dramatically in rapid moving environments. At the same time SA-MIP only cost reasonable resource that is as much as enough for seamless handoff.

PAGE 89

79 M = 1 M = 2 M = 3 M = 4 r h = 0 0 < r h < 0.109 0.109 < r h < 0.218 0.218 < r h < 0.328 Figure 5-2 FA Set size vs handoff rate Speed detection and location tracking is an interesting topic on mobile computing. [Bahl00][Yous03] are all making use of signal strength information to locate and track wireless users. [Erge02] uses GPS to inform mobile users about the prospective future location and to improve performance of the ad hoc routing. In this paper, we assume the MN has GPS system to detect its location. When the MN moves at speed v, if v < 30m/s(67.10miles/h), it performs a normal registration. If 30m/s < v < 40m/s(89.4miles/h), it initializes registration after receiving two successive agent advertisements. If v > 40m/s(89.4miles/h), we assume the MN wont change its direction largely in a short distance. It initializes registration once it gets a new agent advertisement. MNs registration message is extended by speed extension. According to Mobile IP Vendor/Organization-Specific Extensions[RFC3115]. Two Vendor/Organization Specific Extensions are allowed for MIP, Critical (CVSE) and Normal (NVSE) Vendor/Organization Specific Extensions. The basic difference is when the CVSE is encountered but not recognized, the message containing the extension must be silently discarded, whereas when a NVSE is encountered but not recognized, the extension should be ignored, but the rest of the Extensions and message data must still be processed. We use the NVSE extension.

PAGE 90

80 The following is the NVSE format. Figure 5-3 Normal vendor/organization specific extension In figure 5-3, the type here is 134 for NVSE extension. Length is the size in bytes of the extension, not including the type and length bytes. The verdor/org-ID is assigned in RFC 1700. We pick up a large unassigned number 5205. Vendor-NVSE-Type Indicates the particular type of Vendor-NVSE-Extension. The administration of the Vendor-NVSE-Types is done by the Vendor. Vendor-NVSE-Value here is a floating point number for handoff rate. Figure 5-4 shows the SA-MIP handoff procedure and message exchange. Whenever the MN needs to handoff to a new FA set, after it gets that many times of agent advertisements which is determined by speed(step 1 in figure 5-4), it sends a registration request with up-to-date handoff rate information to the very first FA in a new FA set(step 2). The first FA relays the registration request to upper FA or HA(step 3). Meanwhile, it decapsulates the speed extension, refill the MIP header and authentication extension and then forward it to other FAs(M-1 FAs) in this FA set(step 4). Assume the handoff rate is below 0.109. The FA set size at this time is 2. These other FAs relay the registration request to upper FA or HA as well, just like the request comes from the

PAGE 91

81 MN(step 5). When the GFA or HA received these registration requests, it builds up tunnels downwards to each FA and responses with registration reply(step 6 and 7). When the FA received the registration reply, it builds up tunnel upwards to the GFA or HA. Figure 5-4 SA-MIP handoff procedure Whenever the MN setups the Link-layer contact with the FA, the later forwards the registration reply to the former(step 9 or 10). The MN gets the care-of-address from agent advertisement message(step 10 or 9) or registration reply message(step 9 or 10), and begins data communication. At the same time, it sends registration request to the new FA with up-to-date speed information (step 11). This new FA decapsulates the registration request message and sets up a new FA set. Assume the handoff rate is between 0.109 and 0.218. The FA set size is 3 at this time. The new FA(FA2) refill the MIP header and authentication extension and then forward it to other FAs(FA3 and FA4 in the figure) in FA1 HA CN internet AP1 MN FA2 AP2 FA3 AP3 FA4 AP4 5 3 6 7 4 1 2 8 9 12 10 11 13

PAGE 92

82 this FA set and repeats the above process. In Figure 5-4, the FA set size M changes from 2 to 3 when the MN handoff rate changes from 0.08 to 0.11. Implementation of Speed Adaptive MIP Mobile IP has three main entities, HA, FA and MN. HUT dynamic MIP implementation version 0.8.1, originally developed at Helsinki University of Technology (HUT), is a scalable, dynamical, and hierarchical Mobile IP software for Linux operating system. The SA-MIP is developed on HUT dynamic MIP implementation version 0.8.1. Home Agent The HA implementation of SA-MIP is almost the same as HUT dynamic MIP except the Registration Request validation check function. The following describes the basic functionalities of HA. The HA is responsible for encapsulating and forwarding packets to its MNs when they are away from their Home Network. It also decapsulates and forwards tunneled packets originating from its Mobile Nodes. The HA communicates with FAs and MNs using Berkeley IP sockets. The HA listens to ICMP agent solicitation messages from MNs on a "packet" socket. ICMP agent advertisement messages are sent in reply to these messages on the same socket. The HA also listens to Registration Requests on a UDP socket (port 434 by default) originating from FAs or MNs. If Registration Requests is validate a mobility binding for the requested Mobile Node will be established or, if one already exists, updated. The request is then answered with an corresponding Registration Reply.

PAGE 93

83 When received of a Registration Request Message the HA performs a Registration Request validation check process. It first looks up the shared secret for the corresponding MN. The shared secret is used to check the MAC of the request message. If a Mobility Binding for the MN exists, then the timestamp in the request is checked to be greater than the one in the Mobility Binding. If either of these checks fails the HA responds to the sender with a Registration Reply indicating registration failure. If the checks succeed the HA determines the smaller lifetime value of the one in the request and the HA's pre-configured maximum value. It then generates a Session Key and creates a Mobility Binding consisting of the MN's address, its highest FA, the identification timestamp and the Session Key. The HA then responds with a Registration Reply indicating registration success. The message includes the same timestamp as the request, the lifetime value, a MAC, the Session Key encrypted with the shared secret and the Session Key encrypted with the highest FA's public key. The HA configures a tunnel between itself and the highest FA and works as a proxy for the registered MN. If the lifetime in the request is set to zero, the HA interprets this as a deregistration from the MN. On deregistration the HA purges the tunnel configuration and stops the proxy ARP functionality for the MNs address. If the FA differs in a reregistration, a Registration Reply with a lifetime set to zero is sent to the previous FA to indicate that the old tunnel should be torn down. In order to focus on performance issues of mobile IP, we ignore the security check part. When the HA checks the validation of the Registration Requests, the MN-HA

PAGE 94

84 authentication check is comment out. Figure 5-5 is the function flowchart of Registration in HA. Main loop( ) Handle_reg_msg( ) Recvmsg( ) Parse_msg( ) Validate_request( ) Send_reg_failure( ) Send_reg_repl( ) Figure 5-5 Function flowchart of registration in HA Mobile Node In addition to the basic function of HUT dynamic MIPs MN, the MN of SA-MIP needs to transfer moving speed information to FAs. This is done by extending the Registration Request message with speed extension. The Registration function in HUT dynamic MIP implementation is the method by which MN requests forwarding services when visiting a foreign network, informs their HA of their current CoA, renews a registration which is due to expire, and/or deregisters when they return home. The Registration Request message has the following format.

PAGE 95

85 Figure 5-6 Registration request message format The Registration Request message header consists of the fields from Type to Identification. The send_registration () function in the MN implementation first fills out the Registration Request header with corresponding data then fills out the extension. Figure 5-7 is the Registration Request Message extension format. Figure 5-7 Registration request message extension format The speed extension is as following.

PAGE 96

86 struct speed_ext mn_speed; // speed_ext struct for SA-MIP if(speedChanged) //compare the handoff rate send last time with current one. { mn_speed = (struct speed_ext *) pos; if (left < sizeof(struct speed_ext)) //left is the message size after Registration //header return -1; mn_speed ->type = VENDOR_EXT_TYPE2; mn_speed ->length = sizeof(struct speed_ext) 2; mn_speed ->reserved = 0; mn_speed ->vendor_id = htonl(VENDOR_ID_DYNAMICS); mn_speed ->sub_type = 25 mn_speed -> mn_spd = handoff_Rate; pos += sizeof(struct speed_ext); left -= sizeof(struct speed_ext); } Figure 5-8 show the function flowchart of sending Registration Request send_registration () fill_req_header () add_req_extensions () main loop Figure 5-8 Function flowchart of sending registration request Foreign Agent Whenever the FA received a Registration Request from the MN, it decapsulates the message, checks the speed extension. If the handoff rate is non-zero, this FA calculates the FA set size M. It fills out the Registration Request header with new CoA and new MD5

PAGE 97

87 MN-HA authentication. This new Registration Request message is sent to next M-1 FAs, which in turn forward the Registration Request one level up or the HA. Figure 5-9 is the function flowchart for FA handling Registration Request. Main loop( ) Handle_reg_msg( ) Recvmsg( ) Parse_msg( ) Figure 5-9 Function flowchart for FA handling registration request. Evaluation of Speed Adaptive Extension for MIP We evaluate the performance of SA-MIP over WLAN under the same scenario as in Section 3. Figure 5-10 amd 5-11 are the time-sequence graph at speed 60m/s(rh = 0.06)and N Handoff rate =0? 1 hhandoffrtM fill_req_header () Send_reg_req( ) Y

PAGE 98

88 80m/s(rh = 0.08) and AP distance 1000m. The average throughput at different speed is listed in table 5-1. Figure 5-10 Time-sequence graph at speed 60m/s and AP distance 1000m Figure 5-11 Time-sequence graph at speed 80m/s and AP distance 1000m

PAGE 99

89 Table 5-1 Average throughput for speed-adaptive MIP Speed (m/s) AP distance (m) Bytes transferred (kB) Travel Time(s) Arg throughput (kB/s) Handoff Rate (FAs/s) 20 1000 85000 399 213.03 0.02 40 1000 37500 198 189.39 0.04 60 1000 19400 130 149.23 0.06 80 1000 11600 99 117.17 0.08 10 500 84400 398 212.06 0.02 20 500 37400 198 188.89 0.04 30 500 19500 131 148.55 0.06 40 500 11500 98 117.34 0.08 Figure 5-12 is the average throughput vs. handoff rate before and after the speed adaptive MIP is installed. After installing SA-MIP, at handoff rate 0.02 FA/s, the average throughput is improved by (212.54 197.35)/ 197.35 = 7.69%. At handoff rate 0.04, 0.06 and 0.08 FA/s, the average throughput is improved by 13.02%, 15.97% and 24.73% respectively. Kbytes/sec 200 Figure 5-12 Average throughput vs. handoff rate 80 100 0 0.02 0.04 0.06 0.08 Handoff rate FA/s 120 140 160 180 220 SA -MIP MIP (212.55 197.35) /197.35 = 7.69% (189.14 167.34) /167.34 = 13.02% (148.89 128.32) /128.32 = 15.97% (117.25 94.12) /94.12 = 24.58%

PAGE 100

CHAPTER 6 SUMMARY AND FUTURE WORKS In this dissertation, in order to evaluate the rapid mobility of MIP in a laboratory environment, we build up the performance evaluation testbed on Wireless LAN. The emulation experiments showed that MIP is not suitable for rapid moving environments. We depicted the relationship between the performance and the handoff rate of MN and quantitatively analyzed the handoff latencies of the MIP over wireless LAN. A Speed Adaptive MIP is proposed and evaluated. The emulation showed that the SA-MIP can improve the performance from 8% to 25% when the handoff rate changes from 0.02 FA/s to 0.08 FA/s. Compared to the mechanisms of Malki[Malk02] and Koodlis mechnism[Kood02], SA-MIP combines the preand post-registration methods, but keeps indenpendency from L2 infrastructure. Compared to Hsieh[Hsi03] and Wijngaerts mechnism[Wijn04], SA-MIP not only predicts its next move but also involves next M number of FAs according to MNs moving speed. In our work so far, SA-MIP only deal with L3 handoff latency. But there is still physical link break from the Layer 2 handoff. And also we noticed that even in SA-MIP, the biggest part of handoff latency was still the layer4 TCP back-off-latency. In future works, the speed adaptive scheme should be applied to layer 2 and layer 4 handoff latencies. 90

PAGE 101

LIST OF REFERENCES [Akyi99] I. F. Akyildiz, Mobility Management for Next Generation Wireless Systems, Proc. IEEE, vol. 87, no. 8, Aug. 1999, pp. 1347. [Amic02] W.P. DAmico, P.A. Stadter, M.H. Lauss, A. Hooper, Network Telemetry: Practical Experiences and Unique Features, International Telemetring Conference 2002, San Diego, CA, USA, October 21, 2002. [Bahl00] P. Bahl and V. N. Padmanabhan, RADAR: An In-Building RF-based User Location and Tracking System , IEEE Infocom 2000, volume 2, March 2000, pages 775-784. [Bamb02] R.J. Bamberger, G.R. Barrett, R.A. Nichols, J.L. Burbank, M.H. Lauss, Wireless Local Area Network for Data Telemetry from Fast Moving Nodes, International Telemetring Conference 2002, San Diego, CA, USA, October 21, 2002. [Blon03] C. Blondia, O. Casals, L. Cerda, N. Van den Wijngaert, G. Willems, P. De Cleyn, Performance Comparison of Low Latency Mobile IP Schemens, Proceedings of WiOpt '03: Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks, INRIA Sophia Antipolis, March 2003, pp. 115-124 [Blon04] C. Blondia, O. Casals and LL. Cerda, Performance Evaluation of Layer 3 Low Latency Handoff Mechanisms, Mobile Networks and Applications 9, 63345, 2004 [Cam99] A. Campbell, J. Gomez, C-Y. Wan, Z. Turanyi, A. Valko, Cellular IP ," Internet Draft, draft-valko-cellularip-01.txt, October 1999 [Camp99] A. T. Campbell, J. Gomez, A. G. Valko, "An Overview of Cellular IP," IEEE Wireless Communications and Networking Conference (WCNC'99), New Orleans, September 1999 [Camp00] A. T. Campbell, Design, Implementation, and Evaluation of Cellular IP, IEEE Pers. Commun., Aug. 2000, pp. 4249. 91

PAGE 102

92 [Camp02] A. T. Campbell, J..Gomez, S. Kim, Z.Turanyi, C. Y. Wan, and A, Valko, Comparison of IP Micro-Mobility Protocols ," IEEE Wireless Communications Magazine, Vol. 9, No. 1, February 2002 [Casa03] O. Casals, L. Cerda, G. Willems, C.Blondia, N. Van den Wijngaert Performance Evaluation of the Post-Registration Method, a Low Latency Handoff in MIPv4, Proceedings of IEEE 2003 International Confernence on Communications (ICC 2003), Anchorage, May 2003 [Cast01] P. Castro, P. Chiu, T. Kremenek, and R. Muntz. A Probabilistic Location Service for Wireless Network Environments. Ubiquitous Computing 2001, September 2001. [El-Ho00] A. El-Hoiydi, Implementation options for the distribution system in the 802.11 Wireless LAN Infrastructure Network, Proc. IEEE ICC2000, New Orleans, 2000. [Erge02] M. Ergen, S. Coleri, B. Dundar, A. Puri., and P. Varaiya, Fast Handoff with GPS routing for Mobile IP, IPCN 2002, April 2002, Paris, France. [Fiko01] N. A. Fikouras, A. J. Knsgen, and C. Grg. Accelerating Mobile IP Hand-offs through Link-layer Information. In Proceedings of the International Multiconference on Measurement, Modelling, and Evaluation of Computer-Communication Systems (MMB), Aachen, Germany, September 2001. [Gast02] M. Gast, Chapter 1: Introduction to Wireless Networks, 802.11 Wireless Networks: The Definitive Guide. O'Reilly. ISBN 0-596-00183-5. April, 2002. [Gust00] E. Gustafsson, A. Jonsson, C. Perkins. Mobile IP Regional Registration, draftietf-mobileip-reg-tunnel-02.txt, March 2000. [Hern02] E. Hernandez and Sumi Helal, "RAMON: Rapid Mobility Network Emulator," Proceedings of the 27th Annual IEEE Conference on Local Computer Networks (LCN), November 2002, Tampa, Florida [Hsi03] R. Hsieh, Z.-G. Zhou, and A. Seneviratne, S-MIP: A Seamless Handoff Architecture for Mobile IP, In Proceedings of INFOCOM, San Francisco, 2003. [Hsie03] P. Hsieh and A. Seneviratne. A Comparison of Mechanisms for Improving Mobile IP Handoff Latency for End-to-End TCP, MobiCom03 San Diego, CA, USA, September 2003.

PAGE 103

93 [Jain03] A. Jain. Handoff delay for 802.11b wireless lans. Technical report, University of Kentucky, Lexington, Kentucky, 2003. [Jim01] G. Jim Wireless LANs, 2nd Edition, Sams publish, ISBN: 0672320584; Published: Jul 9, 2001; Copyright 2002, [Kapp02] S. Kapp, (2002). .11: leaving the wire behind, Internet Computing, IEEE. Volume: 6 Issue: 1. Page(s): 82 85. February,2002. [Kood02] R. .Koodli, Fast Handovers for Mobile IPv6. Internet Draft, IETF, Sep 2002. [Kim04] H. Kim, S. Park, C. Park, J. Kim, S. Ko. Selective Channel Scanning for Fast Handoff in Wireless LAN using Neighbor Graph , ITC-CSCC 2004, July 2004. [Ladd02] A. M. Ladd, K. Bekris, A. Rudys, G. Marceau, L. E. Kavraki, and D. S. Wallach. Robotics-Based Location Sensing using Wireless Ethernet, In 8th ACM MOBICOM, Atlanta, GA, September 2002. [Malk02] K. El Malki, Low latency handoffs in mobile IPv4, IETF draft-ietf-monileip-lowlatency-handoffs-v4-04.txt (2002). [Mani03] D. Maniezzo, P. Bergamo, M. CESANA, G. Pau, K. Yao, M. Gerla, D. E. Whiteman, IEEE802.11 Wireless Networks under Aggressive Mobility Scenarios, in proceedings of the International Telemetring Conference 2003, ITC 2003, Las Vegas, Nevada, USA, October 20-23 2003 [Mish03] M. S. A. Mishra and W. Arbaugh. An Empirical analysis of the IEEE 802.11 MAC Layer Handoff Process, ACM SIGCOMM Computer Communication Review, 33(2):93-102, April 2003. [Mish04] A. Mishra, M. Shin, and W. A. Arbaugh, "Context Caching using Neighbor Graphs for Fast Handoffs in a Wireless Network," in IEEE Infocom 2004, Mar. 2004 [Mobi03] Mobility and Mobile IP, IP Unplugged AB white paper 2003. [Perk98] C. E. Perkins, Mobile IP, Design Principles and Practices, Prentice Hall PTR; 1st edition, Page 67-110, 1998, [Perk02] C. Perkins, RFC3344, IP Mobility Support for IPv4, August 2002.

PAGE 104

94 [Par02] S. Park and Y. Choi. Fast inter-AP handoff using predictive-authentication scheme in a public wireless LAN, Networks2002 (Joint ICN 2002 and ICWLHN 2002), August 2002. [Park02] S. Park and Y. Choi. Pre-authenticated fast handoff in a public wireless lan based on ieee 802.1x mode, Singapore, October 2002. IFIP TC6 Personal Wireless Communications. [Ramj99] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, L. Salgarelli, IP micro-mobility support using HAWAII, Internet Draft, draft-ietf-mobileip-hawaii-00, Work in Progress, June 1999 [Ramj02] R. Ramjee, T. L. Porta, S. Thuel, K. Varadhan, and S. Y. Wang, HAWAII: A Domain-based Approach for Supporting Mobility in Wide-area Wireless Networks, in in IEEE/ACM Transactions on Networking Vol 6., No. 2, June 2002 [Ren99] A. H. Ren, G. Q. Maguire Jr., An adaptive realtime IAPP protocol for supporting multimedia communications in wireless LAN systems, Proc. Of ICCC99, Japan, 1999. [Roos02] T. Roos, P. Myllymaki, H. Tirri, P. Misikangas, and J. Sievanen. A Probabilistic Approach to WLAN User Location Estimation, International Journal of Wireless Information Networks, 9(3), July 2002. [RFC1701] S. Hanks, T. Li, D. Farinacci, and P. Traina, "Generic Routing Encapsulation (GRE)," RFC 1701, October 1994. [RFC2003] C. Perkins, "IP Encapsulation within IP," RFC2003, October 1996. [RFC2004] C. Perkins, "Minimal Encapsulation within IP", RFC 2004, October 1996. [RFC2104] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC 2104, February 1997. [RFC3115] G. Dommety, K. Leung, Mobile IP Vendor/Organization-Specific Extensions, RFC 3115, April 2001 [RFC3344]: C. Perkins, Ed. IP Mobility Support for IPv4, Nokia Research Center, RFC3344, August 2002.

PAGE 105

95 [Sing02] J.P. Singh, N. Bambos, B. Srinivasan and D. Clawin, Wireless LAN Performance under Varied Stress Conditions in Vehicular Traffic Scenarios, IEEE Vehicular Technology Conference 2002, Vancouver, Canada, September 24-28, 2002, vol. 2, pp. 743-747. [Smai01] A. Smailagic, D. P. Siewiorek, J. Anhalt, D. Kogan, and Y. Wang. Location Sensing and Privacy in a Context Aware Computing Environment, Pervasive Computing, 2001. [Soli02] H. Soliman, C. Castelluccia, K. El-Malki, L. Bellier. Hierachical MIPv6 mobility management, draft-ietf-mobileip-hmipv6-07.txt, October 2002 [Srik04] S. Srikant N. Zhu, T. Chiueh Low-Latency Mobile IP Handoff for Infrastructure-Mode Wireless LANs, IEEE Journal on selected areas in communications, vol 22, no. 4, May 2004. [STD802] IEEE 802-2001, IEEE IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, 2001. [Shin04] S. Shin A. S. Rawat H. Schulzrinne, Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs, MobiWac'04, Philadelphia, Pennsylvania, October 1, 2004. [Thor02] C.-E. I. Thorner and R. Iltis, Low-Cost Telemtry using Frequncy Hopping and the TRF6900 Transceiver, International Telemetring Conference 2002, San Diego, CA, USA, October 21, 2002. [Trim04] All About GPS, Online tutorial. 2004. Trimble Navigation Limited. http://www.trimble.com/gps/index.html [Vela04] H. Velayos and G. Karlsson Techniques to Reduce IEEE 802.11b Handoff Time, IEEE ICC 2004, Paris, France, June 2004. [Wijn04] V. d. Wijngaert, N. and C. Blondia, An Urban Mobility Model and Predictive Handover Scheme for Mobile IP, Proceedings of OPNETWORK 2004, Washington D.C., (2004). [You03] M. Youssef, A. Agrawala, and A. U. Shankar. WLAN Location Determination via Clustering and Probability Distributions, In IEEE PerCom 2003, March 2003.

PAGE 106

96 [You04] M. Youssef and A. Agrawala. Handling Samples Correlation in the Horus System, In IEEE Infocom 2004, March 2004. [Yous03] M. Youssef, A. Agrawala, Small-Scale Compensation for WLAN Location Determination Systems ," IEEE Wireless Communications and Networking Conference (WCNC) 2003 New Orleans, Louisiana, March 16-20, 2003. [Yous04] M. Youssef and A. Agrawala, On the Optimality of WLAN Location Determination Systems ," Communication Networks and Distributed Systems Modeling and Simulation Conference, January 18-24 2004, San Diego, California. [11F03] IEEE 802.11F-2003 IEEE Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation [80211] IEEE 802.11, 1999 Edition (ISO/IEC 8802-11: 1999) IEEE Standards for Information Technology -Telecommunications and Information Exchange between Systems -Local and Metropolitan Area Network -Specific Requirements -Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications [80211a] IEEE 802.11a-1999 (8802-11:1999/Amd 1:2000(E)), IEEE Standard for Information technologyTelecommunications and information exchange between systemsLocal and metropolitan area networksSpecific requirementsPart 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specificationsAmendment 1: High-speed Physical Layer in the 5 GHz band [80211b] 802.11b-1999/Cor1-2001, IEEE Standard for Information technologyTelecommunications and information exchange between systemsLocal and metropolitan area networksSpecific requirementsPart 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specificationsAmendment 2: Higher-speed Physical Layer (PHY) extension in the 2.4 GHz bandCorrigendum1 [80211g] IEEE 802.11g-2003 IEEE Standard for Information technology Telecommunications and information exchange between systemsLocal and metropolitan area networksSpecific requirementsPart 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specificationsAmendment 4: Further Higher-Speed Physical Layer Extension in the 2.4 GHz Band

PAGE 107

BIOGRAPHICAL SKETCH Jun Tian got his B.S. and M.S. in electrical engineering from Shandong University, China. In 2002, he was awarded an alumni fellowship to pursue his Ph.D degree in computer sciences at the University of Florida. He got his Ph.D degree and joined Motorola Corporation in May 2005, and works on mobile device local connectivity technologies. 97


Permanent Link: http://ufdc.ufl.edu/UFE0012700/00001

Material Information

Title: A Speed Adaptive Mobile Internet Protocol over Wireless Local Area Network
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0012700:00001

Permanent Link: http://ufdc.ufl.edu/UFE0012700/00001

Material Information

Title: A Speed Adaptive Mobile Internet Protocol over Wireless Local Area Network
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0012700:00001


This item has the following downloads:


Full Text

























Copyright 2005

by

Jun Tian
















TABLE OF CONTENTS
page

L IS T O F T A B L E S .............................................................................. ................ .. v i

LIST OF FIGURES .................. .............................. ...... .............. .. vii

A B STR A C T ................. .............................................................................................. ix

CHAPTER

1 IN TR OD U CTION ....................................... ................ .. ........ ..

2 R E L A T E D W O R K .............................................................................. .. ........ 5

N network Layer Handoff M anagem ent ................................................................5
M obile IP ............................................................ . 6
A g ent D iscov ery ............................................... .. ...... .. ...... ........ ...... 8
R eg istratio n ....................................................................... 10
T unneling ........................................ 12
H ierarchical M IP .................... ................. ...................................... 15
C cellular IP ................................................................. ..... ............. 16
R outing ..................................... .............. ..................... 17
Handoff ................................. ............................... ......... 17
Paging ......................................... 19
HAW AII ........................................... ..................... ........ 20
W irele ss L A N ............................................................................................... 2 4
Technology Overview................................ ...... .......... 24
The IEEE 802.11 Established Standards ........................................... 25
Standard 802 .11.................................................... 26
Standard 802.11b......................... ...............28
Standard 802.11a......................... ...............29
Standard 802.11g................................. ........................31
Pending Specifications W within the 802.11 Suite ................... ............. 33
The IEEE 802.11 Wireless LAN Architecture ......... ............. .. .........33
W wireless LA N Station ......................................................... ............... 34
B asic Service Set (B SS) ............... .............. ...... ...... ...................34
Independent Basic Service Set (IBSS)........................................ 34









Infrastructure Basic Service Set(BSS) .................................................. 35
Extended Service Set (ESS) .......................................... ...............35
Wireless LAN Handoff Management......................................................35
Wireless LAN Handoff Management Frames ................. .................. 35
IEEE 802.11 H andoff Procedure ...................... ..........................................37
Techniques to Reduce IEEE 802.11 Handoff Time.................................39
Low Latency Handoff Mechanisms for MIP over 802.11 Network .............. 41
L2 Triggers....................................................................... 42
P re-R eg istratio n .............................................................. .. .......... .... .4 2
Post-Registration .................. ............................ ......... .. ...... .... 43
L location Tracking ............ .... ...................................................... ...... .... ... .. 44
O their R elated W ork ..................................... ...... ....................... 46

3 PERFORMANCE OF MIP OVER WLAN AT DIFFERENT SPEEDS.............49

M IP over W wireless LAN Handoff Procedure .................................................49
R A M ON Testbed .................. ..................................... .. ........ .... 50
H ardw are A rchitecture.............................................................. ............... 51
Softw are A architecture ............................................................................ 52
Perform ance Evaluation ................................... ............................................ 53
Emulation Scenario and Result.................. .............................................. 53
Experim ental Result Analysis................................................ .................. 57

4 QUANTITATIVE ANALYSIS OF THE MIP OVER WIRELESS LAN HANDOFF
LATENCY ...................................................................... .... ......... ................... 63

L ayer 2 H andoff L atency ........................................................................ ... ... 63
Layer2 M movement Detection Phase............... .............................................64
Layer2 AP Searching Phase................................ .......... .... ............... 65
Layer2 R association Phase ........................................ ....... ............... 66
L ayer 3 H andoff L atency............................ ............................. ............... 66
Agent Discovery ....... .... ...................... .................... .. 66
Registration .......... ......... .... .................... ................. 68
Layer 4 Handoff Latency...................... ........... ................... 69
Quantitative Analysis of the Handoff Latency ............. .................................. 70

5 SPEED ADAPTIVE MIP AND ITS PERFORMANCE EVALUATION..........73

Traditional MIP over WLAN Handoff Procedure .............................................73
Algorithm of Speed Adaptive M IP ............... ............................................. 77









Implementation of Speed Adaptive M IP................................. ...... ...............82
H om e A g ent .............. ....... .............................................. 82
Mobile Node ...... ......... ......... .......... ........84
Foreign Agent ...... ............... ..... ...............86
Evaluation of Speed Adaptive Extension for MIP ....................................87

6 SUMMARY AND FUTURE WORKS..................................... 90

LIST O F REFEREN CE S ......... .................... ......... .................................... 91

BIOGRAPHICAL SKETCH ........... ..... ............... ............... 97

















LIST OF TABLES


Table page

2-1 Characteristics specified by the 802.11 standard............................................. 28

2-2 Characteristics specified by the 802.1 lb standard...........................................29

2-3 Characteristics specified by the 802.lla standard.....................................................31

2-4 Characteristics specified by the 802.1 1g standard...........................................32

2-5 Comparison of characteristics specified within the IEEE 802.11 suite....................33

3-1 Average throughput at different speeds and AP distances.......................................58

4-1 Handoff latency distribution of MIP over WLAN .................................................71

5-1 Average throughput for speed-adaptive MIP ................................... .................89

















LIST OF FIGURES


Figure p

2-1 M acro and M icro m obility ........................................ ................................. 6

2-2 Three functional entities of M IP ........................................................................ .. 8

2-3 IP in IP encapsulation and minimal encapsulation..................... ...............13

2-6 802.11 wireless LAN handoff procedure .........................................................39

3-1 RAM ON testbed architecture........................................................ ............. 51

3-2 D ynam ic M IP sam ple scenario........................................... ........................... 53

3-3 Time-sequence graph at speed 20m/s and AP distance 1000m.............................54

3-4 Throughput graph at speed 20m/s and AP distance 1000m............................... 54

3-5 Time-sequence graph at speed 80m/s and AP distance 1000m .............................55

3-6 Throughput graph at speed 80m/s and AP distance 1000m................................ 55

3-7 Time-sequence graph at speed 10m/s and AP distance 500m.............................56

3-8 Throughput graph at speed 10m/s and AP distance 500m.....................................56

3-9 Time-sequence graph at speed 40m/s and AP distance 500m.............................57

3-10 Throughput graph at speed 40m/s and AP distance 500m. ..................................57

3-11 Average throughputs vs speeds. ........................................ ......................... 59

3-12 Time-sequence graph at AP distance 1000m with speed 20m/s without handoff...60

3-13 Time-sequence graph at AP distance 1000m with speed 80m/s without handoff...60

3-14 Average throughput vs handoff rate..................................................62









4-1 Handoff procedure with message exchange............................................................67

4-2 LCS handoff latency for M IP ...................................................... ...................67

4-3 ECS handoff latency for M IP ...................................................... ...................68

4-4 Handoff procedure with handoff latency distribution.....................................72

5-1 Traditional M IP Handoff Procedure.................................................................... 74

5-2 FA Set size vs handoff rate...................................................................... 79

5-3 Normal vendor/organization specific extension............................. ...............80

5-4 SA -M IP handoff procedure ......................................................... .............. 81

5-5 Function flowchart of registration in HA ...................................... ....... ............ 84

5-6 R registration request m message form at ............................ .................. .....................85

5-7 Registration request message extension format ................................ ............... 85

5-8 Function flowchart of sending registration request........................................86

5-9 Function flowchart for FA handling registration request ........................................87

5-10 Time-sequence graph at speed 60m/s and AP distance 1000m .............................88

5-11 Time-sequence graph at speed 80m/s and AP distance 1000m .............................88

5-12 Average throughput vs. handoff rate.............................. ...............89
















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

A SPEED ADAPTIVE MOBILE INTERNET PROTOCOL
OVER WIRELESS LOCAL AREA NETWORK

By

Jun Tian

December 2005

Chair: Abdelsalam (Sumi) Helal
Major Department: Computer and Information Sciences and Engineering.

This dissertation presents two novel contributions in the area of mobile network

communication. The first is the performance/moving speed relationship of Mobile Internet

Protocol(MIP) over Wireless Local Area Network(LAN). In this dissertation, the rapid

mobility of MIP over Wireless LAN is emulated on a testbed. The performance of MIP

over Wireless LAN at different moving speeds is evaluated. The result shows that current

MIP protocol is not suitable for rapid moving environments. This dissertation analyzes the

emulation results and depicts the relationship between the performance and the moving

speed of the mobile devices. This relationship is used in a novel protocol, which is the

second contribution, to improve the performance of MIP over Wireless LAN in rapid

moving environments. The second contribution is the Speed Adaptive Mobile IP. In the

Speed Adaptive Mobile IP, Mobile Node's registration message is extended by speed










extension. With the speed information popularized in the mobile IP network, the behavior

of the Speed Adaptive Mobile IP will automatically adapt to the speed of the Mobile Node

so that the performance of the Speed Adaptive Mobile IP won't decline dramatically in a

rapid moving environment. At the same time, the Speed Adaptive Mobile IP only uses

reasonable resources that are enough for seamless handoff The emulation result shows

that the Speed Adaptive MIP greatly improves the performance of MIP over Wireless

LAN in rapid-moving environments.















CHAPTER 1
INTRODUCTION

The population living on the world wide internet is exploding. According to the

analysis of Internet usage across more than 50 countries, the latest report from Computer

Industry Almanac(CIA) Inc.'s shows that as of the end of March 2004, there are 945

millions of internet users world wide. The report also indicates 1.12 billion Internet users

projected for the end of 2005, and 1.46 billion for 2007. A significant number will be using

wireless devices such as Web-enabled cell phones and PDAs to go online. In America,

27.9% of 193 millions of internet users are using wireless internet. At the end of 2007,

46.3% of 263 millions will be wireless internet users.

Throughout history, the economic wealth of people or a nation has been closely tied

to efficient methods of transportation. The transportation speed is becoming faster and

faster. A person can drive a car on high way at speed of 70mph. Some high speed trains

such as France TGV, Japanese bullet, German maglev can travel at speeds of over

300km/hour(186mph). Could those people surf the internet, communicate with families

and enjoy an online movie while traveling at high speeds? Could the current network

infrastructure support rapid mobility?

While TCP/IP successfully overcomes the barriers of time and distance in a wired

network, mobile IP is a promising technology to eliminate the barrier of location for the










increasing wireless internet usage. Third generation (3G) services combine high speed

mobile access with IP-based services. With access to any service anywhere, anytime, from

one terminal, the old boundaries between communication, information sharing, media

distribution will disappear. 3G enables users to transmit voice, data, and even moving

images whenever and wherever. But, 3G networks are not based on only one standard, but

a set of radio technology standards such as cdma2000, EDGE and WCDMA. Mobile IP

[Perk02] can be the common macro mobility management framework to merge all these

technologies in order to allow mobile users to roam between different access networks.

These radio technologies only need to handle Micro mobility issues such as radio specific

mobility enhancements. Mobile IP is different from other efforts for doing mobility

management in the sense that it is independent to any specific access technology[Mobi03].

Wireless local area networks (WLAN) have experienced incredible growth over

recent years. WLANs provide wireless users with an always-on, wireless connection to

each other, to local area networks (LAN), to wide area networks (WAN), and to the

Internet. The major benefit of WLANs over wired network is its flexibility and mobility

[Kapp02]. There are currently two major WLAN standards, and both operate using radio

frequency (RF) technology. The two standards have heretofore been colloquially referred

to as 802.1 lb and 802.1 la. 802.1 lb operates in the radio frequency (RF) band between 2.4

and 2.485GHz while 802.1 la operates between 5.15-5.35GHz and 5.725-5.825GHz. The

performance of both 802.1 lb and 802.1 la decreases as your distance from the antenna

increases. This degradation is neither linear nor granular. Instead, each wireless










specification has a handful of pre-defined bandwidth levels at which it can operate

(802.1 lb has four, while 802.1 la has seven). Take 802.1 lb as an example. Within a closed

office, the bandwidth will drop from 11, 5.5, 2 to Imbps when the distance increases from

25, 35, 40 to 50 meters. For outdoors, the bandwidth will drop from 11, 5.5, 2 to Imbps

when the distance increases from 160, 270, 400 to 550 meters. So if you want to keep a

high throughput, you have to reduce the distance between access points. For example, to

keep 5.5mbps when outdoors, the distance between two access points should be no more

than 500 meters. The smaller the cell the higher the bandwidth you get.

The use of current cellular/PCS high data rate services for data networking is not

economically feasible due to high usage costs. The success of WLAN lies in the following

factors. First, WLAN uses license-free band. 802.1 lb and 802.1 Ig use Industrial,

Scientific, and Medical (ISM) 2.4GHz radio band while 802.1 la operates in the 5 GHz

National Information Infrastructure (UNII) radio band. Second, WLAN offers reasonably

high available data rates. 802.1 lb can transmit data up to 11 Mbps while 802.1 Ig and

802.1 la can provide data rate up to 54Mbps. Finally, there are lots of commercially

available WLAN products around the world. Even though WLAN has been designed and

used for mostly indoor applications, the possible use of WLAN technologies for high

mobility outdoor applications, such as, telemetry, traffic surveillance, rescue operations,

and outdoor data networking can provide reasonably high data rates at minimal operational

costs. For outdoor applications WLANs provide support for link-layer handoff, which is

used to switch a mobile node (MN) from one access point (AP) to another. For WLANs










connected by an IP backbone, Mobile IP[Perk02] is the protocol for location management

and network-layer handoff. These attractions led us to investigate the performance of MIP

over WLAN in outdoor rapid moving environments.

In this dissertation, Chapter 2 introduces related research in the area of mobile

network protocols, wireless LAN standards, layer 3 and layer 2 handoff mechanisms and

location tracking technologies. Chapter 3 introduces a protocol evaluation testbed,

RAMON. The performance of MIP over wireless LAN and its relationship to speed are

shown in Chapter 3 as well. Chapter 4 breaks down the handoff procedure of MIP over

wireless LAN and presents a quantitative analysis of the handoff latency. A speed adaptive

MIP protocol is proposed in Chapter 5 and the performance for this protocol is evaluated.

Chapter 6 summarizes the dissertation and presents future works.
















CHAPTER 2
RELATED WORK

Mobile computing and networking try to provide users confident accesses to the

Internet anytime, anywhere. One big challenge for mobile computing and networking is

how to manage global and seamless roaming among various access technologies. Mobility

management contains two components: location management and handoff management

[Akyi99]. In wireless network, there are two kinds of roaming, interdomain and

intradomain roaming. Interdomain roaming, also called macromobility, refers to roaming

among different domain of systems. Intradomain roaming, also called micromobility,

refers to roaming among different cells in the same domain or system. In this chapter we

will introduce network layer handoff management of macro/micro mobility, wireless LAN

protocol standards and technologies to reduce handoff latency for wireless LAN and

Mobile IP network. At the end of this chapter, some research works on location tracking

will be introduced.

Network Layer Handoff Management

Macro Mobility protocols aim to handle global moving of users. An example is

mobile IP[RFC3344]. Micro-mobility protocols are used to handle local moving (e.g.,

within a domain) of mobile hosts without interaction with the Mobile IP enabled internet.










Hierarchical MIP, Cellular IP, IntraDomain Mobility Protocol(IDMP), HAWAII are

examples of micro mobility protocols. Figure 2-1 shows the macro and micro mobility.



HA

acro mobilityTERNET



Macro mobility -SA
hand
cro mobility Micro mobility.
handoff ando



Figure 2-1 Macro and Micro mobility

Mobile IP

IP mobility support for IPv4 is specified in RFC3344. The Mobile IP protocols

support transparency above the IP layer, including maintenance of active TCP connections

and UDP port bindings. It allows a node to continue using its 'permanent' home address no

matter where the node physically attached to. Therefore, ongoing network connections to

the node can be maintained even as the mobile host is moving around the internet.

Mobile IP defines three functional entities where its mobility protocols must be

implemented: Mobile Node(MN), Home Agent(HA) and Foreign Agent(FA).

MN is a movable device whose software enables network roaming capabilities.

FA is a router that may function as the point of attachment for the MN when it roams

to a foreign network, delivering packets from the HA to the MN. Mobile IP works by

allowing the MN to be associated with two IP addresses: a home address and a dynamic,










Care-of Address(CoA). Home address is fixed IP address the MN gets from its home

network. The CoA is the termination point of the tunnel toward the MN when it is on a

foreign network. CoA changes at each new point of attachment to the Internet.

HA is a router on the home network serving as the anchor point for communication

with the MN; it tunnels packets from a device on the Internet, called a Correspondent

Node(CN), to the roaming MN. (A tunnel is established between the HA and a reachable

point for the MN in the foreign network.). The HA maintains an association between the

home IP address of the MN and its CoA, which is the current location of the MN on the

foreign or visited network. The MN's movement is invisible to the CN.

Figure 2-2 shows the three functional entities and routing of datagrams transmitted

from a MN away from home. When a MN moves, it finds an agent on its local network by

the Agent Discovery process. It listens for Agent Advertisement messages sent out by FAs

or HAs. If it doesn't hear these messages it can sent Agent Solicitation message to ask for

it. From the Agent Advertisement message, the MN determines whether it is on its home

network or a foreign one. The MN works like any fixed node when it's on its home

network. When the MN moves away from its home network, it obtains a CoA on the

foreign network. The MN registers each new CoA with its HA while away from home.

This may be done either directly between the MN and the HA, or indirectly using the FA as

a conduit. The packets from CN are tunneled by HA to FA then to the CoA. The packets

from MN to CN are either directly routed to the CN or reverse-tunneled from FA to HA

then to the CN.













Global Intemet
FA HA







Figure 2-2 Three functional entities of MIP


MIP has three main processes, Agent discovery, registration and tunneling.

Agent discovery

The Mobile IP agent discovery process makes use of ICMP Router Advertisement

Protocol(RFC 1256) and add one or more MIP extensions. HAs and FAs periodically

broadcast a router advertisement ICMP messages with an advertisement extension. The

router advertisement portion of the message includes the IP address of the router. The

advertisement extension includes additional information such as lift time, care-of-address,

etc. A MN listens for these agent advertisement messages. If a MN needs to get a care-of

address and does not want to wait for that long time, the MN can broadcast or multicast an

agent solicitation(also an ICMP message) and then listens for the agent advertisement

messages. Another important rule of agent discovery process is movement detection. This

can be done in two ways. One way is to make use of Lifetime field in the agent

advertisement message. When a MN receives an agent advertisement from a FA that it is

currently using or that it is now going to register to, it records the lifetime field as a timer.

If the timer expires before the agent receives another advertisement from the agent, then










the node assumes that it has lost contact with that agent. In this situation, the MN may

choose to wait for another advertisement or to send an agent solicitation. Another way is to

use network prefix. The MN checks whether any newly received agent advertisement is on

the same network as the current care-of address of the node. If it is not, the MN assumes

that it has moved and uses the new advertisement.

The MN can also get a collocated care-of-address acquired from a Dynamic Host

Configuration Protocol (DHCP) server. In this case, the MN acts as its own FA.

The agent advertisement extension consists of the following fields:

0 1 2 3
01 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Type I Length I sequence Number I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime IRIB|HIFMIGI|rTTI reserved I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |


Type: 16, indicates that this is an agent advertisement.
Length: (6 + 4N), where N is the number of care-of addresses advertised.
Sequence number: The count of agent advertisement messages sent since the
agent was initialized.
Lifetime: The longest lifetime, in seconds, that this agent is willing to accept a
registration request from a mobile node.
R: Registration required. Registration with this foreign agent (or another foreign
agent on this link) is required even when using a co-located care-of address.
B: Busy. The foreign agent will not accept registrations from additional mobile
nodes.
H: This agent offers services as a home agent on this network.
F: This agent offers services as a foreign agent on this network.
M: This agent can receive tunneled IP datagrams that use minimal encapsulation.
G: This agent can receive tunneled IP datagrams that use Generic Routing
Encapsulation (GRE).
r: Set as zero; ignored on reception.
T: Foreign agent supports reverse tunneling.
Care-of Address(es): The care-of address or addresses supported by this agent











Registration


When a MN realizes that it is on a foreign network and has acquired a


care-of-address, it needs to notify the HA by sending a registration request message so that


the HA can forward IP packets between MN and CN. There are two kinds of registration


messages, registration request and registration reply, both sent to User Datagram Protocol


(UDP) port 434. The MN sends the request to the FA, which then relays the request to the


home agent. If the MN is using a collocated care-of-address, the MN sends its request


directly to the HA, using collocated care-of-address as the source IP address of the request.


The registration request message consists of the following fields:

0 1 2 3
01 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Type ISIBIDIMIGI|rTI|I Lifetime
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Home Agent I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+ Identification +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SExtensions ...
+-+-+-+-+-+-+-+-
Type: 1, indicates that this is a registration request.
S: Simultaneous bindings. When set, the mobile node is requesting that the home
agent retain its prior mobility bindings. The home agent will forward multiple
copies of the IP datagram, one to each care-of address currently registered for this
mobile node.
B: Broadcast datagrams. Indicates that the mobile node would like to receive
copies of broadcast datagrams that it receives if it were attached to its home
network.
D: Decapsulation by mobile node. The mobile node is using a collocated care-of
address and will decapsulate its own tunneled IP datagrams.
M: Indicates that the home agent should use minimal encapsulation.
G: Indicates that the home agent should use GRE encapsulation.










R: Sent as zero; ignored on reception.
T: Reverse Tunneling requested.
X: Set as zero; ignored on reception.
Lifetime: The number of seconds before the registration is considered expired. A
value of zero is a request for deregistration.
Home address: The home IP address of the mobile node.
Home agent: The IP address of the mobile node home agent.
Care-of address: The IP address for the end of the tunnel. The home agent
should forward IP datagrams that it receives with the mobile node home address
to this destination address.
Identification: A 64-bit number generated by the mobile node, used for matching
registration requests to registration replies and for security purposes.
Extensions: authentication extension must be included, and other optional
extensions.

The registration reply message consists of the following fields:

0 1 2 3
01 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S Type I code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I I
+ Identifi cation +
I I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SExtensions ...
+-+-+-+-+-+-+-+-

Type: 3, indicates that this is a registration reply.
Code: Indicates result of the registration request. 0 for registration accepted, 77
for invalid care-of address, etc.
Lifetime: If the code field indicates that the registration was accepted, the
number of seconds before the registration is considered expired. A value of zero
indicates that the mobile node has been deregistered.
Home address: The home IP address of the mobile node.
Home agent: The IP address of the mobile node home agent.
Identification: A 64-bit number used for matching registration requests to
registration replies.
Extensions: authentication extension must be included, and other optional
extensions.

The identification field of the registration request and reply messages and the


authentication extension are used to protect replay attack. The Identification value enables










the mobile node to match a reply to a request. Two methods are described in RFC 3344:

timestamps mandatory ) and noncess" (optional).

An authentication extension consists the following fields:

Type: Used to designate the type of this authentication extension. 32 for MN-HA,
33 for MN-FA, 34 for FA-HA.
Length: 4 plus the number of bytes in the authenticator.
Security parameter index (SPI): An index that identifies a security context
between a pair of nodes. This security context is configured so that the two nodes
share a secret key and parameters relevant to this association (for example,
authentication algorithm).
Authenticator: The value used to authenticate the message. The default
authentication algorithm uses HMAC-MD5[RFC2104] to compute a 128-bit
"message digest" of the registration message.

Tunneling

After a successful registration, the home agent must be able to intercept datagrams

destined to the mobile node and tunnel them to the mobile node's care-of-address. The

tunneling can be done by one of several different encapsulation algorithms, IP in IP

encapsulation [RFC2003], Minimal encapsulation [RFC2004] and GRE encapsulation

[RFC 1701]. By default, home agents and foreign agents must support tunneling datagrams

using IP in IP encapsulation. Any mobile node that uses a collocated care-of address must

support IP in IP encapsulation. In IP-within-IP encapsulation, the original entire IP

datagram becomes the payload in a new IP datagram. The original IP header is unchanged

except to reduce Time To Live (TTL) by 1. The outer IP header is a full IP header. Two

fields are copied from the inner IP header: The version number, 4, which is the protocol

identifier for IPv4, and the type of service field. Figure 2-3 is the IP in IP encapsulation and

minimal encapsulation format.






13



.-,I------|- ------





u mi I nuimal foihgl IP hn te b -rtwen the origina lIP-------
a hea erIs'- .'- Ow t oM form a new out e I
c 'B R IfIl -- ---








Figure 2-3 IP in IP encapsulation and minimal encapsulation

Minimal encapsulation results in less overhead but is little complicated than IP in IP


encapsulation. It can only be used if the MN, HA, and FA all agree to use it. With minimal




and the original IP payload. The original IP header is modified to form a new outer IP

header. The minimal forwarding IP header includes the following fields:

Protocol: Copied from the protocol field in the original IP header. It identifies the
protocol type of the original IP payload.
S: If 0, the original source address is not present, and the length of this header is 8
octets. If 1, the original source address is present, and the length of this header is
12 octets.
Header checksum: Computed over all the fields of this header.
Original destination address: Copied from the Destination Address field in the
original IP header.
Original source address: Copied from the Source Address field in the original IP
header. This field is present only if the S bit is 1. The field is not present if the
encapsulator is the source of the datagram.










The new outer IP header is modified from the original IP header. The modified field

are as following.

Total length: Incremented by the size of the minimal forwarding header (8 or
12).
Protocol: 55, indicts the following header is minimal IP encapsulation header.
Header checksum: recomputed over all the fields of this header.
Source address: The IP address of the encapsulator, typically the home agent.
Destination address: The IP address of the end of the tunnel, the care-of address.

Mobile IP is a macro mobility management protocol. MIP-based mechanisms use a

flat hierarchy, whereby every change in the MN's point of attachment requires a global

binding update. Frequent global binding updates can not only incur high latency, thereby

making rapid handoffs impossible, but also significantly increase the overall signaling

overhead, especially when the number of MNs increases. Various solutions have been

proposed to solve this problem. All these solutions implicitly or explicitly use a concept of

micro-mobility regions where registrations with the home agent are not necessary if the

MN is moving within these regions. Only if the MN moves between micro-mobility

regions, registrations with the HA would be required. Micro-mobility management

protocols are designed to reduce the high handoff latency of Mobile IP by handling

mobility within micro-mobility regions.

The micro-mobility protocols can be categorized in two types: Hierarchical

Tunneling and Mobile-Specific Routing [Camp02]. Hierarchical tunneling schemes rely

on a tree-like structure of FAs. In Hierarchical tunneling schemes HA delivers

encapsulated traffic to the root FA. Each FA on the tree decapsulates and then

re-encapsulates data packets while they forward the data down the FA tree towards the









MN's point of attachment. As the MN moves between two FAs, location updates are made

at the optimal point in the tree, which is the common root of the two FAs. Hierarchical

Mobile IP[Soli02]) is an example of Hierarchical tunneling scheme.

Mobile-Specific Routing schemes avoid the overhead introduced by decapsulation

and re-encapsulation in hierarchical tunneling schemes. These proposals use mobile

specific routes to forward packets toward a MN's point of attachment. Examples of

micro-mobility protocols that use mobile-specific routing include Cellular IP and

HAWAII.

Hierarchical MIP

The Hierarchical Mobile IP (HMIP)

employs a hierarchy of FAs to locally handle
TNTERNET
Mobile IP registration. In this protocol MNs

send mobile IP registration request messages FA

to update their respective location,

information. The Registration messages -
F F At
establish tunnels between neighboring FAs /

along the path from the mobile host to a

gateway foreign agent(GFA). Packets Figure 2-4 Hierarchical MIP

addressed to mobile hosts travel through these tunnels from the GFA to MN. Figure 3-4

illustrates the operation of Hierarchical Mobile IP. The red dash arrow is a regional

registration, which only need to reach a local entity, GFA. The blue real arrow is a normal










registration, which have to traverse the whole network to the HA. For the purposes of

managing hierarchical tunneling the location register is maintained in a distributed form by

a set of Mobility Agents (MA), i.e. GFAs. Each MA reads the original destination address

of the incoming packets and searches its visitor list for a corresponding entry. The entry

contains the address of the next MA one level lower in the hierarchy. Such entries are

created and maintained by registration messages transmitted by MNs. [Soli02]

Cellular IP

The Cellular IP (CIP) protocol[Cam99] from Columbia University and Ericsson

supports fast handoff and paging techniques. Cellular IP inherits features found in cellular

networks, such as, seamless mobility, passive connectivity and paging, for mobile IP hosts.

It uses Mobile IP to provide interconnectivity between a set of Cellular IP access networks,

which in turn provide a cellular internetworking environment. The Cellular IP access

networks will be connected to the Internet via gateway routers. In that case, host mobility

between gateways(i.e., Cellular IP access networks) will be managed by Mobile IP, while

mobility within access networks will be handled by Cellular IP. MNs attached to the

network use the IP address of the gateway as their Mobile IP care-of address. The data

packets from CN to MN will be first routed to MN's HA and then tunneled to the gateway.

The gateway "detunnels" packets and forwards them toward base stations. Inside the

Cellular IP network, data packets are routed directly to the MN. Data packets from MN to

CN are first routed in the cellular IP network to the gateway and from there on to the










HA[CampOO]. The following presents an overview of the Cellular IP routing, handoff and

paging algorithms

Routing

In Cellular IP, location management and handoff support are integrated with routing.

To minimize control messaging, regular data packets transmitted by mobile hosts are used

to refresh host location information. Uplink packets are routed from MN to the gateway

on a hop-by-hop basis. The path taken by these packets is cached in base stations, which is

call route cache. Cellular IP uses mobile originated data packets to maintain reverse path.

This path is used to route downlink packets addressed to a mobile host. When the mobile

host has no data to transmit then it periodically sends empty IP packets to the gateway to

maintain its downlink routing state. The loss of downlink packets when a mobile host

moves between access points is reduced by customized handoff procedures. Cellular IP

supports two types of handoff scheme, hard handoff and semi-soft handoff

Handoff

The Cellular IP hard handoff algorithm is based on simple approach that trades off

some packet loss in exchange for minimizing handoff signaling. Hard handoff causes

packet losses proportional to the round-trip time and to the downlink packet rate. Mobile

hosts listen to beacons transmitted by base stations and initiate handoff based on signal

strength measurements. To perform a handoff, a mobile host tunes its radio to a new base

station and sends a route-update packet. The route-update message creates routing cache










mappings on route to the gateway hence configures the downlink route to the new base

station.

Cellular IP semi-soft handoff exploits the notion that some mobile hosts can

simultaneously receive packets from the new and old base stations during handoff During

semi-soft handoff a mobile host may be in contact with either the old and new Base

Stations and receives packets from them. Packets intended to the mobile host are sent to

both Base Stations, so when the mobile host eventually moves to the new location it can

continue to receive packets without interruption. To initiate semi-soft handoff, the moving

mobile host transmits a route-update packet to the new Base Station and continues to listen

to the old one. The S flag is set in this route-update packet to indicate semi-soft handoff

Semi-soft route-update packets create new mappings in the Route and Paging Cache

similarly to regular route-update packets. When the semi-soft route-update packet reaches

the crossover node where the old and new path meet, the new mapping is added to the

cache instead of replacing the old one. Packets sent to the mobile host are transmitted to

both Downlink neighbors. When the mobile host eventually makes the move then the

packets will already be underway to the new Base Station and the handoff can be

performed with minimal packet loss. After migration the mobile host sends a route-update

packet to the new Base Station with the S bit cleared. This route-update packet will remove

all mappings in the Route Cache except for the ones pointing to the new Base Station. The

semi-soft handoff is then complete. If the path to the new Base Station is longer than that to

the old Base Station or if it takes non-negligible time to switch to the new Base Station,










then some packets may not reach the mobile host. To overcome the problem, packets sent

to the new Base Station can be delayed during semi-soft handoff. This way a few packets

may be delivered twice to the mobile host, but in many cases this results in better

performance than a few packets lost. Introduction of packet delay can be best performed in

the Cellular IP node that has multiple mappings for the mobile host as a result of a

semi-soft route-update packet. Packets that belong to flows that require low delay, but can

tolerate occasional losses, should not be delayed.

Semi-soft handoff minimizes packet loss providing improved TCP and UDP

performances over hard handoff. Distinguishing idle and active mobile hosts reduces

power consumption at the terminal side. The location of idle hosts is tracked only

approximately by Cellular IP. Therefore, mobile hosts do not have to update their location

after each handoff This extends battery life and reduces air interface traffic. When packets

need to be sent to an idle mobile host, the host is paged using a limited scope broadcast. A

mobile host becomes active upon reception of a paging packet and starts updating its

location until it moves to an idle state again.

Paging

If a mobile host has not received data packets for a system specific time

active-state-timeout, it becomes idle. The idle mobile hosts allow their soft-state routing

cache mappings to be time out. Idle hosts transmit empty IP packets(paging-update

packets) at regular intervals(paging-update-time) to the gateway. Paging-update packets

are sent to the base station that offers the best signal quality. Paging-update packets are










also routed on a hop-by-hop basis to the gateway. Base stations may optionally maintain

paging cache. A paging cache has the same format and operation as a routing cache except

for two differences. First, paging cache mappings have a longer timeout period called

paging-timeout. Second, paging cache mappings are updated by any packet sent by mobile

hosts including route-update packets and paging-update packets. This results in idle

mobile hosts having mappings in paging caches but not in routing caches. If the base

station has no paging cache, it will forward the packet to all its interfaces except for the one

the packet came through. Paging cache is used to avoid broadcast search procedures found

in cellular systems. Base stations that have paging cache will only forward the paging

packet if the destination has a valid paging cache mapping and only to the mapped

interface(s)[Camp00].

HAWAII

The Handoff Aware Wireless Internet Infrastructure (HAWAII)

protocol [Ramj99][Ramj02] proposes a separate routing protocol to handle intra-domain

mobility. All issues related to mobility management within one domain are handled by a

gateway called a domain root router. A MN entering a new foreign agent domain is

assigned a collocated care-of address. The MN retains its care-off address unchanged

while moving within the foreign domain, thus the HAs does not need to be involved unless

the MN moves to a new domain. In this case, packets for the MN are intercepted by its HA

first. The HA tunnels the packets to the domain root router serving the MN. The domain

root router routes the packets to the MN using the host-based routing entries. When the










MN moves between different subnets of the same domain, only the route from the domain

root router to the BS serving the MN is modified, and the remaining path remains the same.

Thus, during an intra-domain handoff, the global signaling message load and handoff

latency are reduced.

HAWAII path setup messages

There are three types of HAWAII path setup messages: powerup, path refresh, and

path update. On power up a mobile host sends a Mobile IP registration request message to

the corresponding base station. The base station then sends a HAWAII path setup

power-up message to the domain root router which is processed in a hop-by-hop manner.

This has the effect of establishing host specific routes for that mobile host in the domain

root router and any intermediate routers on the path towards the mobile host. The domain

root router finally acknowledges this path setup power-up message to the base station

which finally notifies the mobile host with a Mobile IP registration reply.

If a router knows multiple paths to the domain root router, it can use any of them but

it always has to use the same route for a specific host. The routing entries in the routers are

soft-state, i.e. they have to be refreshed periodically by path setup refresh messages, which

are sent independently by each network node and which can be aggregated. This increases

the robustness of the protocol to router and link failures. The mobile host infrequently

sends periodic path refresh messages to its base station to maintain the host based entries.

The base station and the intermediate routers, in turn, send periodic aggregate hop-by-hop

refresh messages towards the domain root router. Path setup messages are sent to only










selected routers in the domain, resulting in very little overhead associated with maintaining

soft-state.

While the mobile host moves within a domain, maintaining end-to-end connectivity

to the mobile host requires special techniques for managing user mobility. HAWAII uses

path setup update messages to establish and update host-based routing entries for the

mobile hosts in selective routers in the domain so that packets arriving at the domain root

router can reach the mobile host with limited disruption. The choice of when, how, and

which routers are updated constitutes a particular path setup scheme.

HAWAII Path Setup Schemes

The HAWAII handoff procedures are only activated when the mobile host's next

hop IP node is changed during the handoff [Ramj02] assumes base stations have IP

routing functionality and uses a tree-based topology for clarity, but the schemes will also

provide for non-tree-based topologies.

[Ramj99] defines two schemes for implementing Handoff procedures within the

domain, the forwarding and the non-forwarding scheme. The cross-over router is defined

as the router closest to the mobile host that is at the intersection of two paths, one between

the domain root router and the old base station, and the second between the old base station

and the new base station.

Non-forwarding path update scheme

The non-forwarding path set-up is a two way Update handshake process. It is

initiated by the Mobile Station sending an Update to the new Base Station. The path setup










Update message consists of the Mobile Station IP address, the old and new Base Station

address, and some other informations. The following is the algorithm:

Step 1: Update the Cache with the combination of the IP address of the Mobile

Station and the port on which the Update was received. This builds an element in a

"reverse" chain in the direction from the current node towards the new Base Station. If the

current node is the old Base Station, it sends an acknowledgement to the Mobile Station

directly via the air interface. This completes the procedure and the old Base station will not

receive further datagrams for the Mobile Station. The path from the gateway to the new

Base Station will be refreshed, the rest (from the Crossover router to the old Base Station)

will not and times out shortly.

Step 2: (recipient is not the old Base Station) The node extracts the forwarding port

for the old Base Station from the routing table, and forwards the Update. Step 1 is then

revisited.

Forwarding path update scheme

The forwarding path set-up is initiated by the Mobile Station. Its also a two way

Update handshake process. The Mobile Station sends the old Base Station an Update

message, which consists of the Mobile Station IP address, the old and new Base Station

addresses, and some other informations. The following is the algorithm:

Step 1: If the node receiving the Update is the new Base Station, it sends an

acknowledgement to the Mobile Station directly via the air interface, and updates the

Cache with the IP address and port number for the Mobile Station. This completes the










procedure, leaving two Soft-state paths. One leading from the old to the new Base Station,

and the other from the gateway, via the Crossover router, to the new Base Station. The

second path will be refreshed while the first will time out shortly.

Step 2: (recipient is not the new Base Station) The node extracts the forwarding port

for the new Base Station from the routing table, and updates the Cache with the IP address

of the Mobile Station and this port number. Step 1 is then revisited. The Forwarding path

set-up scheme packets in transit towards the old router are then forwarded from the Old

Base Station to the new Base Station until the flow is diverted at the Crossover router.

The non-forwarding scheme is optimized for networks where the Mobile Station can

listen/transmit to multiple base stations simultaneously, as in the case of Code Division

Multiple Access (CDMA) networks. The forwarding scheme is optimized for networks

where the Mobile Station can listen/transmit to only one base station, as in the case of a

Time Division Multiple Access (TDMA) network. Both schemes ensure no BSS internal

loss of in transit datagrams during handoff.

Wireless LAN

Technology Overview

Over recent years, the market for wireless communications has experienced

incredible growth. Wireless technologies have quickly found a significant place and

popularity in business and the computer industry. Their major motivation and benefit is

increased flexibility and mobility. Unlike a wired LAN, which requires a wire to access the

network, a Wireless LAN connects computers and other components to the network via an










Access Point (AP). Wireless LANs offer several fundamental benefits including user

mobility, rapid installation, flexibility and scalability. However, there are some primary

limitations [Gast02].

The speed of wireless networks is constrained by the available bandwidth.
Radio waves can suffer from a number of propagation problems that may
interrupt the radio link, such as multi-path interference and shadows.
On Wire LAN, sniffing is much easier because the radio transmissions are
designed to be processed by any receiver within range. Security is still a prime
concern.

The IEEE 802.11 Working Group was formed in September of 1990. Their goal was

to create a wireless LAN specification that will operate in one of the Industrial, Scientific,

and Medical frequency(ISM) ranges. The first 802.11 standard was released in 1997. The

latest version is the 1999 edition. The official name of 802.11 is IEEE Standards for

Information Technology -- Telecommunications and Information Exchange between

Systems -- Local and Metropolitan Area Network -- Specific Requirements -- Part 11:

Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.

The 802.11 protocols address the Medium Access Control (MAC) and Physical (PHY)

layers independently. The MAC layer handles moving data between the link layer and the

physical medium. Figure 2-5 shows how the OSI model match up to the 802.11 standards.

The 802.11 Established Standards

The 802.11 suite has the four established standards: 802.11, 802.1 lb, 802.1 la and

802.1 Ig. The IEEE is continuing to work on new standards that will extend the physical

layer options, improve security, and add quality of service (QoS) features. In the following

several sections, we will brief introduce these four standards [80211].














Annlication

Presentation
Session
ISO/OSI esson IEEE 802.11
7-layer Transnort
model
Network Logical Link Control

Data Link Medium Access (MAC)


Physical Physical (PHY)


Figure 2-5 OSI model vs. IEEE802.11 standard

Standard 802.11

802.11 was the first IEEE standard used for wireless data networking applications

with maximum data transfer rates at 2 Mbps in the 2.4 GHz radio band. Within 802.11, two

different modulation schemes are supported that can be used to transmit data signals.

The first modulation scheme is frequency-hopping spread spectrum(FHSS). This

transmission technique is used in WLAN transmissions where the data signal is modulated

with a narrowband carrier signal that "hops" in a random sequence from frequency to

frequency as a function of time over a wide band of frequencies. This technique reduces

the chances of interference.

The other modulation scheme is direct-sequence spread spectrum (DSSS). In this

method of transmission, the signal does not hop from one frequency to another but is

passed through a spreading function and distributed over the entire band at once. DSSS










usually provides slightly higher data rates and shorter delays than FHSS, because the

transmitter and receiver don't have to spend time returning. DSSS avoids interference by

configuring the spreading function in the receiver to concentrate the desired signal but

spread out and dilutes any interfering signal. A data signal at the sending station is

combined with a higher data rate bit sequence, or chipping code, that divides the user data

according to a spreading ratio. The chipping code, a redundant bit pattern for each bit that

is transmitted, increases the signal's resistance to interference. If one or more bits in the

pattern are damaged during transmission, the original data can be recovered due to the

redundancy of the transmission.

Although the 802.11 standard supports both modulation schemes, the two types of

spread spectrum technologies are not compatible. The number of channels used by 802.11

compliant products depends on the modulation scheme used. More specifically,

FHSS-based products use 79 channels of the Unlicensed National Information

Infrastructure (UNII) band, whereas DSSS-based products use either 3 non-overlapping

channels or 6 overlapping channels of the Industrial, Scientific, and Medical (ISM) radio

band. Some of the common characteristics specified by the 802.11 standard are listed in

Table 2-1.










Table 2-1 Characteristics specified by the 802.11 standard
Characteristic 802.11 Description
Application Wireless data networking
Data Rate 1-2 Mbps
Typical Operating Frequency Band ISM band: 2.4 to 2.4835 GHz.
Modulation Mechanism FHSS or DSSS, CRC-16 in header
Channels available 79 channels with FHSS; 3 or 6 channels with DSSS
Coverage 40m to 400m
Mobility Roaming between APs by mobile IP
Security 128-bit WEP
Link Layer Carrier Sense Multiple Access With Collision Avoidance
(CSMA/CA) with request to send (RTS)/clear to send (CTS)

Standard 802.11b

IEEE 802.1 lb[80211b] is the first enhancement 802.11 standard to be ratified in

1999. 802.1 lb uses the same radio signaling frequency(2.4GHz) as the original 802.11

standard. The 802.1 lb standard specifies operation on three channels in the 2.4-2.4835

GHz spectrum. 802.1 lb can transmit data up to 11 Mbps but will scale down to 1 Mbps

based on conditions.

802.1 lb uses DSSS modulation scheme to transmit data signals through the 11

available channels(3 non-overlapping). This unlicensed portion of the radio band shares

space with many low-power signals from home electronics, including microwave ovens,

cordless telephones, Bluetooth-enabled devices, and garage-door openers. 802.1 lb

compliant products have a range of up to 400 meters in ideal conditions and will be

compatible with the products that meet the new 802.1 Ig standard when it is finalized.

Some of the key characteristics specified by the 802.1 lb standard are shown in Table 2-2.










Table 2-2 Characteristics specified by the 802.1 lb standard
Characteristics 802.11b Description
Application Wireless data networking
Data Rate (Mbps) 1, 2, 5.5, 11
Typical Operating Frequency Band ISM band: 2.4 to 2.4835 GHz
Channels available 11 (3 non-overlapping)
Modulation Mechanism DSSS
Coverage (m) 40 to 400
Mobility Roaming between APs by mobile IP devices
Security 128 bit WEP
Link Layer CSMA/CA with RTS/CTS

Pros of 802.1 lb lowest cost; signal range is best and is not easily obstructed.

Cons of 802.1 lb Speed and channel restriction are significant limitations of

802.1 lb compliant networks. Interference within one's own 802.1 lb network becomes

more likely as the number of users and APs increase. Similarly, interference is more likely

as 802.1 lb compliant networks are deployed near each other. 802.1 lb products share the

bandwidth with other low-power signals, and thus, problems may arise when the

technology is used near some electronic devices such as microwave ovens,

Bluetooth-enabled devices, and cordless telephones.

Standard 802.11a

802.1 la[8021 la], a High-speed Physical Layer in the 5 GHz band standard for

WLANs, was completed in September 1999. It is offered in the 5 GHz radio (UNII) band,

and operates on 8 channels; however, the available radio spectrum in some countries

permits the use of 12 channels. The additional number of channels used in the higher

spectrum yields less interference from neighboring APs. The Federal Communications

Commission (FCC) has divided the total of 300 megahertz (MHz) frequencies used by










802.1 la WLANs into 3 distinct 100 MHz domains, each with a different legal maximum

power output. The "low" band operates in the 5.15-5.25 GHz range and has a maximum

output power of 50 milliwatts (mW). The "middle" band is located in the 5.25-5.35 GHz

range, with a maximum of 250 mW. The "high" band uses the 5.725-5.825 GHz range,

with a maximum of 1 Watt. Because of the high power output, most devices transmitting

in the high band are building-to-building bridge products. The low and medium bands are

more suited to in-building wireless products.

802.1 la transfers data at rates of up to 54 Mbps in the available radio spectrum,

which is up to five times faster than 802.1 lb compliant networks. More commonly,

however, 802.1 la compliant networks communications are at the 6 Mbps, 12 Mbps, or

24 Mbps data rates. As the distance between the user and the AP increases, the data rate

decreases.

802.1 la compliant networks use Orthogonal Frequency Division Multiplexing

(OFDM) modulation to provide these data rates. OFDM is a type of digital modulation in

which a signal is divided into separate channels at different frequencies. Table 2-3 show

the major characteristics of 802.1 la standard.

Pros of 802.11a speed as 5 times as 802.1 lb; supports more simultaneous users;

regulated frequencies prevent signal interference from other devices

Cons of 802.11a shorter range signal that is more easily obstructed; shorter range

costs more APs to cover the same area as an 802.1 lb network; consume more power than

802.1 lb products.










Table 2-3 Characteristics specified by the 802.1 la standard
Characteristic 802.11 a Description
Application Wireless data Networking
Data Rate (Mbps) 6, 9, 12, 18, 24, 36, 48, and 54 Mbps. Rates of 6, 12, and
24 Mbps are mandatory for all products.
UNIIband: 5.15-5.25 GHz, 5.25-5.35 GHz, and
Typical Operating Frequency Band
5.725-5.825 GHz
Channels Available 12 non-overlapping
Modulation Mechanism OFDM- Orthogonal Frequency Division Multiplexing
Coverage (m) < 100
Mobility Roaming between APs by mobile IP devices
Security 128-bit WEP, 64-bit WEP, 152-bit WEP
Link Layer CSMA/CA with RTS/CTS


802.1 la was ratified after 802.1 lb was already penetrating the market, so even

though it offers higher speed and frequency, it may not be worth the switch for users who

have already invested in 802.1 lb technology. Because 802.1 la and 802.1 lb utilize

different frequencies, the two technologies are incompatible with each other. Some

vendors offer hybrid 802.1 la/b network gear, but these products simply implement the two

standards side by side.

802.11g

IEEE 802.1 Ig was ratified as a standard in Jun. 2003. It operates in the same 2.4

GHz range as 802.1 lb but offers the same speed up to 54 Mbps as 802.1 la does. This

standard features increased data transmission rates while maintaining interoperability with

802.1 lb compliant products. The standard uses the same modulation scheme OFDM as

802.1 la to achieve data rates from 22 Mbps to up to 54 Mbps; however, 802.1 g products

will be backward compatible with 802.1 lb products that use the modulation scheme

DSSS. The backward compatibility feature allows an 802.1 lb compliant client adapter










card to interact directly with an 802.1 Ig compliant AP. Communications between 802.1 Ig

and 802.1 lb devices are limited to data rates up to 11 Mbps. The common characteristics

specified by the 802.1 Ig standard are shown in Table 2-4.

Table 2-4 Characteristics specified by the 802.1 Ig standard
Characteristics 802.11 g Description
Application Broadband Wireless LAN Access
Data Rate (Mbps) 6, 9, 12, 18, 24, 36, 48, 54
Typical Operating Frequency Band ISM band: 2.4 to 2.4835 GHz
Channels available 3 non-overlapping
Modulation Mechanism OFDM/DSSS
Coverage (m) 20 to 400
Mobility Roaming between APs by mobile IP devices
Security 128 bit WEP
Link Layer CSMA/CA with RTS/CTS

Pros of 802.11g fast speed as up to 54mbps; supports more simultaneous users;

signal range is better than 802.11 a and is not easily obstructed

Cons of 802.11g costs more than 802.1 lb; just like 802.1 la, appliances may

interfere on the unregulated signal frequency when the technology is used near some

electronic devices such as microwave ovens, Bluetooth-enabled devices, and cordless

telephones.

Table 2-5 provides a comparison of the primary 802.11 standards.












Table 2-5 Comparison of characteristics specified within the IEEE 802.11 suite

Characteristics 802.11 802.11a 802.11b 802.11g
UNII 5 15-5 25 GHz,
Spectrum Band ISM 2 4 to 2 4835 GHz 5 25-5 35 GHz, and ISM 2 4 to 2 4835 GHz ISM 2 4 to 2 4835 GHz
5 725-5 825 GHz
Modulation Scheme FHSS or DSSS OFDM DSSS OFDM or DSSS
Number of Channels 79 channels with FHSS,
12 3 3
(non-overlapping) 3 or 6 channels with DSSS
Optimum Data Rates
2 54 11 54
(Mbps)
Range (meters) 400 100 400 400
Date established July 1997 September 1999 July 1999 June 2003
Compatibility 80211 only 802 lla 802 lb 802 llb/g
North America, Europe, North America, Europe,
Operability North America, Europe, Asia NorthAmerica, Europe, Asia
Asia Asia


Pending Specifications Within the 802.11 Suite

IEEE 802.1 la, lb, 1 Ig are major standard of wireless networking. There are


various other standards which were developed to improve the transmission of data and


promote the effective communication. The following are current standards which enhance


and expand the functionality of the overall 802.11 protocol.[STD802]

IEEE 802.11c: Defines wireless bridge operations
IEEE 802.11d: Defines standards for companies developing wireless products in
different countries.
IEEE 802.11e: Defines enhancements to the 802.11MAC for QoS.
IEEE 802.11f: Defines Inter Access Point Protocol (IAPP)
IEEE 802.11i: Improved encryption
IEEE 802.11j: 802.11 extension used in Japan.
IEEE 802.11n: New standard expected to be completed in 2005 that is expected
to support up to 100Mbps.










The IEEE 802.11 Wireless LAN Architecture

The 802.11 architecture is comprised of several components and services that

interact to provide station mobility transparent to the higher layers of the network stack.

The major components and services in Wireless LAN are as followings [Jain03].

Wireless LAN Station

The wireless LAN station (STA) is the most basic component of the wireless

network. A station is any device that implements the MAC and PHY functionality of the

802.11 protocol. Typically the 802.11 functions are implemented in the hardware and

software of a network interface card (NIC). A station could be a laptop PC, PDA, or an

Access Point. Stations may be mobile, portable, or stationary and all stations support the

802.11 station services of authentication, de-authentication, privacy, and data delivery.

Basic Service Set (BSS)

802.11 defines the Basic Service Set (BSS) as the basic building block of an 802.11

wireless LAN. The BSS consists of a group of stations.

The Topologies could be Independent Basic Service Set (IBSS), Infrastructure Basic

Service Set(BSS) or Extended Service Set (ESS)

Independent Basic Service Set (IBSS)

The most basic wireless LAN topology is a set of stations, which have recognized

each other and are connected via the wireless media in a peer-to-peer fashion. This form of

network topology is referred to as an Independent Basic Service Set (IBSS) or an Ad-hoc

network. In an IBSS, the mobile stations communicate directly with each other. Every










mobile station may not be able to communicate with every other station due to the range

limitations. There are no relay functions in an IBSS therefore all stations need to be within

range of each other and communicate directly.

Infrastructure Basic Service Set(BSS)

An Infrastructure Basic Service Set is a BSS with a component called an Access

Point (AP). The access point provides a local relay function for the BSS. All stations in the

BSS communicate with the access point and no longer communicate directly. All frames

are relayed between stations by the access point. This local relay function effectively

doubles the range of the IBSS.

Extended Service Set (ESS)

An extended service set is a set of infrastructure BSS's, where the access points

communicate among themselves to forward traffic from one BSS to another to facilitate

movement of stations between BSSs.

Wireless LAN Handoff Management

Wireless LAN Handoff Management Frames


The 802.11 standard defines various frame types that stations (NICs and APs) use

for communications, as well as managing and controlling the wireless link. Every frame

has a control field that depicts the 802.11 protocol version, frame type, and various

indicators for WEP is on/off, power management is on/off, etc. In addition all frames

contain MAC addresses of the source and destination station, a frame sequence number,

frame body and frame check sequence (for error detection). 802.11 control frames assist in










the delivery of data frames between stations. Data frames carry protocols and data from

higher layers within the frame body such as RTS, CTS, ACK. Management frames enable

stations to establish and maintain communications. Here we only introduce the

management frames which relative directly to handoff management. [JimO 1]

Authentication frame: 802.11 authentication is a process whereby the access
point either accepts or rejects the identity of a radio NIC. The NIC begins the
process by sending an authentication frame containing its identity to the access
point. With open system authentication (the default), the radio NIC sends only
one authentication frame, and the access point responds with an authentication
frame as a response indicating acceptance (or rejection). With the optional shared
key authentication, the radio NIC sends an initial authentication frame, and the
access point responds with an authentication frame containing challenge text. The
radio NIC must send an encrypted version of the challenge text, using its wired
equivalent privacy (WEP) key, in an authentication frame back to the access point.
The access point ensures that the radio NIC has the correct WEP key (which is
the basis for authentication) by seeing whether the challenge text recovered after
decryption is the same that was sent previously. Based on the results of this
comparison, the access point replies to the radio NIC with an authentication
frame signifying the result of authentication.
Deauthentication frame: A station sends a deauthentication frame to another
station if it wishes to terminate secure communications.
Association request frame: 802.11 association enables the access point to
allocate resources for and synchronize with a radio NIC. A NIC begins the
association process by sending an association request to an access point. This
frame carries information about the NIC (e.g., supported data rates) and the SSID
of the network it wishes to associate with. After receiving the association request,
the access point considers associating with the NIC, and (if accepted) reserves
memory space and establishes an association ID for the NIC.
Association response frame: An access point sends an association response
frame containing an acceptance or rejection notice to the radio NIC requesting
association. If the access point accepts the radio NIC, the frame includes
information regarding the association, such as association ID and supported data
rates. If the outcome of the association is positive, the radio NIC can utilize the
access point to communicate with other NICs on the network and systems on the
distribution (i.e., Ethernet) side of the access point.
Reassociation request frame: If a radio NIC roams away from the currently
associated access point and finds another access point having a stronger beacon









signal, the radio NIC will send a reassociation frame to the new access point. The
new access point then coordinates the forwarding of data frames that may still be
in the buffer of the previous access point waiting for transmission to the radio
NIC.
Reassociation response frame: An access point sends a reassociation response
frame containing an acceptance or rejection notice to the radio NIC requesting
reassociation. Similar to the association process, the frame includes information
regarding the association, such as association ID and supported data rates.
Disassociation frame: A station sends a disassociation frame to another station if
it wishes to terminate the association. For example, a radio NIC that is shut down
gracefully can send a disassociation frame to alert the access point that the NIC is
powering off. The access point can then relinquish memory allocations and
remove the radio NIC from the association table.
Beacon frame: The access point periodically sends a beacon frame to announce
its presence and relay information, such as timestamp, SSID, and other
parameters regarding the access point to radio NICs that are within range. Radio
NICs continually scan all 802.11 radio channels and listen to beacons as the basis
for choosing which access point is best to associate with.
Probe request frame: A station sends a probe request frame when it needs to
obtain information from another station. For example, a radio NIC would send a
probe request to determine which access points are within range.
Probe response frame: A station will respond with a probe response frame,
containing capability information, supported data rates, etc., when after it receives
a probe request frame.

IEEE 802.11 Handoff Procedure

An IEEE 802.11 Handoff occurs when a STA moves out of the range of one AP, and

enters another BSS. During the handoff, management frames are exchanged between the

station (STA) and the AP. Also the APs involved may exchange certain context

information (credentials) related to that STA via Inter Access Point Protocol(IAPP).

The handoff procedure can be divided to two steps[Mish03] [Shin04], discovery and

reauthentication.

Discovery: this step involves the handoff initiation phase and the scanning phase.

When the STA is moving away from the current AP, the signal strength and the










signal-to-noise ratio of the signal may degrade and initiate the scanning phase. Scanning is

to try to find a new available AP to associate with. There are two can of scanning mode:

passive or active. In passive scanning mode, the STA listens to each channel of the

wireless medium for beacon frames broadcasted by AP. Using the information obtained

from beacon frames the STA can elect to join an AP. In active scanning, apart from

listening to the beacon frames, the STA send probe request frames on each channel and

listens to probe responses from the APs. The basic procedure of the active scanning

includes the following steps [80211], as summarize by[Shin04] :

Using the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA)
channel access mechanism gain control of wireless medium.
broadcast a probe request frame.
Start a probe timer.
Listen to the channel for probe responses.
If no response has been received by minChannelTime, scan next channel.
If one or more responses are received by minChannelTime, stop accepting probe
responses at maxChannelTime and process all received responses.
Repeat the above steps to scan next channel. After all channels have been scanned,
all information received from probe responses are processed so that the STA can
select one AP to associate.

Reauthentication: The reauthentication process involves authentication and

reassociation to the new AP. The STA sends a authentication request to the new AP,

informing the AP of its identity. The new AP sends back an authentication response,

indicating acceptance or rejection. After successful authentication, the STA sends a

reassociation request to the new AP and waits for a reassociation response containing an

acceptance or rejection notice.

Figure 2-6, taken from [Shin04], shows the IEEE 802.11 handoff process.










STA
A
V
Probe request (broadcast)

Probe responses






Authentication st New A
B
L
Probe delay E

Probe request (broadcast) A



Authentication request New AP

Authentication delay Authentication response

Reassociation request
Association delay Reassociation response



Figure 2-6 802.11 wireless LAN handoff procedure


Techniques to Reduce IEEE 802.11 Handoff Time

A lot of researches have been done to analyze and reduce the handoff latency of

wireless LAN. [Mish03] conducts experiments to accurately measure the handoff latency

in an in-building wireless network. The measurements are done on two co-existing

wireless networks, and using three wireless NICs from different vendors. It analyzes the

handoff latencies by breaking down the whole process into discovery and reauthentication

phases to assess the contribution of each phase to the handoff latency. The experiment

results show that the discovery phase (scanning time) is the most time consuming part of

the handoff process, taking over 90% of the total handoff latency. The variations in the










probe-wait time account for the large variations in the overall handoff latency. The

reauthentication phase contributes only a few milliseconds.

[Mish04] use of an efficient data structure, neighbor graphs, which dynamically

captures the mobility topology of a wireless network as a means for pre-positioning the

station's context ensuring that the station's context always remains one hop ahead. This

caching mechanism is based on the IAPP protocol in order to exchange the client context

information between neighboring APs. The cache in the AP is built using the information

contained in an IAPP Move-Notify message or in the reassociation request sent to the AP

by the client. By exchanging the client context information with the old AP, the new AP

does not require the client to send its context information in order to reassociate, hence

reducing the reassociation delay.Its experimental and simulation results show that the use

of neighbor graphs cache reduces the layer 2 handoff latency due to reassociation by an

order of magnitude from 15.37ms to 1.69ms.

[Kim04] propose a selective scanning algorithm which depends on the use of

neighbor graphs. This approach requires changes in the network infrastructure and use of

IAPP. The scanning delay is defined as the duration taken from the first Probe Request

message to the last Probe Response message. This definition does not take into

consideration the time needed by the client to process the received probe responses.

[Shin04] also propose a selective scanning algorithm and a caching mechanism. This

caching data structure is maintained at the client side and no changes are required in the

existing network infrastructure or the IEEE 802.11 standard. All the required changes are










done on the client side wireless card driver. And [Shin04] considers the time required for

processing the probe responses received by the client. This processing time represents a

significant part of the scanning delay especially when the number of probe responses

received increased significantly.

Sangheon Pack and Yanghee Choi in [Par02] and [Park02] proposed a fast handoff

scheme using the pre-authentication method based on IEEE 802. lx model. In their

proposal, when a mobile host handoff, it performs authentication procedures not only for

the current AP but for a set of multiple APs. Multiple APs are selected using a Frequent

Handoff Region (FHR) selection algorithm considering users' mobility patterns and their

service classes. The FHR is a set of adjacent APs. It is determined by the APs' locations

and users' movement patterns. Namely, the FHR consists of APs with which mobile hosts

are likely to communicate to in the near future. Since a mobile host is authenticated for

FHR in advance, the handoff latency due to the reauthentication can be minimized.

Low Latency Handoff Mechanisms for MIP over 802.11 Network.

The HMIP, Cellular IP (CIP)[Cam99] and (HAWAII) [Ramj02] protocol we talked

in Section 2 of this chapter are handoff management protocols without considering

underlying layers. This clean separation between Layer 2 and Layer 3 protocol stack

allows those protocols to run on most layer technologies. The disadvantage of this clean

separation is lower performance. In MIP over wireless LAN network, the MN may only

keep connectivity with one AP, hereby one FA. So the MN can only start the registration

process after completion of the L2 handoff [Malk02] proposed two mobility protocols,










pre-registration and post-registration, that aim at low latency Layer 3 handoff based on

Layer 2 information or called Layer2 trigger. In pre-registration, MN may communicate

with the new FA while still being connected with the old FA. In post-registration, the data

can be delivered to the MN at the new FA before the registration process has completed.

Here we briefly depict these two method summarize by [Blon04].

L2 Triggers

A L2 trigger is a signal related to the L2 handoff process. There are there kind of L2

triggers mentioned in [Malk02]: anticipation trigger- an early notice of an upcoming

change in the L2 point of attachment of the MN. Line Down trigger (L2-LD)- indicates

that the L2 link between the MN and the old AP is lost. Line Up trigger (L2-LU)- indicates

that the L2 link between the MN and the old AP is established. A trigger initiated at the old

FA is referred as a source trigger and a trigger initiated at the new FA is referred as a target

trigger.

Pre-Registration

Pre-Registration allows the old FA and new FA to utilize information from layer 2

(the L2 "trigger") to set up a kind of "pre-registration" prior to receiving a formal

Registration Request from the Mobile Node.. The network assists the MN in performing an

L3 handoff before the L2 handoff is completed. Both the MN (mobile-initiated) and the

FAs (network-initiated) can initiate a handoff










A mobile-initiated handoff occurs when the L2 anticipation trigger is received at the

MN informing it that it will shortly move to the nFA. The L2 trigger contains information

such as the nFA's IP address identifier.

A network-initiated handoff can be initiated by a source trigger at the oFA

(source-initiated handoff) or by a target trigger at the nFA (target-initiated handoff). A

source-initiated handoff is initiated at the oFA by a received L2 trigger that informs the

oFA of a MN's upcoming movement from oFA to nFA. A target-initiated handoff is

initiated at the nFA by a received L2 trigger that informs the nFA of a MN's upcoming

movement from oFA to nFA.

Post-Registration

The Post-Registration handoff method is based on a network-initiated model of a

handoff. The Post-Registration occurs after the L2 handoff has been completed. This

approach uses a bi-directional edge tunnel (BET) to perform a low latency change in the

L2 point of attachment of the MN without requiring any involvement of it.

A handoff occurs when the MN moves from the oFA, where the MN performed a

Mobile IP registration, to the nFA. The MN delays its registration with the nFA, while

maintaining connectivity using the BET between the oFA and nFA. There are two

different Post Registration handoff schemes, Source and Target Trigger Post Registration,

depends on what kind of L2 is using. An FA becomes aware that a handoff is about to

occur at L2 through the use of an L2 trigger. Two types of triggers can be received: a

source trigger at the oFA and a target trigger at the nFA.










The FA receiving the trigger sends a Handoff Request (HRqst) to the other FA. The

FA receiving the HRqst sends a Handoff Reply (HRply) to the first FA. This establishes a

BET. The L2-LD (Link Down) trigger at the oFA and at the MN signals that the MN is not

connected anymore with the oFA. When the oFA receives the L2-LD trigger, it begins

forwarding the MN packets through the forwarding tunnel to the nFA. When the nFA

receives the L2-LU (Link Up) trigger, it begins delivering packets tunneled from the oFA

to the MN and forwards packets from the MN. When the MN receives the L2-LU, it

decides to initiate the Mobile IP Registration process with the nFA by soliciting an Agent

Advertisement or continues using the BET. Once the Registration process is complete

(through the exchange of a Regional Registration Request and a Regional Registration

Reply with the GFA), the nFA replaces the role of oFA.

Location Tracking

The ability to determine a user's location in an existing 802.11 wireless network can

provide many useful services for wireless users. Such services include: location sensitive

content delivery, such as being able to send documents to a vicinal printer; creation of

real-time roadmap, asset tracking (locating a valuable device), etc. Some location

mechanisms use additional devices such as GPS, some not.

The Global Positioning System (GPS) is a worldwide radio-navigation system

consists of a constellation of 24 satellites and their ground stations. GPS uses these

"man-made stars" as reference points to calculate positions accurate to a matter of meters.

In fact, with advanced forms of GPS the accuracy can be better than a centimeter[Trim04].










A GPS device, through triangulation of multiple signals received and determination of

propagation (how long it took the signal to go from the satellite to the GPS device), is able

to accurately determine a user's location to within a meter. The problem with GPS is that

the device must have a clear line of sight between itself and the satellite. This means the

technology is unusable in heavily forested areas, urban environments with tall buildings

and indoor environments.

Some works has been done to use the popular 802.11 network infrastructure to

determine the user location without using any extra hardware. Generally, suck kind of

system needs to measure the signal quantity as a function of distance and one or more

reference point such as the APs in the wireless LAN. The signal strength decays

logarithmically with distance in an open space. But in indoors, the wireless channel is very

noisy and the radio frequency (RF) signal can suffer from reflection, diffraction, and

multipath effect [Yous03], which makes the signal strength a complex function of

distance. To overcome this problem, WLAN location determination systems may

constructs radio-maps during offline by sampling the signal at selected locations in the

area of interest and tabulate the complex function. When the system need to determine the

location, the vector of samples received from each access point is compared to the

radio-map and the "nearest" match is returned as the estimated user's location.

[Yous04] divided the radio map-based techniques into two broad categories:

deterministic techniques and probabilistic techniques. Deterministic techniques, such as

RADAR system in [Bahl00] and Location Information Privacy Model in [Smai01],










represent the signal strength of an access point at a location by a scalar value, for example,

the mean value, to estimate the user location. Probabilistic techniques measure the signal

quantity as a function of distance from the APs and store information them into a radio

map and use probabilistic techniques to estimate users location. [CastOl] [Ladd02]

[Roos02] [You04] [You03] are all using probabilistic techniques.

RADAR, An In-Building RF-based User Location and Tracking System, was

developed in Microsoft Research. In RADAR, the signal strength is measured when

transmitting beacon packet between the mobile host and AP. They take sample of radio

signals and build up a radio map for the area interested during offline phase. RADAR uses

3 APs as reference point of its location, which is called triangulation. During location

phase, it match the real time signal strength with the radio map and determines the user's

location. The match is done by linear search.

Horus system from the University of Maryland is an RF-based location

determination system [You04] [You03]. It is implemented in the context of 802.11

wireless LANs. The system uses the stored radio map to find the location that has the

maximum probability given the received signal strength vector. In [Yous04], they also

proved formally that probabilistic techniques give more accuracy than deterministic

techniques.

Other Related Work

IEEE802.11 standard was originally devised to replicate in a wireless fashion the

structures of the wired LANs. Only recently the idea of utilizing IEEE802.11 technology










for high mobility scenarios has been taken into account and the range of WLAN based

applications has been enriched. In [Mani03], Pierpaolo Bergamo from UCLA and Don

Whiteman from NASA, experimentally studied the behavior of an IEEE802.11 wireless

network when the nodes are characterized by mobility up to the speed of 240 km/h. The

authors studied the survivability and the performance of a connection under various

aggressive mobility conditions. These studies may be adapted for data telemetry from

mobile airborne nodes to fixed networks or between airborne nodes. In [Sing02], authors

assessed the performance of WLANs in different vehicular traffic and mobility scenarios.

The network throughput and the quality of the wireless communication channel,

measured on IEEE 802.1 lb compliant equipment, are observed to degrade with

increasingly stressful communication scenarios. [Amic02] presents a project using a

WiFi-like network for military telemetry applications. For military telemetry, aircraft

and/or cars equipped with IEEE802.11 enabled devices will communicate with a fixed

backbone infrastructure. The authors of [Amic] focused on aspects like frequency

selection and network security. In [Thor], authors developed their own frequency

hopping transceiver working at 900 MHz for telemetry purposes. In [Bamb], authors

assured through analytical considerations that these kinds of transceivers can guarantee

an impressive tolerance to rapid moving environments.

A review on recent research on MIP shows a great amount of efforts contributed to

reducing MIP handoff latency. Malki [Malk02] proposed two mobility protocols, pre-

and post-registration, using L2 trigger. In pre- registration, MN may communicate with

both oFA and nFA. In post-registration, data are cached in nFA before the registration is

completed. Fast-handover [Kood02] for Mobile IPv6 network combines the about two

methods. But they all depend on L2 information. S-MIP[Hsie03], uses MN location and






48


movement patterns to 'instruct' the MN when and how handoff should be carried out.

[Wijn04] also uses MN's movement model to predict handoff. But all these efforts didn't

consider the speed factor of MN, which may cause problems when the MN moving

rapidly.















CHAPTER 3
PERFORMANCE OF MIP OVER WLAN AT DIFFERENT SPEEDS

MIP over Wireless LAN Handoff Procedure

MIP over wireless LAN provides more flexibility and mobility to mobile IP

network. Unlike a traditional wired mobile IP network, which requires a wire to connect a

computer to the network, wireless LAN users can access IP network from nearly anywhere

without losing connectivity.

Mobile IP is designed independently for all

Layer 2 technologies, so it can run on any layer 2
GFA
infrastructures. But such kind of independency

FA1 FA 2 also costs more overhead. Figure 3-1 is the handoff

procedure of MIP over two wireless LAN. When a

S--1 MN moves from wireless LAN1 to wireless

Figure 3-1 MIP handoff LAN2, it performs a layer 802.1 lb handoff


between Access Point 1 (AP1) and Access Point 2(AP2). After the layer handoff, the MN

begins a layer3 handoff, which is MIP handoff. Suppose there is a communication, for

example a TCP stream, between MN and CN. After the layer and layer3 handoff, it will

require a significant time interval to recover the communication. This time internal is

called layer4 handoff latency, which is also a part of the whole handoff cost. Equation 1

gives the life-cycle of MIP over wireless LAN handoff procedure:











thandoff= tL2handoff + tL3handoff + tL4handoff (Equation 1)

Where thandoff is the total handoff latency of MIP over wireless LAN, tL2handoff,

tL3handoff, tL4handoff are the handoff cost of Layer2, Layer3 and Layer4 separately.

In the following section, we introduce an emulation testbed, RAMON, which is used

to evaluation the performance of MIP over WLAN and to analyze the handoff latency of

the MIP handoff procedure.

RAMON Testbed

In order to evaluate the performance of MIP over WLAN, we build up a MIP

emulator RAMON[Hern02]. RAMON is a Rapid Mobile Network emulator. It's a testbed

combining software and hardware components to produce a realistic experimentation

environment that can test the behavior and performance of actual mobile systems. The

testbed provides the wireless and wired infrastructure to allow experimental testing of

wireless and wired mobile network protocols. Figure 3-2 is the architecture of RAMON.

RAMON consists of a Pentium II pc as Emulator, a circuit board as Controller, three

JFW Industries Attenuators with Antennas, three Cisco 350 Access Points, three FAs, a

HA and one or more MNs. All the FAs, HA and MN, which are the major entities of MIP,

are running Linux kernel 2.4.20 and are installed with HUT dynamic MIP implementation

version 0.8.1. The Attenuators are program controllable devices. The Emulator

manipulates the Attenuators by the Controller to control the signal strength coming out

from the Access Points. By increasing or decreasing the signal strength of one AP, we can

emulate the MN moving towards to or away from the AP. By varying the increasing or










decreasing speed of the signal strength, we can emulate the speed change of the MN. The

emulation program running on the emulator can dynamically change the IP addresses for

each AP and FA so that every physical AP(and FA) in Figure. 3-2 can emulator multiple

logical AP(and FA) in Figure 3-3.


Figure 3-1 RAMON testbed architecture
Hardware Architecture

The hardware architecture of RAMON includes

*two PCs-one is emulator, one is home agent
o The emulator has four Ethernet cards. IP addresses are
EthO: 192.168.1.2 mask 255.255.255.0
Ethl: 192.168.2.2 mask 255.255.255.0
Eth2: 192.168.3.2 mask 255.255.255.0
Eth3: 192.168.4.2 mask 255.255.255.0









o The HA has two Ethernet cards. IP address are
EthO: 10.3.3.14 mask 255.255.255.0
Ethl: 192.168.4.2 mask 255.255.255.0
3 IBM ThinkPad laptops-as 3 foreign agents
o FA1 : eth0: 192.168.1.1 mask 255.255.255.0
o FA2 : eth0: 192.168.2.1 mask 255.255.255.0
o FA3 : eth0: 192.168.3.1 mask 255.255.255.0
3 CISCO AIRONET 350 Aps, IP addresses are
o API: 192.168.1.3
o AP2: 192.168.2.3
o AP3: 192.168.3.3
o The backup configuration files of these 3 APs are saved in the
emulator.
3 Omnidirectional 3dbi Cushcraft Antennas
one control board-control the attenuator to emulate the signal fading
3 JFW Industries 50p-1230 Attenuators
one Laptop-- as mobile host
o MN eth0: 192.168.4.5
Software Architecture

Emulator:
o Linux Kernel 2.4.7-10.
o Modules IPIP
o Script emulator to create Virtual interfaces and routing table
o Emulation object file to run the emulation
HA:
o Dynamics HUT mobile IP home agent package: dynhad.
o NAT
o Modules IPIP
FA:
o Dynamics HUT mobile IP foreign agent package: dynfad.
o Modules IPIP
o Script FA1, FA2, FA3. simulate the action of foreign agents.
o DynX. 1 dynfad.conf configure files.
MN:
o Dynamics HUT mobile IP foreign agent package: dynmnd.
o Dynmnconfl dynmnd.conf configure file.
o Tcpdump to capture data
o Ethereal tool for analysis.










Performance Evaluation

Emulation Scenario and Result


Using RAMON, we emulate HUT dynamic MIP in the following scenario in Figure

3-3:


interest






FA FA2 FA3 FA4 FA5 FA6 FA7 FA8











Figure 3-2 Dynamic MIP sample scenario

In this scenario, a rapid moving MN will travel trough 8 APs. Each AP is wired to a

FA. The distance between every two APs is d= 250m, 500m or 1000m. The moving speed

of MN is V, varying from 10m/s to 80m/s. In our experiments, we used ftp to transfer a

large file from the CN to the MN. During the ftp transfer, we tracked down TCP sequence

numbers by using the tool tcpdump. We analyze the tcpdump data by using ethereal. Here

we only give the experiment results for d = 500m and 1000m, v = 10m/s to 80m/s. Figure

3-4 and figure 3-5 are the time-sequence graph and throughput graph at speed 20m/s and

AP distance 1000m. Figure 3-6 and 3-7 shows the time-sequence graph and throughput









54





graph at speed 80m/s and AP distance 1000m. Figure 3-8 to figure 3-11 are those graphs at



speed 10m/s, AP distance 500m and speed 40m/s, AP distance 500m.




Sequence
number[B] Time/Sequence Graph
80000000 -- -


50 100 150 200 250 300 350 400



Figure 3-3 Time-sequence graph at speed 20m/s and AP distance 1000m


Tih-oghput Grah


. . .. .... ..rn ss T g.s ~ B= w i-s s a .... .. .. ...... .. ...~"

-. "- =. .--= "

S:- *-


i i i' 9

1$


!*L *- l. -



ig


, S .
LI i.


*1, ~1 j

Ir~~ i;f


50 3 10 150 200 250 300 350 400 450



Figure 3-4 Throughput graph at speed 20m/s and AP distance 1000m


innnnnnn-


















Tme/SequenceGraph


I '" 1'' 1 I I 1 I" I 1 ''" 1 ''" '1''" I '"
5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 s0 85 90 95 100 105 110




Figure 3-5 Time-sequence graph at speed 80m/s and AP distance 1000m.


S .. .. 1




ii I i V* vI.
.. ~ M


Figure 3-6 Throughput graph at speed 80m/s and AP distance 1000m.


6000000-


5000000- "


4000000


3000000


2000000- *


1000000-


0nnnn00


700000 -


0600000


00000


5 10 15 20 25 30 35


40 45 50 55 60 65 70 75 80 85


90 95 100 105 110
















A.^


I I2II I I I I I I I


Figure 3-7 Time-sequence graph at speed 10m/s and AP distance 500m.


Throughput Graph


Figure 3-8 Throughput graph at speed 10m/s and AP distance 500m


_-







loa -
4XOn -


a -


1XOxB-


ItmxX)--


n 1,,


50 100


200 250


, '', I. ka;~ ... POO....RI .









57




Seluence
ritibelBI iere/SeqerceGraph
1190000D






/2 *
19-






















5 10 15 20 2 3 35 o d 5 0 5- 60 65 70 75 W 85 5 19 10 Io
boom -















300000-
5 I0 15 a0 fi 30 35 do 45 50 55 Wo 65 70 75 W0 85 so 95 1 0 1 10



Figure 3-9 Time-sequence graph at speed 40m/s and AP distance 500m.











..... .... .
0000 -


r .... .. ... -. -". --
.... .... : ;.



I *










Figure 3-10 Throughput graph at speed 40m/s and AP distance 500m.


Experimental Result Analysis



To compare the performance of MIP/ WLAN at different speeds and different AP



distances, we list the experiment data in table 3-1. In the table, the bytes transferred are the



total bytes transferred from when the MN enters the first cell to when it moves out of the



last cell. The average throughput is calculated by dividing bytes transferred by travel time.










The total handoff time is the summary of the handoff latency of 7 times handoffs. The

effective time is the time for effectively transferring data, which equals to the travel time

minus the total handoff time.

Table 3-1 shows the average throughput drops when the MN's speed goes up. At the

same speed of 20m/s, the average throughputs are 196.97kB/s for d=1000m and

167.172kB/s for d=500m. At the speed of 40m/s, the average throughputs are 167.512kB/s

for d=1000m and 93.877kB/s for d=500m. The table shows that if we double the speed and

at the same time double the AP distance, the average throughput shows no suggestive

difference. For example, at the speed of 40m/s and AP distance 1000m the average

throughputs is 167.512kB/s. At the speed of 20m/s and AP distance500m the average

throughputs is 167.172kB/s.

Table 3-1 Average Throughput at Different Speeds and AP Distances.

Speed AP Bytes Travel Average Total Effective PMaxavg Handoff
(m/s) distance transferred Ti throughput handoff Etimes (kB/s) Rate
(m) (kB) Tme (s) (kB/s) times) te(s) (FAs/s)

20 1000 78000 396 196.970 58 338 232.5 0.02

40 1000 33000 197 167.512 57 140 234.31 0.04

60 1000 16700 130.5 127.969 56 74.5 234.07 0.06

80 1000 9200 98.5 94.359 57 41.5 232.673 0.08

10 500 78500 397 197.733 58 339 233.01 0.02

20 500 33100 198 167.172 56 142 234.4 0.04

30 500 16600 129 128.682 56 73 232.86 0.06

40 500 9200 98 93.877 58 40 232.8 0.08











The analysis of table 1 also shows: (1). The total handofftime doesn't change with


speed. (2). Effective-time/total-travel-time ratio drops when the speed goes up. This is the


reason why higher speed has lower throughput.


Figure 3-12, the average throughput vs. speed graph, gives a more obvious view of


this conclusion.



200- 200

D 180- 180-

160- 160-

140- 140-

120- 120

100- \100-

80 80 -
0 20 40 60 80 0 10 20 30 40
Speed v(m/s) d= 1000m Speed v (m/s) d = 500m

Figure 3-11 Average throughputs vs speeds.

In order to figure out the relationship between the performance of MIP over wireless


LAN and the moving speed, we measured the throughputs of MIP over wireless LAN at


different moving speeds and AP distances when there are no handoffs. We call this


throughput, PMaxavg, the maximum average throughput without handoff Here we only give


the time-sequence graph at AP distance 1000m with speed 20m/s(left) and 80m/s(right).


From figure 3-13, we get PMaxavg = 93000kB / 400s = 232.5 kB/s. From the right graph of


figure 3-14, we get PMaxavg = 23500kB / 101s = 232.673 kB/s. The PMaxavg at different


moving speeds and AP distances are listed in table 1.











































Figure 3-12 Time-sequence graph at AP distance 1000m with speed 20m/s without


handoff

Sequence
number[B] Tlme/SequenceGraph
25000000



20000000-



15000000



-nnnnn-


5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 00 95 90 95 100 105 110



Figure 3-13 Time-sequence graph at AP distance 1000m with speed 80m/s without


handoff


Let Pavg Average throughput



Pmaxavg Average throughput without handoff



Travel Total travel time


400










Teffective Total effective time for ftp transmission

Thandoff Total handoff time while traveling

Khandoff- The number of handoffs while traveling

thandoff Average handoff time among 7 times of handoff

Then, Pavg = (Pmaxavg / Ttravel ) x Teffetive

= Pmaxavg (Ttravel Thandoff )/ Ttravel

= Pmaxavg (1 Thandoff/ Ttravel)

= Pmaxavg( 1 Khandoff x thandoff / Ttravle)

= Pmaxavg( 1 (Khandoff/ Ttravle ) x thandoff ))

Since thandoff doesn't change, The change of Pavg is caused by Khandoff/Ttravel ratio.

We define MN handoff rate as rh = v/d, which is the ratio of the MN's speed and the

cell size(AP distance). It means that how many APs or FAs the MN hands over in one

second. rh is also equal to Khandoff/ Ttravel.

The relationship between the performance of MIP/WLAN and the moving speed is

presented in Equation 2:



Pavg = Pmaxavg( 1 rh x thandoff )) Equation 2



Where Pavg is the average throughput for the MN; PMaxavg is the average throughput

without handoff. thandoff is the average handoff time for each handoff procedure.











Since thandoff doesn't change, the change of Pavg is caused by handoff rate rh. At

handoff rate 0.02 FAs/s, the average throughput is 197.35 kB/s. When the handoff rate


goes up to 0.08 FAs/s, the average throughput drops to 94.118 kB/s. The graphs in Figure


3-12 can be combined into graph in Figure 3-15.

Kbytes/sec

200-

180

160

140

120

100

80 -
0 0.02 0.04 0.06 0.08
Handoff rate FA/s

Figure 3-14 Average throughput vs handoff rate



This chapter shows that the performance of MIP over WLAN is depends on the


MN's handoff rate. In Chapter 5, we will propose an idea of how to make use of this


throughput/handoff-rate relationship to improve the performance of MIP over wireless


LAN in rapid moving environment. In the following chapter, we will take a deep view of


the handoff latency by breaking down the handoff procedure of MIP over wireless LAN.














CHAPTER 4
QUANTITATIVE ANALYSIS OF THE MIP OVER WIRELESS LAN HANDOFF
LATENCY

Equation 1 in Chapter 3 shows that the life-cycle of MIP over wireless LAN handoff

is the summary of Layer2, Layer3 and Layer4 handoff latency. In the following sections,

we analyze the handoff characters of each layer and provide a quantitative analysis of the

MIP over wireless LAN handoff latency.

Layer 2 Handoff Latency

In the case of IEEE 802.1 lb WLAN, Layer2 handoff is the change of APs. It causes

an interruption of data frame transmission. Buffering and routing update make the handoff

time for uplink and downlink traffic different. Some researches have been done to even

this difference[El-Ho00][Ren99]. In our experiments, we only concern the downlink

handoff time. In [Vela04], Hector Velayos splitting the Layer2 handoff time into three

sequential phases: detection, search and execution. In our experiment, we also split it into

three parts and name them as: movement detection, AP searching and reassociation.

The Layer2 handoff involves three participating entities, the station(here is the MN),

an old AP(oAP) and a new AP(nAP). The oAP is the access point which the station had

layer connectivity prior to the handoff, while the nAP is the access point to which the

station gets layer connectivity after the handoff The handoff process among 2 APs also

includes information exchanges. This information typically consists of the station's










credentials and accounting information. The message exchange between APs can be done

by Inter Access Point Prototcol(IAPP)[1 1F03] or via a proprietary protocol. The following

is a detail analysis of three phases of Layer 2 handoff.

Layer2 Movement Detection Phase

In oAP's coverage, the station keeps frame transmission. There are three reasons for

frames lose: collision, radio signal fading, or oAP is out of range. The station first assumes

the lost frame is cause by collision. In 802.1 lb standard, collision is handled by Carrier

Sense Multiple Access with Collision Avoidance (CSMA/CA) protocol. CSMA/CA is a

basic protocol used to avoid signal collision and canceling. It works by requesting

authorization to transmit for a specific amount of time prior to sending information. When

collision happens, the sending device broadcasts a Request To Send (RTS) frame with

information on the length of its signal. If the receiving device permits it at that moment, it

broadcasts a Clear To Send (CTS) frame. Once the CTS is transmitted, the sending

machine transmits its information. Any other sending device in the area that "hears" the

CTS realize another device will be transmitting and allow that signal to go out

uncontested. If the station tried to retransmit several times and still unsuccessful, then it

assumes signal fading. This time the station sends out probe requests to probe the link.

After several probe requests and without any response, the station assumes oFA is out of

range and begin AP searching phase. In figure 10, from TCP point of view, when MN

receives the last TCP package, it responses with TCP ACKnowledgement. After several










unsuccessful transmission of TCP ACK, the MN assumes the oAP is out of range and

starts a new AP searching phase.

Layer2 AP Searching Phase

After the station assumes oAP is out of range, it tries to find new potential APs to

associate to. This is done by 802.1 lb MAC layer function: SCAN. There are two methods

of scanning, active and passive. In passive scanning, the station listen to each channel for

beacon frames(broadcasted periodically by APs every 10ms). The station takes note of the

corresponding signal strengths while scanning. The beacons contain information about the

AP, including service set identifier (SSID), supported data rates, etc. The station can use

this information along with the signal strength to compare APs and decide upon which one

to chose. In active scanning, the station broadcasts a probe request frame and waits for

response. The time to wait for responses depends on the channel status. If the channel is

idle during MinChannelTime, the station can receive prove response form the AP on that

channel. If there is any traffic during this time, the station will wait for MaxChannelTime

to allow the data in the channel be transmitted and wait for AP's response. After gathers

several response from APs in range, the station will compare and choose one to associate

to. Active scanning enables a station to receive immediate response from APs, without

waiting for beacon frames. However, it imposes additional overhead on the network. In

our experiment, only after got 3 probe responses from an AP, the station regards that AP is

stably in range. This is a default configuration of Orinoco Wireless card.










Layer2 Reassociation Phase

After choose one AP in phase 2, the station sends out a reassociation request to nAP.

If the nAP can get the credentials and other state information from oAP through IAPP,

there is no Authentication message exchange between the station and nAP. Or else, the

station will send out authentication request to the nAP and wait for response. After

authentication, nAP reassociates the station and sends reassociation response back.

The above three phases complete Layer2 handoff. The layer handoff latency can be

expressed in Equation 3.

tL2handoff = tL2detection + tL2seraching + tL2reassociation (Equation 3)


Where tL2detection tL2seraching and tL2reassociation are the time costs for Layer2 movement

detection, Layer2 AP searching and Layer2 reassociation. Figure 4-1 shows these three

phases in green arrows and are indexed as L2.

Layer 3 Handoff Latency

Only after the layer 2 link has been established, could the Layer 3 handoff starts,

because the MN can only communicate with the FA on the same link. The Layer 3 handoff

involves 2 phases, agent discovery and registration.

Agent Discovery

The well know agent discovery algorithms are Lazy Cell Switching(LCS) and Eager

Cell Switching(ECS)[Perk98].











*.... Data package
L3 HO signal
L2 HO signal


[L2 mnaement de-

L2 L2 AP searching

L2 reassociation


MIP agent discovt


MIP registton


L4 TCP retmnsmissio


cti


i *m

m isls 44m." p PP
nI14~l

nIIILl~I


I .on... .:ia .






........... ..... .,. ...... .
ie 41 Hanofocede wih mese exnge

Figure 4-1 Handoff procedure with message exchange


oEA unreachable uEA aeent
detection vJ discovery,
tRegistrationu
L handoff.,




oEA out Handoff aE New point of
of range' initiated discovered' attachment

established&


Figure 4-2 LCS handoff latency for MIP

The LCS method is a reactive handoff initiation strategy. In LCS the MN keeps


receiving Agent Advertisement messages from the oFA and refreshes the lifetime of the


CoA and stays in the original network until it moves and loses contact with oFA for the


duration of three advertisement(FA broadcast Agent Advertisement message every 1










second), which means oFA becomes unreachable. A handoff will be initiated if a nFA is

discovered after this moment. If the nFA hasn't been discovered before the oFA becomes

unreachable, the handoff latency will be much higher. An advantage of the LCS is to

reduce the frequency of handoff when the MN hangs around among several FA. As to MIP

over WLAN, because the MN can only keep physical link with one FA, the new agent

can't be discovered before the old agent becomes out of range. Figure 4-2 is the LCS

handoff latency plot for MIP.

ECS is a proactive initiation strategy. It dictates an immediate MIP handoff as soon

as a new agent is discovered. ECS is effective for the moving patterns that the MN rarely

change its moving direction. Figure 4-3 is the ECS handoff latency plot for MIP.


oEA unreachable uEA agent
detection r disc very&





New point of
dEA out uEA iscvered attachment
of range Handoff initiated established



Figure 4-3 ECS handoff latency for MIP

Registration

When a MN realizes that it is on a foreign network and has acquired a

care-of-address from the nFA, it needs to notify the HA so that the HA can forward IP










packets between MN and CN. This is done by registration. The registration process

involves four steps.

* The MN sends a registration request to nFA.
* The nFA relays this request to the GFA or HA.
* The HA either accepts or denies the request and sends a registration reply to nFA. If it
accepts the request, it will build a tunnel downward to nFA(if FA decapsulation is
used).
* The nFA relays this reply to the MN. If the registration reply is positive, it will build
a tunnel upward to HA or GFA.

If the MN is using a collocated care-of-address, it will register directly with the HA,

which is not the case in this paper.

The layer3 handoff latency can be splitted into Equation 4[Fiko01]. Figure 4-1

shows these two phases in red arrows and are indexed as L3.

tL3handoff = tmipagentdicovery + tmlpreglstratlon (Equation 4)

Layer 4 Handoff Latency


TCP is a connection-oriented, end-to-end reliable protocol designed to support error

recovery and flow control. Reliability is insured by a sliding-window acknowledgement

and retransmission mechanism. All data sent by TCP must be acknowledged by the

receiver. TCP maintains a variable-sized window of data that is unacknowledged for a

given time. If the window is full, no data will be sent until an acknowledgement is

received. TCP maintains a Retransmission Time Out (RTO) timer. If no ACK has been

received when the RTO timer expired, TCP assumes that the data has lost and retransmits

all of the data in the window. The retransmission follows the exponential back-off

algorithm. According to this algorithm TCP doubles the timeout value on unsuccessful










successive retransmissions[Hsie03]. In our case, during the Layer2 and layer3 handoff, the

TCP doubles the retransmission timeout value several times. So even after the layer and

layer3 handoff is over, TCP still have to wait for RTO to timeout to recover the

retransmission. In figure 4-1, the dash blue arrows depict the TCP retransmission interval

has been doubled. This latency is cost by TCP exponential back-off algorithm. So we call

it TCP back-off delay ttcp-back-off.

We define tL4hadoff= ttcp-back-off (Equation 5)

Quantitative Analysis of the Handoff Latency


According Equation 1, 2, 3 and 4, the handoff latency distribution for MIP over

WLAN is show in Equation 6.

thandoff tL2detection + tL2seraching + tL2reassociation + tmipagentdicovery + tmipregistration + ttcp-back-off (

Equation 6)

We used RAMON introduced in Section 3 to emulate the same scenario as in Section

3. We did 20 times experiments to get the average handoff latency. The experimental result

of the handoff latencies of MIP over wireless LANis listed in table 4-1. Table 4-1 gives 20

times of experiment data. Each row is one experiment. Each column is the time latency for

that handoff phase. The data in the last column are the total handoff latencies for every

experiment. The number in the bottom right cell is the average handoff latency.













Table 4-1 Handoff latency distribution of MIP over WLAN
tency L2 L2AP L2 MIP MIP TCP Handoff
movement searching reassociati agent registration backoff latency
xp t detection on discover

1 1.033 0.061 0.005 2.996 0.073 5.058 9.226
2 1.064 0.044 0.009 1.945 0.042 6.01 9.511
3 1.133 0.063 0.006 3.023 0.052 5.345 9.622
4 1.032 0.100 0.008 2.563 0.050 5.323 9.076
5 1.044 0.065 0.003 2.756 0.052 5.125 9.045
6 1.131 0.057 0.004 2.578 0.043 5.004 8.817
7 1.009 0.056 0.010 2.436 0.060 5.625 9.196
8 1.120 0.060 0.006 3.001 0.704 5.002 9.893
9 1.023 0.059 0.026 2.213 0.054 4.998 8.373
10 1.039 0.076 0.005 3.008 0.053 5.006 9.187
11 1.100 0.045 0.030 2.770 0.041 5.728 9.714
12 1.013 0.049 0.010 2.545 0.042 4.768 8.427
13 1.021 0.051 0.009 3.001 0.065 5.202 8.896
14 1.006 0.043 0.017 2.600 0.046 5.312 9.024
15 1.104 0.069 0.006 2.598 0.047 4.544 8.368
16 1.003 0.064 0.013 2.674 0.062 4.806 8.622
17 1.110 0.054 0.010 2.783 0.054 5.705 9.716
18 1.100 0.064 0.006 3.012 0.057 5.602 9.841
19 1.302 0.056 0.009 2.349 0.070 5.71 9.496
20 1.098 0.044 0.004 2.404 0.062 5.172 8.784
Avg 1.074 0.059 0.010 2.660 0.086 5.253 9.142
Avg 1.143 2.746 5.253 9.142



We redraw figure 4-1 with handoff latency distribution in figure 4-4.








72



....**** Data package
L3 HO signal
L2 HO signal ....- :::
S.......... ...... .. .
7 : :: M *. .I *** .... .
1.074 L2mor ement detection t .... ..... ...
Probe ....... ..
L2delay 0.059 L2 AP seiching Probere .po: .e ......
1.14 ... .

0.010 L2reascwation

.. .............
2.660 MIP agent dismcery ..*
L3 delay I
2.746 ReijtaiRaiet __ ,
0.086 MIPregistration Rpi : yrat rniRy


L4delay 5.253 TCPretransion s

L .a..... j... ... .... -.. ..
Handoff delay : 9 142 :::...........c. d ....-...
111m mmmmmmmmm1 mmmmmm m 4,''I


Figure 4-4 Handoff procedure with handoff latency distribution
















CHAPTER 5
SPEED ADAPTIVE MIP AND ITS PERFORMANCE EVALUATION

From above analysis of handoff latency distribution, we can see the largest part is

TCP back-off latency ttcp-back-off. Because of TCP exponential back-off algorithm, if we

reduce the L2 and L3 latency, ttcp-back-off will be reduce exponentially. In this chapter, we

deal with L3 latency first. L2 and L4 latency will be considered in future works.

Traditional MIP over WLAN Handoff Procedure

The physical coverage of an IEEE 802.11-base wireless LAN is limited. To increase

the coverage of a wireless network, one can deploy multiple wireless LAN cells or

segments in an overlapped fashion where each cell is associated with an AP. AP serves as

a layer-2 bridge between the high-speed wired network and the wireless LAN. As MNs

move in and out of these overlapped cells, they can associate with the corresponding APs

according to beacon signal strengths. In IEEE 802.1 lb-based networks, the intelligence to

measure signal strength and switch among network segments is built into the wireless

LAN NIC(Network Interface Card), which exposes various status and control information

to the software device driver. To enable cellular-like networking structure, wireless LAN

NIC need to be configured to run in the access point mode, which is also known as the

infrastructure mode. Mobile IP provides MNs the ability to roam across wireless IP

subnets without loss of network-layer connectivity. Any network application executing on











a mobile host with mobile IP support can continue to run regardless of any change in the


mobile node's point of attachment. With mobile IP, mobile nodes do not need to


reconfigure their IP addresses while migrating from home subnets to foreign subnets. A


generic wired and wireless network topology with which mobile IP operates is shown in


Fig. 5-1[Srik04].


internet CN
H CN



13

FAt FA3
FA2
11 2

API 2 AP3 AP4

4 '
5 6 7 8



N



Figure 5-1 Traditional MIP Handoff Procedure

In this topology, there are one HA and several FAs running on the wired network.


The MN is communicating with CN through the wireless link with AP1. The FAs


periodically broadcast mobile IP advertisements on the wireless LANs(message 1, 2, 3 and


4 in figure 5-1). Because there no wireless link between the MN and AP2, AP3 and AP4,


the mobile IP advertisements messages 2, 3 and 4 can not be transferred to the MN. The


mobile IP advertisements messages 1 can reach the MN. Since MN already registered on


FA1, message 1 will be discarded by the MN. Whenever the MN migrates from one subnet










to another (foreign) subnet, it first needs to establish wireless connection with the

corresponding AP then starts receiving mobile IP advertisements from the corresponding

FA.

When an IEEE 802.1 lb-based wireless network is configured in infrastructure

mode, the MN is associated with the AP, which is API in figure 5-1, of the wireless LAN

cell in which it currently resides. Each AP periodically broadcast beacon frames every

10ms in passive scanning mode((message 5, 6, 7 and 8 in figure 5-1). The beacons contain

information about the AP, including service set identifier (SSID), supported data rates, etc.

The station can use this information along with the signal strength to compare APs and

decide upon which one to chose. If the MN chooses AP2, it initiates a link-layer handoff

from API to AP2. The MN sends a reassocation request message to AP2(message 9 in

figure 5-1). If the nAP can get the credentials and other state information of the MN from

API through IAPP, there is no Authentication message exchange between the MN and

AP2. Or else, AP2 will send out authentication request to the MN and wait for response.

After authentication, AP2 reassociates the MN and response with a reassociation response

message(message 10). In all known IEEE 802.1 lb cards, this link-layer handoff logic is

built into the firmware of the NIC, and does not generate any interrupts to notify the

higher-layer software. If the new wireless LAN cell belongs to the same IP subnet as the

old wireless LAN cell(like AP3 and AP4 belongs to the same subnet to FA3), then to the IP

layer and above on the mobile node there is no change in connectivity and the network

applications continue without any disruptions. However, if the new wireless LAN cell










belongs to a different IP subnet, then the MN can no longer communicate with CN until a

network layer handoff is completed. In this case, the MN would eventually receive an

advertisement from the FA2 through AP2(message 2 in figure 5-1). The mobile IP

software running on the MN intercepts these advertisements and sends a registration

request to FA2(message 11). This registration request is forwarded by FA2 to the

HA(message 12). After the authentication(not show in figure 5-1) a registration reply is

sent to the FA2(message 13) and is relayed to the MN(message 14). The mobile IP handoff

is over and an IP-over-IP tunnel is established between the HA and FA2. From this point

onwards, the HA, acts as a proxy for the MN, forwards all packets to FA2 over the tunnel.

FA2 de-encapsulates the packets and forwards them to the MN. Similarly, all packets that

the MN transmits to the CN are first received by FA2 and are tunneled over to the HA,

which further routes them to the CN. This process is known as bidirectional tunneling.

The above process of switching from FA1 to FA2 as the MN moves across adjacent

wireless cells is called mobile IP handoff. After the moves to a new wireless LAN cell but

before the associated mobile IP handoff completes, the mobile node is essentially cut off

from the wired network. For a rapid moving MN, this mobile IP handoff latency greatly

deduces the network performance. In extreme cases, the MN may even not be able to

accomplish mobile IP handoff. For example, assume a rapid moving MN moves at speed

V(m/s), the wireless LAN cell size is D(m) and the mobile IP handoff latency is T(s). If V

x T > D, the MN can never register to the wired network. Therefore, it is critical to reduce

the mobile IP handoff latency in rapid moving environments.










Algorithm of Speed Adaptive MIP

In Chapter 3, we define MN handoff rate as rh = v / d. It means MN move through

how many APs or FAs per second. Chapter 3 also shows that the performance of MIP over

WLAN is depends on the MN handoff rate among FAs. Figure 3-13 shows when the

handoff rate is 0.02 FA/s, the average throughput is above 90kBytes/s. When the handoff

rate rises to 0.08 FA/s, the average throughput drops to around 50kBytes/s. This means

lower handoff rate has higher throughput. rh is also equal to the ratio of Khandoff/Ttravel. We

rewrite the handoff rate rh = v / d in Equation 7.

rh = Khandoff/ Ttravel. (Equation 7)

Where Khandoff is the number of handoffs occurred during the MN traveling. Travel is

MN's total travel time. In order to reduce handoff rate without changing total travel time,

we can reduce the number of handoffs. The optimal is Khandoff = 0

Let N be total FA numbers on the way MN traveling. Let's assume somehow M is

the number of FAs with whom the MN can communicate without L3 latency. The optimal

is M=N. But it costs too many resources, especially when the number of active MNs is

large. Also we don't know how long will the MN travel at the beginning.

We call M the size of the FA Set with whom the MN can communicate without L3

handoff latency. From IP level of view, M is the number of FAs that MN has registered to

and can communicate with at that moment.










Now the question is:

How to decide FA set size M
How to guarantee MN can communicate with a FA set almost like to do with a
single FA.

The first problem SA-MIP needs to deal with is to decide FA set size M. In SA-MIP

algorithm, M is decided by the following Equation.



M = handoff r +1 (Equation 8)

where t .. is the handoff time for every handoff procedure, and rh is the handoff

rate. Here we use the experimental average handoff time 9.142s for t .. rh is dynamic.

For example, at speed 40m/s, AP distance 500m, M = 9.142 x 40/500 1 + 1 = 2. At speed

80m/s, AP distance 500m, M = 3.

The second problem is how to guarantee MN can communicate with a FA set just

like it can do with one FA. Our solution is to let MN pre-register M potential FAs along the

way MN traveling, at the same time multicast IP packets to those FAs in this FA set. So

MN won't feel any handoff latency from the IP level of view.

In Speed Apative MIP(SA-MIP), the set of FAs that MN can talk to without L3

latency is extended from one point at low moving speed to a line at high moving speed.

The length of the line dynamically changes with the MN handoff rate as in figure 5-2. The

behavior of SA-MIP will automatically adapt to the handoff rate of the MN so that the

performance of SA-MIP won't decline dramatically in rapid moving environments. At the

same time SA-MIP only cost reasonable resource that is as much as enough for seamless

handoff.










M=l M=2 M=3 M=4


rh= 0 0rh < 0.109 0.109

Figure 5-2 FA Set size vs handoff rate

Speed detection and location tracking is an interesting topic on mobile computing.

[BahlOO][Yous03] are all making use of signal strength information to locate and track

wireless users. [Erge02] uses GPS to inform mobile users about the prospective future

location and to improve performance of the ad hoc routing. In this paper, we assume the

MN has GPS system to detect its location. When the MN moves at speed v, ifv <

30m/s(67. 10miles/h), it performs a normal registration. If 30m/s < v < 40m/s(89.4miles/h),

it initializes registration after receiving two successive agent advertisements. If v>

40m/s(89.4miles/h), we assume the MN won't change it's direction largely in a short

distance. It initializes registration once it gets a new agent advertisement.

MN's registration message is extended by speed extension. According to Mobile IP

Vendor/Organization-Specific Extensions[RFC3115]. Two Vendor/Organization Specific

Extensions are allowed for MIP, Critical (CVSE) and Normal (NVSE)

Vendor/Organization Specific Extensions. The basic difference is when the CVSE is

encountered but not recognized, the message containing the extension must be silently

discarded, whereas when a NVSE is encountered but not recognized, the extension should

be ignored, but the rest of the Extensions and message data must still be processed. We use

the NVSE extension.










The following is the NVSE format.

0 1 2 3
01 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I vendor-NVSE-Type | vendor-NVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5-3 Normal vendor/organization specific extension

In figure 5-3, the type here is 134 for NVSE extension. Length is the size in bytes of

the extension, not including the type and length bytes. The verdor/org-ID is assigned in

RFC 1700. We pick up a large unassigned number 5205. Vendor-NVSE-Type Indicates

the particular type of Vendor-NVSE-Extension. The administration of the

Vendor-NVSE-Types is done by the Vendor. Vendor-NVSE-Value here is a floating point

number for handoff rate.

Figure 5-4 shows the SA-MIP handoff procedure and message exchange.

Whenever the MN needs to handoff to a new FA set, after it gets that many times of

agent advertisements which is determined by speed(step 1 in figure 5-4), it sends a

registration request with up-to-date handoff rate information to the very first FA in a new

FA set(step 2). The first FA relays the registration request to upper FA or HA(step 3).

Meanwhile, it decapsulates the speed extension, refill the MIP header and authentication

extension and then forward it to other FAs(M-1 FAs) in this FA set(step 4). Assume the

handoff rate is below 0.109. The FA set size at this time is 2. These other FAs relay the

registration request to upper FA or HA as well, just like the request comes from the









MN(step 5). When the GFA or HA received these registration requests, it builds up tunnels

downwards to each FA and responses with registration reply(step 6 and 7). When the FA

received the registration reply, it builds up tunnel upwards to the GFA or HA.



-?
internet CN




6 13
FA1 4 12i FA3 FA4








f1 MN


Figure 5-4 SA-MIP handoff procedure

Whenever the MN setups the Link-layer contact with the FA, the later forwards the

registration reply to the former(step 9 or 10). The MN gets the care-of-address from agent

advertisement message(step 10 or 9) or registration reply message(step 9 or 10), and

begins data communication. At the same time, it sends registration request to the new FA

with up-to-date speed information (step 11). This new FA decapsulates the registration

request message and sets up a new FA set. Assume the handoff rate is between 0.109 and

0.218. The FA set size is 3 at this time. The new FA(FA2) refill the MIP header and

authentication extension and then forward it to other FAs(FA3 and FA4 in the figure) in










this FA set and repeats the above process. In Figure 5-4, the FA set size M changes from 2

to 3 when the MN handoff rate changes from 0.08 to 0.11.

Implementation of Speed Adaptive MIP

Mobile IP has three main entities, HA, FA and MN. HUT dynamic MIP

implementation version 0.8.1, originally developed at Helsinki University of Technology

(HUT), is a scalable, dynamical, and hierarchical Mobile IP software for Linux operating

system. The SA-MIP is developed on HUT dynamic MIP implementation version 0.8.1.

Home Agent

The HA implementation of SA-MIP is almost the same as HUT dynamic MIP except

the Registration Request validation check function. The following describes the basic

functionalities of HA.

The HA is responsible for encapsulating and forwarding packets to its MNs when

they are away from their Home Network. It also decapsulates and forwards tunneled

packets originating from its Mobile Nodes. The HA communicates with FAs and MNs

using Berkeley IP sockets. The HA listens to ICMP agent solicitation messages from MNs

on a "packet" socket. ICMP agent advertisement messages are sent in reply to these

messages on the same socket. The HA also listens to Registration Requests on a UDP

socket (port 434 by default) originating from FAs or MNs. If Registration Requests is

validate a mobility binding for the requested Mobile Node will be established or, if one

already exists, updated. The request is then answered with an corresponding Registration

Reply.










When received of a Registration Request Message the HA performs a Registration

Request validation check process. It first looks up the shared secret for the corresponding

MN. The shared secret is used to check the MAC of the request message. If a Mobility

Binding for the MN exists, then the timestamp in the request is checked to be greater than

the one in the Mobility Binding. If either of these checks fails the HA responds to the

sender with a Registration Reply indicating registration failure. If the checks succeed the

HA determines the smaller lifetime value of the one in the request and the HA's

pre-configured maximum value. It then generates a Session Key and creates a Mobility

Binding consisting of the MN's address, its highest FA, the identification timestamp and

the Session Key. The HA then responds with a Registration Reply indicating registration

success. The message includes the same timestamp as the request, the lifetime value, a

MAC, the Session Key encrypted with the shared secret and the Session Key encrypted

with the highest FA's public key. The HA configures a tunnel between itself and the

highest FA and works as a proxy for the registered MN. If the lifetime in the request is set

to zero, the HA interprets this as a deregistration from the MN. On deregistration the HA

purges the tunnel configuration and stops the proxy ARP functionality for the MN's

address. If the FA differs in a reregistration, a Registration Reply with a lifetime set to

zero is sent to the previous FA to indicate that the old tunnel should be torn down.

In order to focus on performance issues of mobile IP, we ignore the security check

part. When the HA checks the validation of the Registration Requests, the MN-HA










authentication check is comment out. Figure 5-5 is the function flowchart of Registration

in HA.


Main loop() ] Handle_reg_msg()


Recvmsg()



Parse_msg()



Validaterequest()




Send_reg_failure() Send_reg_repl()

Figure 5-5 Function flowchart of registration in HA
Mobile Node


In addition to the basic function of HUT dynamic MIP's MN, the MN of SA-MIP

needs to transfer moving speed information to FAs. This is done by extending the

Registration Request message with speed extension. The Registration function in HUT

dynamic MIP implementation is the method by which MN requests forwarding services

when visiting a foreign network, informs their HA of their current CoA, renews a

registration which is due to expire, and/or deregisters when they return home.

The Registration Request message has the following format.












0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S Type = 1 ISI|BIDIDM|G|r Tx Lifetime
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Agent
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Care-of Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+ Identification +

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optional Non-Auth Extensions for HA ...
Variable length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type =32 Length SPI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SPI (cont..)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MN-HA Authenticator ( variable length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optional Non-Auth Extensions for FA .........
Optional MN-FA Authentication Extension...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Figure 5-6 Registration request message format


The Registration Request message header consists of the fields from Type to


Identification. The sendregistration () function in the MN implementation first fills out


the Registration Request header with corresponding data then fills out the extension.


Figure 5-7 is the Registration Request Message extension format.


0 1 2 3
01 2 34 5 6 7 8 01 2 34 5 6 7 01 2 3 4 5 6 7 8 9 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S Type | Length | Reserved
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vendor/arg-ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S vendor-NVSE-Type | vendor-NVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Figure 5-7 Registration request message extension format


The speed extension is as following.










struct speed_ext mn_speed; // speed_ext struct for SA-MIP

if(speedChanged) //compare the handoff rate send last time with current one.
{
mn_speed = (struct speed_ext *) pos;
if (left < sizeof(struct speed_ext)) //left is the message size after Registration
//header
return -1;
mn_speed ->type = VENDOREXT_TYPE2;
mn_speed ->length = sizeof(struct speed_ext) 2;
mn_speed ->reserved = 0;
mn_speed ->vendorid = htonl(VENDORIDDYNAMICS);
mn_speed ->sub_type = 25
mn_speed -> mn_spd = handoff_Rate;
pos += sizeof(struct speed_ext);
left -= sizeof(struct speedext);
}
Figure 5-8 show the function flowchart of sending Registration Request



main loop


sendregistration ()



fill_req_header


addreq_extensions ()

Figure 5-8 Function flowchart of sending registration request

Foreign Agent

Whenever the FA received a Registration Request from the MN, it decapsulates the

message, checks the speed extension. If the handoff rate is non-zero, this FA calculates the

FA set size M. It fills out the Registration Request header with new CoA and new MD5










MN-HA authentication. This new Registration Request message is sent to next M-1 FAs,

which in turn forward the Registration Request one level up or the HA.

Figure 5-9 is the function flowchart for FA handling Registration Request.


Figure 5-9 Function flowchart for FA handling registration request.


Evaluation of Speed Adaptive Extension for MIP


We evaluate the performance of SA-MIP over WLAN under the same scenario as in

Section 3. Figure 5-10 amd 5-11 are the time-sequence graph at speed 60m/s(rh = 0.06)and






88



80m/s(rh = 0.08) and AP distance 1000m. The average throughput at different speed is


listed in table 5-1

nrtM l 1


IOXOOMD

9O l -
1 OD )0 -
SWO-

1000000
sr-
OTO-
7000 -


3m-
am-
Ir-


10000-


mua~no O7~




~~/7'


I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I
S 10 2 u 25 30 35 I4 46 SO Sq C 6t 0 65 M s 90 9a 100 It s 110 11s 1a IS I V 13 140 145 150

Figure 5-10 Time-sequence graph at speed 60m/s and AP distance 1000m

T.-/SCeGh /


/7


/'


S'I "+ "I" "I I '"I "I' 'I""I" "I" "I"' I"I "I'" 'I'"'I'" I" "I "I"" I" I '"I '"I'"
5 10 15 20 25 30 3 40 45 50 5 W 65 70 75 80 8 90 5 10 105 10

Figure 5-11 Time-sequence graph at speed 80m/s and AP distance 1000m


z /-












Table 5-1 Average throughput for speed-adaptive MIP
Speed AP Bytes Travel Arg Handoff
(m/s) distance transferred Time(s) throughput Rate
(m) (kB) (kB/s) (FAs/s)
20 1000 85000 399 213.03 0.02
40 1000 37500 198 189.39 0.04
60 1000 19400 130 149.23 0.06
80 1000 11600 99 117.17 0.08
10 500 84400 398 212.06 0.02
20 500 37400 198 188.89 0.04
30 500 19500 131 148.55 0.06
40 500 11500 98 117.34 0.08

Figure 5-12 is the average throughput vs. handoff rate before and after the speed


adaptive MIP is installed. After installing SA-MIP, at handoff rate 0.02 FA/s, the average


throughput is improved by (212.54 197.35)/ 197.35 = 7.69%. At handoff rate 0.04, 0.06


and 0.08 FA/s, the average throughput is improved by 13.02%, 15.97% and 24.73%


respectively.


Kbytes/sec

220-


-- SA-MIP



MIP


(212.55- 197.35) /197.35
(189.14- 167.34) /167.34
' (148.89 128.32) /128.32
(117.25- 94.12) /94.12 =


= 7.69%
=13.02%
=15.97%
24.58%


0 0.02 0.04 0.06 0.08
Handoff rate FA/s


Figure 5-12 Average throughput vs. handoff rate


200

180-

160

140

120

100-

80
















CHAPTER 6
SUMMARY AND FUTURE WORKS

In this dissertation, in order to evaluate the rapid mobility of MIP in a laboratory

environment, we build up the performance evaluation testbed on Wireless LAN. The

emulation experiments showed that MIP is not suitable for rapid moving environments.

We depicted the relationship between the performance and the handoff rate of MN and

quantitatively analyzed the handoff latencies of the MIP over wireless LAN. A Speed

Adaptive MIP is proposed and evaluated. The emulation showed that the SA-MIP can

improve the performance from 8% to 25% when the handoff rate changes from 0.02 FA/s

to 0.08 FA/s. Compared to the mechanisms of Malki[Malk02] and Koodli's

mechnism[Kood02], SA-MIP combines the pre- and post-registration methods, but keeps

indenpendency from L2 infrastructure. Compared to Hsieh[Hsi03] and Wijngaert's

mechnism[Wijn04], SA-MIP not only predicts its next move but also involves next M

number of FAs according to MN's moving speed.

In our work so far, SA-MIP only deal with L3 handoff latency. But there is still

physical link break from the Layer 2 handoff And also we noticed that even in SA-MIP,

the biggest part of handoff latency was still the layer4 TCP back-off-latency. In future

works, the speed adaptive scheme should be applied to layer 2 and layer 4 handoff

latencies.