华为呼叫迁移与a口掉话初步分析报告

1、华为bsc呼叫迁移功能与a 口掉话初步分析2009年6月，网优屮心组织华力公司就掉话问题进行了技术交流，华为工程师讲述了 在华为没备区进行跨bsc切换的流程，其中有部份切换在特定情况t由bsc申请、msc 参与，华为公司称该流程为“呼叫迁移”。网优屮心统计华为bsc间硬切换成功率平均只 有90%左右，联系到前阶段的a2掉话高的问题，就呼叫迁移功能与a2掉话率是否产生 影响进行了初步分析，下面简单地介绍一下。阁1为目前网络的基本示意图，为描述流程简洁，msce2+mgw称为msc2。在一般情况下，ms从bsc1下的bts1通话移动到bsc2下的bts2、bts3或bts4,在这个过程中ms将与服

2、务的bts发生切换，切换可能发生在2个bsc间的2个bts之间，也可 能发生在2个bsc间的多个bts之间，在无线的切换过程中将会产生无线小区的合并过程， 正常情况丁，无线bss系统应该合并2个bsc间可能发生切换的多个小区信息，通过2个 bsc间的a3/a7接口完成切换而不需要msc参与，fi前，华为的2个bss间能够完成bts1 到bts2的小区合并，但不能完成bts1到bts4的小区合并，所以，华为bss设计了呼叫迁 移功能来弥补无线小区合并的不足，呼叫迁移实际上就是msc参与的硬切换，下面是呼叫迁 移的主要信令流程。、“呼叫迁移”关键信令流程traffic frame切換糾央过种han

