空中接口学园--求救?基站总需要第二次分配链路?

  《空中接口学园》
>>   PHS技术
>>>>  求救?基站总需要第二次分配链路?

--  作者：FreeRun
--  发布时间：2004-08-10 08:59:23
有一个室内分布系统，信源使用的是中兴CS28组控基站，接着使用PHS干放进行信号的放大，现在发现一个问题，在室内做呼叫测试时，基站第一次分配TCH载频和时隙后，手机都没有响应，最后导致TCH同步超时（--[<TCH Synchronize Time's up]--），紧接着基站第二次分配TCH载频和时隙，手机才有响应，手机给基站发送TCH同步突法脉冲（CS<-PS TCH syn. burst  ），整个呼叫才能继续。在拨打电话时，手机侧听到一声“嘀”，接着才能听到对方的回铃声。
     在19次呼叫中，有17次出现上面的问题，即基站需要进行第二次链路分配才能正常通信。呼叫使用的UT318型手机，拨打10000号，测试时间为星期六上午，话务不繁忙，同时测试位置基站信号场强很高，大于50dBuv，没有误码。用PHS35L仔细查看这19次呼叫的链路协议，第二次分配的TCH载频没有规律，19到50号载频都有，结合PHS35L的同步和频谱测试，整个网络是同步的，没有大的干扰。最后比较2次成功的和17次需二次分配的测试，发现了些问题。那2次成功的呼叫，基站第一次分配TCH载频是在手机请求后的100ms发起的(如：167ms、153ms),而其他的17次呼叫，基站发起的第一次TCH载频分配是在100mS内（比如：82ms、62ms、87ms、72ms、52ms、77ms...）。
      是什么导致基站需第二次分配链路,呼叫才能成功呢? 对这个问题，本人甚感迷惑，附上相关的协议,敬请各位大侠指教！谢谢！

--  作者：FreeRun
--  发布时间：2004-08-10 09:01:37
相关协议:17次基站第一次分配不成功的例子
--- Date/Time[04.08.06/11:21:41]
(0)[CS-ID:80F608401D8] / [PS-ID:6FA5D61]
||       0.00000||0 CS<-PS Link cha. request:SCCH[0102020C00][ 80]dBuV
||      57.50417||0 CS->PS Link cha. assig. :SCCH[0106072601][ 53]dBuV
Relative Slot[8]/Carrier No.[38]/Contr.Slot.No.[2]/Commu.Slot.No[1]
||     254.82167||0 --[<TCH Synchronize Time's up]--
||     357.50375||0 CS->PS Link cha. assig. :SCCH[0106072001][ 56]dBuV
Relative Slot[8]/Carrier No.[32]/Contr.Slot.No.[2]/Commu.Slot.No[1]
||     399.37375||0 CS<-PS TCH syn. burst   :Sync[0000000000][ 61]dBuV
||     406.87792||0 CS->PS TCH syn. burst   :Sync[0000000000][ 62]dBuV
||     414.18708||0 --<< Sync off
||     414.18708||0 -<- Idle TCH [8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF]
||     421.69083||0 -->> Sync off
||     421.69083||0 ->- Idle TCH [80001F1F11F11F1F11FF11F1F11FF11F1F1F111F1F1F]
||     439.18750||0 :<F10:U(3F) SABM [P=1] []
||     446.69125||0 :>F10:U(73) UA   [F=1] []
||     449.18708||0 :<S10:U(3F) SABM [P=1] []
||     461.69125||0 :>S10:U(73) UA   [F=1] []
||     479.18708||0 <<F10:I(00) I    [N(R)=0 P=0 N(S)=0] [450103050403808CA46C0E008030303230]
||     494.18708||0 :<F10:I(12) I    [N(R)=0 P=1 N(S)=1] [35313232373038337006803130303030]
||     494.18708||0 <[45010305] <CC SETUP
CC [Bearer Capability:0403808CA4]
CC [Calling Party number:6C0E0080303032303531323237303833]
CC [Called  Party number:7006803130303030]
||     501.69125||0 :>F10:S(51) RR   [N(R)=2 F=1] []
||     521.69125||0 :>F11:I(50) I    [N(R)=2 P=1 N(S)=0] [45018302]
||     521.69125||0 >[45018302] >CC CALL PROC
||     534.18708||0 :<F11:S(31) RR   [N(R)=1 F=1] []
||     549.18708||0 :<F10:I(34) I    [N(R)=1 P=1 N(S)=2] [430181]
||     549.18708||0 <[4301]     <RT DIRq
RT [Definition Info.Req.:81]
||     556.69125||0 :>F10:S(71) RR   [N(R)=3 F=1] []
||     561.69125||0 :>F11:I(72) I    [N(R)=3 P=1 N(S)=1] [4302013F3C39422C6005]
||     561.69125||0 >[4302]     >RT DIRs
RT [Area Info.:013F3C39422C6005]
||     574.18750||0 :<F11:S(51) RR   [N(R)=2 F=1] []
||     589.18750||0 :<F10:I(56) I    [N(R)=2 P=1 N(S)=3] [43040910001507C0]
||     589.18750||0 <[4304]     <RT FRq
RT [Encryption:091000]
RT [TCH Reassign:1507]
RT [Zone Info.Indicat.Func.:C0]
||     596.69125||0 :>F10:S(91) RR   [N(R)=4 F=1] []
||     601.69125||0 :>F11:I(94) I    [N(R)=4 P=1 N(S)=2] [43050910001517C0]
||     601.69125||0 >[4305]     >RT FRs
RT [Encryption:091000]
RT [TCH Reassign:1517]
RT [Zone Info.Indicat.Func.:C0]
||     614.18750||0 :<F11:S(71) RR   [N(R)=3 F=1] []
||     629.18708||0 :<F10:I(78) I    [N(R)=3 P=1 N(S)=4] [43030910000D026FA5]
||     629.18708||0 <[4303]     <RT EKS
RT [Encryption:091000]
RT [Encryption Key Set:0D026FA5]
||     636.69167||0 :>F10:S(B1) RR   [N(R)=5 F=1] []
||     901.69208||0 :>F11:I(B6) I    [N(R)=5 P=1 N(S)=3] [440106010708F05B5FB1A7D50029]
||     901.69208||0 >[4401]     >MM ARq
MM [Authentication Type:0601]
MM [Authentication Random Pattern:0708F05B5FB1A7D50029]
||     914.18750||0 :<F11:S(91) RR   [N(R)=4 F=1] []
||     934.18792||0 :<F10:I(9A) I    [N(R)=4 P=1 N(S)=5] [44020508BD0F5B7DCB392EDE]
||     934.18792||0 <[4402]     <MM ARs
MM [Active Chipherring Pattern:0508BD0F5B7DCB392EDE]
||     941.69208||0 :>F10:S(D1) RR   [N(R)=6 F=1] []
||     946.69208||0 :>F11:U(53) DISC [P=1] []
||     959.18792||0 :<F11:U(73) UA   [F=1] []
[11:21:42]>{64dBuV ERR(  0,  0)}
||    1136.69250||0 >>S11:I(00) I    [N(R)=0 P=0 N(S)=0] [4501]
||    1146.69250||0 >>S11:I(02) I    [N(R)=0 P=0 N(S)=1] [8301]
||    1156.69250||0 >>S11:I(04) I    [N(R)=0 P=0 N(S)=2] [1E02]
||    1166.69250||0 :>S11:I(16) I    [N(R)=0 P=1 N(S)=3] [8088]
||    1166.69250||0 >[45018301] >CC ALERT
CC [Progress Indicator:1E028088]
||    1179.18792||0 :<S11:S(91) RR   [N(R)=4 F=1] []
[11:21:43]<{52dBuV ERR(  0,  0)}
||    1946.69375||0 >>S11:I(08) I    [N(R)=0 P=0 N(S)=4] [4501]
||    1956.69375||0 :>S11:I(1A) I    [N(R)=0 P=1 N(S)=5] [8307]
||    1956.69375||0 >[45018307] >CC CONN

--  作者：FreeRun
--  发布时间：2004-08-10 09:04:39
相关协议:2次基站第一次分配成功的例子
--- Date/Time[04.08.06/11:13:35]
(0)[CS-ID:80F608401D8] / [PS-ID:6FA5D61]
||       0.00000||0 CS<-PS Link cha. request:SCCH[0102020E00][ 56]dBuV
||     167.50333||0 CS->PS Link cha. assig. :SCCH[0106072B01][ 52]dBuV
Relative Slot[8]/Carrier No.[43]/Contr.Slot.No.[2]/Commu.Slot.No[1]
||     214.37583||0 CS<-PS TCH syn. burst   :Sync[0000000000][ 56]dBuV
||     216.87792||0 CS->PS TCH syn. burst   :Sync[0000000000][ 52]dBuV
||     224.18708||0 --<< Sync off
||     224.18708||0 -<- Idle TCH [8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF]
||     231.69083||0 -->> Sync off
||     231.69083||0 ->- Idle TCH [8000FF11F1F111F1F111FF1F111F1FF1F1F11F1F111F]
||     249.18708||0 :<F10:U(3F) SABM [P=1] []
||     256.69083||0 :>F10:U(73) UA   [F=1] []
||     259.18667||0 :<S10:U(3F) SABM [P=1] []
||     271.69083||0 :>S10:U(73) UA   [F=1] []
||     289.18667||0 <<F10:I(00) I    [N(R)=0 P=0 N(S)=0] [45017E050403808CA46C0E008030303230]
||     304.18667||0 :<F10:I(12) I    [N(R)=0 P=1 N(S)=1] [35313232373038337006803130303030]
||     304.18667||0 <[45017E05] <CC SETUP
CC [Bearer Capability:0403808CA4]
CC [Calling Party number:6C0E0080303032303531323237303833]
CC [Called  Party number:7006803130303030]
||     311.69083||0 :>F10:S(51) RR   [N(R)=2 F=1] []
||     331.69083||0 :>F11:I(50) I    [N(R)=2 P=1 N(S)=0] [4501FE02]
||     331.69083||0 >[4501FE02] >CC CALL PROC
||     344.18667||0 :<F11:S(31) RR   [N(R)=1 F=1] []
||     359.18667||0 :<F10:I(34) I    [N(R)=1 P=1 N(S)=2] [430181]
||     359.18667||0 <[4301]     <RT DIRq
RT [Definition Info.Req.:81]
||     366.69125||0 :>F10:S(71) RR   [N(R)=3 F=1] []
||     371.69083||0 :>F11:I(72) I    [N(R)=3 P=1 N(S)=1] [4302013F3C39422C6007]
||     371.69083||0 >[4302]     >RT DIRs
RT [Area Info.:013F3C39422C6007]
||     384.18708||0 :<F11:S(51) RR   [N(R)=2 F=1] []
||     399.18708||0 :<F10:I(56) I    [N(R)=2 P=1 N(S)=3] [43040910001507C0]
||     399.18708||0 <[4304]     <RT FRq
RT [Encryption:091000]
RT [TCH Reassign:1507]
RT [Zone Info.Indicat.Func.:C0]
||     406.69125||0 :>F10:S(91) RR   [N(R)=4 F=1] []
||     411.69083||0 :>F11:I(94) I    [N(R)=4 P=1 N(S)=2] [43050910001517C0]
||     411.69083||0 >[4305]     >RT FRs
RT [Encryption:091000]
RT [TCH Reassign:1517]
RT [Zone Info.Indicat.Func.:C0]
||     424.18708||0 :<F11:S(71) RR   [N(R)=3 F=1] []
||     439.18708||0 :<F10:I(78) I    [N(R)=3 P=1 N(S)=4] [43030910000D026FA5]
||     439.18708||0 <[4303]     <RT EKS
RT [Encryption:091000]
RT [Encryption Key Set:0D026FA5]
||     446.69125||0 :>F10:S(B1) RR   [N(R)=5 F=1] []
||     691.69167||0 :>F11:I(B6) I    [N(R)=5 P=1 N(S)=3] [440106010708849D27BAE814F418]
||     691.69167||0 >[4401]     >MM ARq
MM [Authentication Type:0601]
MM [Authentication Random Pattern:0708849D27BAE814F418]
||     704.18750||0 :<F11:S(91) RR   [N(R)=4 F=1] []
||     724.18750||0 :<F10:I(9A) I    [N(R)=4 P=1 N(S)=5] [44020508B40090A845060DF6]
||     724.18750||0 <[4402]     <MM ARs
MM [Active Chipherring Pattern:0508B40090A845060DF6]
||     731.69125||0 :>F10:S(D1) RR   [N(R)=6 F=1] []
||     736.69167||0 :>F11:U(53) DISC [P=1] []
||     749.18750||0 :<F11:U(73) UA   [F=1] []
||     956.69208||0 >>S11:I(00) I    [N(R)=0 P=0 N(S)=0] [4501]
||     966.69208||0 >>S11:I(02) I    [N(R)=0 P=0 N(S)=1] [FE01]
||     976.69208||0 >>S11:I(04) I    [N(R)=0 P=0 N(S)=2] [1E02]
||     986.69167||0 :>S11:I(16) I    [N(R)=0 P=1 N(S)=3] [8088]
||     986.69167||0 >[4501FE01] >CC ALERT
CC [Progress Indicator:1E028088]
||     999.18792||0 :<S11:S(91) RR   [N(R)=4 F=1] []
||    1721.69333||0 >>S11:I(08) I    [N(R)=0 P=0 N(S)=4] [4501]
||    1731.69292||0 :>S11:I(1A) I    [N(R)=0 P=1 N(S)=5] [FE07]
||    1731.69292||0 >[4501FE07] >CC CONN
...
...

--  作者：FreeRun
--  发布时间：2004-08-10 09:32:09
19次测试的统计测试表,其中第7次和第13次是一次分配接入成功的.
测试地点,,XX楼8楼过道和楼梯口处
测试时间,,2004年8月7日上午
PSID,,6FA5D61
拨打序号,时间,CSID,Relative Slot,Carrier No,Contr.Slot.No,Commu.Slot.No,备注,,
1,11:17:20,80F608401D8,2,41,2,3,[<TCH Synchronize Time's up],,
                       2,45,2,3,OK
2,11:23:56,80F608401D8,8,43,2,1,[<TCH Synchronize Time's up],,
                       3,48,2,4,OK,,
3,11:24:05,80F608401D8,3,48,2,4,[<TCH Synchronize Time's up],,
                       2,23,2,3,OK,,
4,11:25:44,80F608401D8,3,33,2,4,[<TCH Synchronize Time's up],,
                       2,20,2,3,OK,,
5,11:21:41,80F608401D8,8,38,2,1,[<TCH Synchronize Time's up],,
                       8,32,2,1,OK,,
6,11:21:48,80F608401D8,3,33,2,4,[<TCH Synchronize Time's up],,
                       3,22,2,4,OK,,
7,11:13:35,80F608401D8,8,43,2,1,OK,,
8,11:13:42,80F608401D8,8,19,2,1,[<TCH Synchronize Time's up],,
                       2,34,2,3,OK,,
9,11:13:51,80F608401D8,2,32,2,3,[<TCH Synchronize Time's up],,
                       8,19,2,1,OK,,
10,11:14:02,80F608401D8,3,39,2,4,[<TCH Synchronize Time's up],,
                       1,21,2,2,OK,,
11,11:14:10,80F608401D8,3,38,2,4,[<TCH Synchronize Time's up],,
                       3,35,2,4,OK,,
12,11:44:10,80F608401D8,2,38,2,3,[<TCH Synchronize Time's up],,
                       2,21,2,3,OK,,
13,11:44:26,80F608401D8,8,44,2,1,OK,,
14,11:51:05,80F608401D8,8,34,2,1,[<TCH Synchronize Time's up],,
                       2,47,2,3,OK,,
15,11:57:06,80F608401D8,8,42,2,1,[<TCH Synchronize Time's up],,
                       8,18,2,1,OK,,
16,11:57:12,80F608401D8,8,50,2,1,[<TCH Synchronize Time's up],,
                       8,23,2,1,OK,,
17,11:57:28,80F608401D8,8,50,2,1,[<TCH Synchronize Time's up],,
                       2,20,2,3,OK,,
18,12:02:37,80F608401D8,8,23,2,1,[<TCH Synchronize Time's up],,
                       2,23,2,3,OK,,
19,12:02:45,,8,23,2,1,[<TCH Synchronize Time's up],,
                       8,20,2,1,OK,,

--  作者：tom
--  发布时间：2004-08-10 09:40:56
奇怪，协议中没有第二次链路分配一说，一旦基站链路分配失败，就需要终端重新发起链路建立请求。
  因此，我估计问题出在组控上，也就是组控的两个基站分别向终端分配了链路，终端只使用其中最后的指配。正常情况应该只分配一次链路，不知道这是不是一个新功能。

-- 作者：FreeRun
-- 发布时间：2004-08-11 09:45:24
昨天我又去测试了，发现使用UT618没有上述问题，而使用UT318，几乎每次都出现问题（基站需第二次分配TCH信道），难道是手机类型的问题吗？？是不是UT318手机对基站在100ms内分配的ＴＣＨ信道没来得及响应吗？？

-- 作者：transmit
-- 发布时间：2004-08-11 10:27:07
其他类型的手机呢？

-- 作者：华人
-- 发布时间：2004-08-11 12:21:46
第二次请求可能是35没有收到：）
建议对每个Transmitter的每个时隙进行测试：）
还有618的记录可以拿出来看一下呢？

--  作者：FreeRun
--  发布时间：2004-08-12 10:33:20
因为时间很紧,没有那么多的手机类型作测试呀,有机会继续测试吧。不过后来询问局方网管，他们在上个星期对中兴的CS28进行了软件升级，不知道是否给这有关系？？
附带上UT618的测试记录：
--- Date/Time[04.08.10/16:56:18]
[CS-ID:80F608401D8] / [PS-ID:105361372]
||       0.00000||0 < PS SCCH: 0102020E00 56dBuV
||      47.50375||0 > CS SCCH: 0106062102 47dBuV
(Assigned: Abs.Slot  1 / CarrierNo. 33)
||      88.74708||0 < PS SYNC: 0000000000 56dBuV
||      98.75292||0 --<< Sync off
||     106.25292||0 > CS SYNC: 0000000000 47dBuV
||     111.06667||0 -->> Sync off
||     111.06667||0 ->- Idle TCH [80003113F21F11
||     113.56250||0 -<- Idle TCH [8000FFFFFFFFFF
||     183.56208||0 <[45010405] <CC SETUP
  CC [Bearer Capability:0403808CA4]
  CC [Calling Party number:6C0E008030303
  CC [Called  Party number:7006803130303
||     211.06583||0 >[45018402] >CC CALL PROC
||     238.56250||0 <[4301]     <RT DIRq
  RT [Definition Info.Req.:81]
||     251.06625||0 >[4302]     >RT DIRs
  RT [Area Info.:013F3C39422C6007]
||     278.56250||0 <[4304]     <RT FRq
  RT [Encryption:091000]
  RT [TCH Reassign:1507]
  RT [Zone Info.Indicat.Func.:C0]
||     291.06625||0 >[4305]     >RT FRs
  RT [Encryption:091000]
  RT [TCH Reassign:1517]
  RT [Zone Info.Indicat.Func.:C0]
||     318.56208||0 <[4303]     <RT EKS
  RT [Encryption:091000]
  RT [Encryption Key Set:0D02647A]
||    1001.06708||0 >[4401]     >MM ARq
  MM [Authentication Type:0601]
  MM [Authentication Random Pattern:0708
||    1033.56333||0 <[4402]     <MM ARs
  MM [Active Chipherring Pattern:05083F0
||    1251.06792||0 >[45018401] >CC ALERT
  CC [Progress Indicator:1E028088]
||    1926.06917||0 >[45018407] >CC CONN
||    3898.56833||0 <[45010445] <CC DISC
  CC [Cause:0803008590]
||    4071.07208||0 >[4501844D] >CC REL
  CC [Cause:0803028590]
||    4113.56833||0 <[4501045A] <CC REL COMP
||    4161.07250||0 >[4322]     >RT RDi
  RT [Cause:0680]
  RT [CS Ident.:0880F608401D02]
  RT [PS Ident.:0E647AFD0C]
||    4178.56875||0 <[4323]     <RT RDiC
  RT [CS Ident.:0880F608401D02]
  RT [PS Ident.:0E647AFD0C]
||    4283.76875||0 --<< TX off
||    4621.26875||0 ->>< TX off
--[Wait for a Link Channel Request]--
  [CrNo:26]
--[Wait for a Link Channel Request]--
  [CrNo:26]

-- 作者：FreeRun
-- 发布时间：2004-08-12 10:35:59
建议对每个Transmitter的每个时隙进行测试？？
怎么测试呀，是对基站每个端口进行测试吗？？
我不是局方的网优人员呀，没机会对基站的每个发射端口进行测试呀？

-- 作者：FreeRun
-- 发布时间：2004-08-12 11:21:53
今天又拿到两款手机进行测试，发现UT318、UT702-U都需要基站进行二次链路分配，UT618、ZTE767则没有上述问题。测试方法，拨打10000号，每款手机呼叫10次，用PHS35L进行协议链路跟踪。

--  作者：transmit
--  发布时间：2004-08-12 11:41:35
是否每次不成功时都是基站在100ms以内分配的？如果是那样的话，难道手机侧只能接收100ms以后的下行信号？应该不会啊！至少702-U我以前在Sanyo基站下测过，100ms以内的分配可以成功的呀！
流程如下：
[CS-ID:9E04833E278] / [PS-ID:027406D]
||       0.00000||0 CS<-PS Link cha. request:SCCH[0102020C00][ 77]dBuV
||      77.50250||0 CS->PS Link cha. assig. :SCCH[0106062C02][ 62]dBuV
Relative Slot[7]/Carrier No.[44]/Contr.Slot.No.[3]/Commu.Slot.No[1]
||     123.74917||0 CS<-PS TCH syn. burst   :Sync[0000000000][ 77]dBuV
||     131.25208||0 CS->PS TCH syn. burst   :Sync[0000000000][ 45]dBuV
||     133.75875||0 --<< Sync off
||     138.56250||0 -<- Idle TCH
||     151.06458||0 -->> Sync off
||     151.06458||0 ->- Idle TCH
||     173.56208||0 :<F10:U(3F) SABM [P=1] []
||     178.56208||0 :<S10:U(3F) SABM [P=1] []
||     181.06458||0 :>F10:U(73) UA   [F=1] []
||     191.06458||0 :>S10:U(73) UA   [F=1] []
||     213.56208||0 <<F10:I(00) I    [N(R)=0 P=0 N(S)=0] [450101050403808CA46C0E008030353734]
||     218.56208||0 <<F10:I(02) I    [N(R)=0 P=0 N(S)=1] [3636363131303432700980363636313130]
||     223.56208||0 :<F10:I(14) I    [N(R)=0 P=1 N(S)=2] [3439]
||     223.56208||0 <[45010105] <CC SETUP
CC [Bearer Capability:0403808CA4]

-- 作者：FreeRun
-- 发布时间：2004-08-13 10:02:59
是呀,每次基站在100ms以内分配TCH信道,UT702-U、UT318都需要基站进行二次链路分配，而基站类型是中兴的CS28基站。而ZTE767和UT618则没有这个问题，我测了好多次啦？？奇怪啦？？如果这样的话，忙时会对网络造成多大的影响呢？？

目前已经有13条评论 >>> 发表你的见解