3、doff requestsccp conn ec* reqciej connect cpn armaois-bts setupabivcorrwctaois-cornect ackab s-bts setup ackbihs.2000 fch fwo(null dxj：handoff requiredhandoff direction messagems ack orderrrevels* tafficframe!abis-is-2000 fch f/(ghdmiabrs-is-2coo fch rvs(ms adc)歐/trafficchanrel preamble handoff comm

4、andhardoff commercedhardoff recuest ackw abis-is-2coc fch rvs(ldhanoof* completion vess巧e ab<s-ls-2k0 fch rvsfframeibase ack orcer蝙 abs-ls-2x0rvs(hcmrab.s-is-20(x) fch fwd(3ase a<clear commandclear completehandoff compilebts_sbsc.smscbsc-dbts一 di .源bsc的切换判决检测到需要进行呼叫迁移，其实就是要删除bsc1在激活屮的唯一一个 分支。2

5、. 源bsc将目标小区的信息放在handoff required消息巾发送到msc。msc为切换分配一条地面电路，将电路的cic、切换需要的无线信道类型等信息构造成handoff request消息。并且将该消息放在sccp connect request的用户数据域中发i4bsc4 (r标 bsc),要求建立sccp连接。3. 目标bsc和msc完成sccp的连接后开始处理层三的handoff request消息并建立abis地面链路，根据收到的handoff request消息巾指定的无线信道类型，分配一条合适的无 线业务信道。4. 目标bsc将该业务信道的标识等相关信息放在handoff

6、 request acknowledge消息屮 发送到msc。5. msc对收到的handoff request acknowledge消息进行分析，构造handoff command消息，发送到源bsc.6. 源bsc在收到handoff command消息以后，进行处理，向终端发送universal handoff direction message。7. universal handoff direction message是以确认模成发送的，所以终端在收到 universal handoff direction message以后，需要在层二进行确认，表示收到该消息。8. 源bsc在收

7、到终端的确认以后，构造handoh commenced消息，发送到msc，通知msc切换已经开始。9. 终端在发送完确认以后，离幵原来的信道，调整到切换的目标信道上进行接入。接入成功以后，终端就从新的信道上发送handoff completion message。10. 目标基站在收到终端上报的handoh completion message后一方面给终端发送确认 消息 ms ack order,同时向目标bsc发送handoff completion message。ii .目f小bsc在4夂至uhandoff completion message以后，衫j造handoff complet

8、e消息， 发送到msc,通知msc切换己经完成。12.130收至|)30( complete消息以后，认为切挽已经成功。然后开始淸除在源bsc 上占用的资源和呼叫连接。msc向源bsc发送clear command，启动释放流程。13.源bsc收至uciear command以后，立刻向msc发送clear complete表示该消息己经收到随后开始自身资源的淸除过程从呼叫迁移的关键信令流程可以看山，呼叫迁移走的信令流程就是硬切换流程，但是 硬切换由于采川的先断后连的方式，棹话的可能性比较大，在无线网络的切换中，应该尽力 避免采用硬切换的方式。平为公司为了在bsc间切换问题上回避“硬切换”字眼

9、，采用了 “呼叫迁移”这种称谓。通过对比替换前北电无线采用ibsho方式处理跨bsc切换的方式，我们发现华为公司 在处理处理跨bsc切换吋之所以要采用硬切换，主要是因为在切换吋候华为源bsc无法访 问目标bsc的邻区数据库，也并未有采用类似北电的逻辑邻区的概念，在源bsc中对目标 bsc的邻区等数据进行配置。当用户进行跨bsc间切换时，如果不开启“呼叫迁移功能” 必然会导致掉话！下而将华为关闭呼叫迁移后的关键信令流程表示如下：为了验证华为呼叫迁移关闭后的信令流程及掉话发生位罝，我们进行了多次测试如上图所示（黄色标注为起呼点，红色为掉话点）第一次测试从大坪电信门口起呼，占川bsc2的信号，在通话

10、状态下向两路口方向 （bsc1）切换，在国际村附近掉话。第二次测试从菜园坝大桥起呼，占用bsc1的信号，在通话状态下i4南坪四公里 （bsc3）切换，在菜园坝大桥南坪隧道内掉话。第三次测试从鹅公岩大桥头起呼，占用bsc3的信号，在通话状态下向陈家坪方向 （bsc2）切换，在大公馆立交掉话。以第一次呼叫为例，当ms起呼时占用bsc2的信号，呼叫管理模块以及选择器、声码 器均由bsc2分配，当ms在呼叫状态运动至鹅岭附近（bsc2与bsc1）边界处，巾于边界 处的扇区配罝了其附近的扇区（包括目标bsc1的扇区）为邻区，ms收索器能够检査到bsc1 位于边界处的pn强度，并正常的进行跨bsc软切换，

11、建立a3/a7链路，在bsc1建立分支， 并将语音帧通过a3/a7传送给bsc2进行选择合并。随着ms向bsc1深入，所占用的源bsc2分支信号强度越来越弱，ms将根据psmm切 换去的促发条件，向bsc2发送删除最后一条分支的请求，在关闭呼叫迁移功能的情况下， 华为bsc2并不会指示ms去掉该链路，ms将一直保留该链路，直到bsc2在进行帧合并吋， 由于该链路信号质量完全无法满足帧合并的同步要求，bsc判断掉话。二、呼叫迁移失败与a口掉话的关系在对呼叫迁移功能关闭后的测试屮，我们可以发现当ms判断掉话后，bsc并未判断掉 话，这与现网设置的掉话定吋器吋长设置有关。当ms向目标bsc深入，由于

12、无法进行软切换，无法将周边的信号加入aset,ec/lo越来 越差，手机前向链路连续收到12个坏帧，并在5s内没受到1个好帧，手机将关闭发射机。 实际路测中己经显示手机掉话，但bsc此时在反链路上还没有在连续15s内收到97%的 误帧，还没达到掉话门限。手机掉话后处于空闲状态，此吋会重新初始化，监听bsc1的寻呼信道，当发现收到的 spm消息巾nid等信息发生改变，将会马上发起位置登记。当登记消息发送到msc时候， msc会发现该用户还处于呼叫状态，因此会向源bsc下发n-disconnect消息，指示拆 除源链路，而此时源bsc还不知道ms已经发生掉话，会将该次掉话统计为a17释放，计入 a

13、2掉话中。这也正好解释了为什么关闭呼叫迁移功能后a2掉话次数反而增加。下面是bsc后台跟踪的消息。跟踪回顾d:工作资料20090710华为呼叫迁移功盅与a 口越话分析7月8日关闭呼叫迁移后的试1-bsc1 一乙消息类型消息方向到达时间243244245246247248249251252253254255256257258259260打a3a7 /-propagation delay measurement report abis abis-propagation delay report :abis abis-propagation delay report a3a7 /-propagati

14、on delay measurement report :a3a7 a3-pr叩agation delay measurement report abis abis-pr叩agation delay report um registration messageall location updating requestal njzonnect-con al location updating accept um order message al clear command al clear complete a1ndisconnect jnd a3a7 a7-drop target a3a7 a

15、3-remove abis abis-bts release abis abis-remover akirl akir-darbsend10:35:20:001:085bts->bsc10:35:20:000:121bts->b5c10:35:23:825:160send10:35:23:826:099send10:35:36:258:064bts->b5c10:35:36:257:065r-csch10:35:37:949:415|bsc->msc10:35:37:949:807msc->bsc10:35:38:033:308msc->bsc10:35:3

16、8:033:415f-csch10:35:38:033:697msc->bsc10:35:38:043:014bsc->msc10:35:38:043:530msc->bsc10:35:38:092:285receive10:35:38:430:274send10:35:38:446:096b5c->bts10:35:38:431:296bts->b5c10:35:38:445:114rc：r-x.rtcnm1298:um power measurement report messager-dsch10:35:35:057:1881299umpower measu

17、rement report messager-dsch10:35:35:197:2031300umpower measurement report messager-dsch10:35:35:338:3201301:umpower measurement report messager-dsch10:35:35:477:1891302:umpower measurement report messager-dsch10:35:35:617:2181303umpower measurement report messager-dsch10:35:35:757:1971304:umpower me

18、asurement report messager-dsch10:35:35:897:3071305:umpower measurement report messager-dsch10:35:36:038:5311306umpower measurement report messager-dsch10:35:36:177:2011307'a3a7 a3-propagation delay measurement reportreceive10:35:36:272:4751308allndisconnect indmsc->bsc10:35:38:041:4401309um o

19、rder messagef-dsch10:35:38:117:0301310:umorder messagef-dsch10:35:38:196:6261311umorder messagef-dsch10:35:38:276:5701312a3a7 a7-drop targetsend10:35:38:417:2411313a3a7a3-removereceive10:35:38:458:7541314a3a7a3-remove acksend10:35:38:460:2321315a3a7a7-drop target ackreceive10:35:38:498:519 跟踪回甬d:.工作

20、资料20090710华为呼叫迁移功盅与a 口掉话分析7月8日关闭呼叫迁从以上信令可以看出目标bsc1在10:35:37向msc发送了登记消息，msc在 10:35:38向源bsc2发送了n_disconnect消息，指示异常释放呼叫资源。下面为路测的数据，由于路测记录的时间为笔记本的系统时间，和后台记录的消息时间 有一点偏差，但采用的是同一imsi进行的测试，消息能对应上。p«ami value1rxacqdbml<£7077txagc(dbm)173tx pcwer(dbfrt)096txga(db)299total ec/lowb)refwence ec/i131

21、4maxeo1o<db)1114told ec(dbm)84 06relwence ec(d8406mad(ec(dbm)84.06reletence pn375maxec/lopn375ffer(x)q00acbvesel nurnber1fieouency201fparamvalue1rxagqdbm) <txagc(dbm)io.detx pcwer(<jbm)1716txgaad|(<fi)34 00told edo(db)rcfc<enceec/l.2460maxec/lo(db)-2460to«d ec(dbm)44.86reference

22、ec|d .砌85maxec(dbm)4 85rcfctencepn375maxec/lopn375fferii100 00acbvese* numbe<1frequency201se4ich |nc0hjer8dtescnacknowtedgemei二公订fttimedieciionmenjje10 35 18 416 103518:445 1035:18:516 10 351&905 10:35:21:845 10 3521 965 10 35 22116 10:35 22:156 103522165 103& 22178 10.35:22:205 10 35 22

23、27g 1035 22:3% 103522 3g5 10 35 22 43g0luldlululul0ldluldluldl0lutdl0l10352257s i dl10l522g45 1ft：10：tme 103548:865 10 35 收 005 1做格145 1ft36:49:285 1035 竹 425 1035 竹565 103549:705 1o3rew5 103549:985 103550125 103550265 1o3&5o4o5 103550545 103&50685ul0luldtechonululululululululululululululul1

24、035:50:965 ! ul103551:105ia»51:7s51036:52:281ul0l0lftc ordw>b 脱 s lalion ac*jw4edi>wnert rtc ordeohobie staton ackno¥4edoeme<il ftc ordeob 做 stabonacknoedownert power me«memeh» reportpower measuremert report metse pw sbenglh meurement mestdqe ftc 0rde(->bme station ac

25、knom4ed9«ner< urwveftal hardoh drccbon mesiaqe rtc orde<*>mome station ackncoedoemerri ftc orde<->b«e slatw aciwwjwnert handoff cocrcteton message ftc orde<>8 做ftc order>base slatwacknoedjjwnert power me«uie*«rt report ftc orde<->b«e sw>on ac

26、krwbdqwnert extended ne«£bo( list update me wag©ftc order->bme!rtcordc<>mowe s wion acknoedoemeri e tended hcigww li$< update me;sge rtcordc<>mome station acknov4edj)wnertmenagepower measurement reportpower meawiemenl report men姆e power meatae<nerm report meue pow

27、er meatuemenl report mess>e power meaumemerm report power meawiemenl report m 拗姆e power meauiemert report power meauicmenl report hee power meawiemenl report message power mewiemeni report power meauiemenl report me>e power meatuemenl report meste power meawremenl report power meatuemenl repor

28、t me说其 power med$uremerm report meuepower meastiemenlpower meaxuemerm report me:4esic charnel rre$>egeneref page message掉话前的测试数据cdma radio -|n| x|ocdluri ji icyiuouuii ivicaycy|ij |param| valuei timedirectionmessagerxagc(dbm)71.5810:35:50:965ulpower measurement report messagetxagc(dbm)10.0810:35:

29、51:105ulpower measurement report messagetx power(dbm)17.1610:35:51:765dlsync channel messagetx gain adj.(db)34.0010:35:52:281dlgeneral page messagetotal ec/lo(db)-4.7310:35:52:281dlgeneral page messagereference ec/i-4.7310:35:52:301dlextended system paramelers messagemaxeczlo(db)-6.6110:35:52:321dls

30、ystem parameters messagetotal ec(dbm)-76.3110:35:52:361dlgeneral page messagereference ec(d-76.3110:35:52:361dlgeneral page messagemax ec(dbm)-78.1910:35:52:381dlaccess parameters messagereference pn910:35:52:421dlneighbor list messagemax ec/lo pn910:35:52:441dlgeneral page messageffer()10:35:52:441

31、dlgeneral page messageaclivesel number110:35:52:461dlcdma channel list messagefrequency20110:35:52:461dlextended system parameters message10:35:52:501dlsystem parameters message10:35:52:502dlgeneral page message10:35:52:521dlaccess parameters message10:35:52:561dlneighbor list message10:35:52:581dlc

32、dma channel list message10:35:52:582dlgeneral page message10:35:52:601dlextended system paramelers message10:35:52:641dlsystem parameters message10:35:52:661dlaccess parameters message10:35:52:668ulregistration message10:35:52:681dlgeneral page message10:35:52:681dlgeneral page message10:35:52:721dl

33、neighbor list message10:35:52:721dlcdma channel list message掉话后的测试数据从以上数据看，掉话前占用的信号很差，ec/lo达到-24.6db，掉话后在1秒钟内注册 到新的小区，ec/lo为-4.73db,信号非常好，正常情况应该由差的小区很快切换到好的小 区，但由于关闭呼叫迁移功能后源bsc对对端的质量好的小区不能识别只能掉话。下面为关闭呼叫迁移后bsc1、bsc2的掉话统计数据：bsc1呼叫迁移关闭前后a2掉话次数对比呼叫迁移关闭后a 口掉话次数 6月 30 日 a2 掉诏次数92278150164148口7月7闩八2棹话次数526

34、81162171161 6月30ra2掉话次数国7月7日a2掉话次数bsc2呼叫迁移关闭前后a2掉话次数对比从6月30日与7月7日的6个时段a2棹话次数可以看出，7月6日关闭呼叫迁移后bsc1与bsc2的a2 掉话次数均有所增加。下面为关闭呼叫迁移功能前后bsc1、bsc2的bsc间硬切换统计数据:7月8-9日为关闭呼叫迁移，其余时间为呼叫迁移打开。bsc名称时间（按天）bs间硬切换切出请求次数bs间硬切换切出成功次数bs间切出成功率bs间硬切换切入请求次数bs间硬切换切入成功次数bs间硬切换成功率bs间硬切换总体成功率bsc12009-07-057718644083. 44%39603802

35、96. 01%87. 70%bsc12009-07-069628814884. 63%5102496797. 35%89. 04%bsc12009-07-080000bsc12009-07-090000bsc12009-07-109730821484. 42%7492730597. 50%90. 11%bsc12009-07-118742727583. 22%6655648597. 45%89. 37%bsc22009-07-056062502682.91%4111401497. 64%88. 86%bsc22009-07-067994663482. 99%5098499998. 06%88. 86%bsc22009-07-080000bsc22009-07-090000bsc22009-07-107855664284. 56%8432820297. 27%91. 14%bsc22009-07-116967575682. 62%7636745697. 64%90. 47%从以上数据可以看出，bscl