1、手機性能測試經驗分享,1,主叫流程 2,通話切換 3.常見問題,主叫流程,鏈路信道建立請求消息 終端鏈路信道指配消息(信道的頻點和時隙的位置) 同步突發(fā)脈沖,在呼叫建立過程和切換建立時隙的頻率和時間同步。 啟動多幀傳輸模式，設置異步通信 對SABM的響應 多幀通信建立 建立呼叫的初始信息（承載能力,設施,主被叫號碼） 申請接受區(qū)域信息(終端切換的參數(shù)) 向PS通告區(qū)域信息 通知終端切換模式,主叫呼叫流程,對語音是否加密,密鑰 移動參數(shù),是否需要鑒權,鑒權的算法,尋呼類型 鑒權過程 釋放FACCH信道 確認 鏈路釋放 主叫屏幕開始進入計時界面 和通話有關的硬件被打開,microphone,rec

2、eiver,ADPCM編碼,主叫手機進入等待通話階段,主叫呼叫流程,30 0f 00 20 08 1a 57 1a 1a 44 26 80 00 44 RT L1 start monit L1開始找尋基站 2.781 30 4b 00 9e 01 13 2e 50 01 39 RT CS_ID 2.781 30 4b 00 9e 01 13 3e 25 01 4a RT CS_ID 這個即是RSSI最好的CS 2.953 30 0f 00 20 08 1a 57 18 55 aa 81 60 00 4e RT - L1 PCH information 2.953 30 4b 00 9e 01

3、13 3e 25 01 4a RT CS_ID 選定一個基站,準備階段(MMI層發(fā)送主叫指令至L3,RT層尋找基站建立CCH),TCH請求階段(RT層做具體操作),2.953 31 57 00 01 02 02 09 00 RT - CS link cch req 手機向基站發(fā)送請求分配業(yè)務信道的請求 3.470 30 0f 00 20 08 00 00 00 00 00 00 00 00 4e RT CS link cch rereq 重發(fā)請求 4.453 30 0f 00 20 08 00 00 00 00 00 00 00 00 4e RT CS link cch rereq 5.860

4、 30 04 00 20 07 01 RT - L1 primitive 5.953 30 0f 00 20 08 1a 57 1a 1a 7a 34 a0 00 4b RT - L1 pch information 6.470 30 0f 00 20 08 1a 57 13 23 a3 81 00 00 4a RT - L1 pch information 6.156 30 12 00 04 20 08 01 02 02 12 a0 81 00 00 RT - L1 lch assignment L1向RT發(fā)送信道發(fā)配成功消息 6.188 30 09 00 05 00 RT - L1 Uwa

5、ve IND L1向RT發(fā)送U波檢測成功信息 6.219 30 20 00 06 RT - L1 tch sync L1向RT發(fā)送TCH(業(yè)務信道)同步信息,L2的建立,6.219 30 1e 00 06 11 01 RT - L2 facch est req RT向L2發(fā)送FACCH建立請求，下面是建業(yè)務通道，約定業(yè)務信道載頻和時隙 6.219 26 01 00 3f 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 l2 to l1 data req -facch L2向L1發(fā)送FACCH數(shù)據(jù)傳送請求 6.235 28 01

6、00 10 02 01 00 from l1 inf facch 從L1收到FACCH 6.297 27 01 00 10 01 01 00 02 73 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 from L1 data facch 6.297 30 19 00 06 11 03 RT L2 sacch est req RT向L2發(fā)送SACCH建立請求 6.297 26 00 00 3f 09 00 00 l2 to l1 data req sacch L2向L1發(fā)送SACCH數(shù)據(jù)傳送請求 6.313 28 00 00 10 02 00 00

7、 from l1 inf sacch 6.328 27 00 00 10 01 00 00 02 73 0b 00 00 from L1 data -sacch 6.328 30 18 00 07 11 01 RT MM tch est cfm or ind RT向MM發(fā)送業(yè)務信道建立確認信息 6.328 33 03 00 31 04 00 00 00 MM get TCH establishment confirm from RR,6.344 41 16 00 01 pm send cc set up request to cc 發(fā)送cc setup請求, 說明pm發(fā)給cc setup消息

8、6.344 35 98 00 00 00 00 03 80 8c a4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . CC CS: SETUP CC向基站發(fā)送SETUP消息 6.360 2a 01 00 01 24 02 l2 iformat facch 6.360 26 01 00 02 04 00 a2 00 45 01 01 05 04 03 80 8c a4 6c 0e 00 80 30 35 37 l2 to l1 data req -(facch) L2向L1發(fā)送數(shù)據(jù)傳輸請求,通過FACCH傳輸 6.375 28 01 00 10 02 0

9、1 00 from l1 inf facch 6.375 26 01 00 02 04 02 a2 00 38 35 35 38 37 31 34 30 70 09 80 38 37 35 39 31 35 6.438 27 01 00 10 01 01 00 04 71 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 from L1 data facch 6.531 27 01 00 10 01 01 00 04 70 c9 00 45 01 81 02 00 00 00 00 00 00 00 00 00 00 00 00

10、00 from L1 data facch 6.531 35 02 00 45 01 81 02 CC PM: CALL-PROCEEDING,CC的建立,RT 消息/鑒權/釋放FACCH,6.547 30 22 00 07 RT CS function req RT function request 6.750 30 24 00 43 05 09 10 00 15 17 c0 RT L1 CS enc key set RT encryption key set 6.766 31 5f 00 07 RT - PM fun cfm RT向PM發(fā)送RT function request確認信息 6

11、.781 50 0b 00 51 01 pm send function request to MM MM function request 6.781 34 00 00 a5 3d MM get function request from PM 6.844 32 06 00 MM get auth req from net MM authentication request 6.844 32 07 00 MM send auth rsp to net MM authentication request response 6.844 34 01 00 51 02 MM send functio

12、n confirm to PM MM function request 確認信息 鑒權成功后被叫網絡開始和被叫進行連接 6.938 2b 00 00 11 07 01 04 l2 release indication 6.938 30 23 00 07 01 01 RT PM drel 7.172 2c 00 00 45 01 81 01 1e 02 82 88 l2 send to msg to l3,172 35 01 00 45 01 81 01 1e 02 82 88 CC PM: ALERT 7.188 50 4d 00 PM - ADPCM enter commu 7.188 27

13、 00 00 10 01 00 00 04 08 4e 51 00 from L1 data -sacch 7.203 27 00 00 10 01 00 00 04 1a 4f e0 01 from L1 data -sacch 7.203 2d 00 00 01 06 00 ff l2 rx all ifrm before sending to l3 7.203 2c 00 00 45 01 81 07 l2 send to msg to l3 7.203 26 00 00 d1 0d 00 00 l2 to l1 data req -sacch 7.203 35 07 00 45 01

14、81 07 CC PM: CONNECT 當被叫向網絡傳送CC Alerting時主叫方聽到回鈴音 當被叫向網絡傳送CC Connect時主被方開始正式通話 如被叫沒有和網絡連接成功則會聽到網絡提示音 根據(jù)以上,可以在測試MO時,我們無需聽回鈴音來判斷主叫方是否與網絡連接,只要看到計時開始就算成功MO一次.,Alerting/connect,切換,基本介紹,1) 基站和手機都有權利發(fā)起切換。 2) FER是怎么得到的：檢驗1.2s內即240幀的誤幀數(shù)，它通過檢測UW（識別字）中的16bit或32bit的數(shù)據(jù)是否正確，還有檢驗CRC是否正確，在通信信道里CRC是CI (邏輯信道標識) SA +

15、I共180 bit數(shù)據(jù)產生的16bit的數(shù)據(jù)，在控制信道里它是由PR(前導碼)CAC(公共接入信道)共170bit數(shù)據(jù)產生的16個bit的數(shù)據(jù)，其中PR在控制時隙中為了更好的實現(xiàn)位時鐘同步，它的數(shù)據(jù)是固定不便的62bit的數(shù)據(jù), 通信信道里的PR為6bit。 PS：在待機是FER值永遠不會高于1。 3) 手機側如何判斷做什么切換：在此以手機側發(fā)起切換為例子，當RSSI值波動不大，但FER很大時，說明收到干擾，但此時離原來的CS的距離沒什么變化，只是這個TCH信道不能用，則一般執(zhí)行TCH切換；當RSSI值下降，此時一般來說FER也會升高，則是說明原CS不能使用需要執(zhí)行RECALL切換。無縫切換比

16、較特殊，在每個支持無縫切換的手機中會有一系列的參數(shù)來確定無縫切換的門限，總的說是還是看RSSI和FER來確定判斷：,RSSI： 強信號區(qū) - RSSI-1 當RSSI在某一瞬間跨區(qū)跳變則做無縫 次強區(qū) - RSSI-2 切換，3個門限依照不同的手機確定， 次弱區(qū) - RSSI-3 228的RSSI-1為40，RSSI-2為36,FER: 當在1.2秒內FER突然高于一個特定值時，手機做無縫切換。,4）3種切換在流程上的區(qū)別：recalling切換在流程上和主叫流程相仿，只是少了Alerting和鑒權倆個步驟，而TCH切換因為不需要重新選擇基站則不需要進行建鏈。無縫切換與 recalling 的

17、區(qū)別：2 ports status,在新的鏈路上CC setup之后斷開原語音通道，所以無縫切換基本對用戶通話不產生影響。,基本介紹,5)切換的典型log語句: 在分析R200協(xié)議前,簡單介紹一下Sanyo protocol : (1) 06:06 14 00 00 33 03 29 00 1a 40 10 10 RSSI-FER(No.1TCH) RSSI (33)and FER (03), (2) 06:06 77 77 83 01 83 0b 01 33 83 39 35 34 38 2c 18 01 ba 33為RSSI值，83為FER值 39為待機切換目標基站電平值，35為待機電平切

18、換值（開始尋找別的基站） 34為通話電平切換值（開始尋找別的基站），38為通話切換目標基站電平值 (3) 06:07 33 ca 00 TR306P(new CS monitor)T/O handover start(普通切換) (4) 06:07 3f 00 33 9e 01 12 30 12 03 3c 00 Handover CCH Monitor monitor CS, CS-ID(9e 01 12 30 12 03 ) and RSSI(3c) (5) 06:07 12 01 00 19 00 00 9e 01 10 5e 28 03 cch_est_req 切換的目標基站CS-ID

19、 (6) 06:09 3e 2e 00 00 00 00 00 00 00 U wave testing end display 信道檢測,最后一位為00表示此信道沒有干擾 (7) 06:10 31 07 01 45 01 85 07 1c 06 91 a2 03 02 01 01 Response handover end(成功切換),基本介紹,R200 protocol: (1)2971.573 30 2a 00 08 RT do recalling handover 開始做recalling切換 (2)9.414 31 5a 00 07 02 RT - PM handover start

20、 9.414 31 ca 00 08 RT PORT1 - PORT2 monitor req 開始做seamless切換 (3)42.151 30 c9 00 20 10 01 RT PM handover switch or recall end 結束切換流程 (5)248.808 30 27 00 08 RT - CS switch indication in calling from net 網絡要求發(fā)起切換 從以上兩個協(xié)議的解釋來看, R200的注釋要詳盡,基本可以從注釋中看出此行l(wèi)og的意思, 而Sanyo protocol 的注釋要少于R200,且注釋很抽象, 象UT628等手機

21、的log的注釋都是日文,所以在分析Sanyo protocol的時候我們要多結合STD-28規(guī)范來查看, 以下我分析log中的問題都是從UT228歷次性能測試中截取的log,也就是R200的協(xié)議.,常見問題,UT228(R200協(xié)議)切換中的問題： 1，附近沒有合適的基站（或是合適的載頻）而導致該次切換失?。?200.168 31 5a 00 07 02 RT - PM handover start 200.168 31 ca 00 08 RT PORT1 - PORT2 monitor req 開始做seamless切換 200.168 40 33 00 05 42 26 37 33 34

22、38 d5 pm send rssi indication to MMI 200.178 44 3b 00 02 a0 pm send ho start indication to MMI 200.178 30 ca 00 32 01 RT PORT2 PM handover switch or recall end 200.428 4b 39 00 60 b6 pm send mmi ho end ind when seamless wait tch 200.428 50 60 00 200.438 49 48 00 52 18 00 01 a0 pm send cc smho end re

23、q in global function 200.438 35 9f 00 00 01 01 00 00 CC - PM: seamless HO end seamless 切換結束 以上的log為做seamless切換因外沒有合適是載頻而停止，在228切換測試中能大量的讀到此類信息，事實證明seamless在弱型號區(qū)里的很難做成功，因外很難找到合適的載頻反而會引起頻繁切換的問題，影響通話質量。,常見問題,2，一系列的“超時”影響切換： 1.TR001P:1200ms, 4次001超時結束切換 Start conditions :“Link channel establishment requ

24、est ”,或是“Link channel establishment re-request ” Stop conditions :“Link channel assignment” 或是“Link channel assignment reject” 85.954 31 57 00 01 02 02 09 00 aa RT - CS link cch req 在找到新CS后,向新的CS做業(yè)務信道分配請求 886.014 30 0f 00 20 08 00 00 00 00 00 00 00 00 3b RT CS link cch req 向該基站重新請求業(yè)務信道,常見問題,2.TR101P

25、:200ms, 4次超時結束切換 Start conditions: Without unwanted signal in the TCH designated by “Link channel assignment” Stop conditions: “Synchronization establishment” reception 887.647 80 0c 00 14 05 29 40 0a L1 indication uwave to RT 887.647 30 04 00 20 02 01 00 RT CS link cch rereq 重新請求信道 在log中我們能發(fā)現(xiàn)在建鏈中存在

26、大量的TR001和TR101超時,這個是無法避免的,但是他們的存在確實對手機在弱信號區(qū)的切換有很大的影響,常見問題,3.掉話： 1.網絡主動斷線引起掉話, 106.973 2d 00 00 00 02 7e 07 l2 rx all ifrm before sending to l3 106.983 27 00 00 00 00 04 06 8e 40 21 from L1 data -sacch 106.983 2d 00 00 00 03 43 01 l2 rx all ifrm before sending to l3 107.003 27 00 00 00 00 04 18 0d 24

27、 00 from L1 data -sacch 107.003 2d 00 00 01 04 04 81 l2 rx all ifrm before sending to l3 107.003 2c 00 00 45 01 07 45 08 03 02 85 90 l2 send to msg to l3 107.003 26 00 00 00 04 b1 0d l2 to l1 data req -(sacch) 107.003 35 45 00 45 01 07 45 08 03 02 85 90 CC PM: DISCONNECT 此時的掉話往往沒有征兆,突然斷線,這個現(xiàn)象不是我們軟件協(xié)

28、議所能控制的,在現(xiàn)實log中此類的斷線比例也不是很高,所以我們一般不對這種掉線分析。,2.新的TCH建立失敗而掉話.(切換流程中) 1)同步超時: 37.634 30 41 00 0e f2 0d RT TRMONITP Timer Out 37.634 30 4b 00 9e 01 11 ae a6 02 RT CS_ID 37.634 30 4b 00 9e 01 11 ae a6 02 39 RT CS_ID 找到一個合適的基站 37.634 31 57 00 01 02 02 09 00 RT - CS link cch req 向該CS做建TCH請求 37.634 80 1c 00

29、02 03 L1 ready to tx scch 38.896 30 04 00 f2 01 RT CS link cch req 重新請求 38.896 80 1c 00 05 03 L1 ready to tx scch 38.976 30 0f 00 20 08 00 00 00 00 00 00 00 00 36 RT PM handover switch or recall end 切換停止 39.697 48 39 00 00 47 pm send ho end indication to MMI in HO 40.709 30 04 00 f2 14 RT - L1 primi

30、tive 40.709 30 48 00 0d f2 14 RT TRDLRELP Timer Out 斷鏈Send RT “Radio-channel disconnection complete”,常見問題,常見問題,2).連接時間超時 195.891 30 4b 00 9e 01 94 3e c1 01 3b RT CS_ID 195.891 31 57 00 01 02 02 09 00 RT - CS link cch req 向該CS做建TCH請求 195.891 80 1c 00 02 05 L1 ready to tx scch 196.052 30 0f 00 20 08 0

31、0 00 00 00 00 00 00 00 3c RT - L1 pch information 196.082 80 11 00 07 0a L1 scch tx cfm . 211.263 80 12 00 04 01 0a aa 14 be 13 14 24 00 a2 18L1 rx NULL msg 211.303 50 63 00 f5 0a 02 00 00 00 04 08 211.303 50 5f 00 211.303 34 0a 00 51 0b 00 00 MM get PM a disc command TCH建立時間太長,超過PM TIMER(15S),從而掉話.

32、 在切換中都要重新建立TCH,所以一半以上的掉話都是由于TCH建立失敗而導致.,常見問題,3.switch back失敗而掉話(切換不成功而switch back) 444.960 80 01 00 00 37 L1 cch monit 444.960 80 01 00 00 36 L1 cch monit 444.970 30 04 00 f2 0d RT PM handover switch or recall end 445.922 48 39 00 00 22 pm send ho end indication to MMI in HO 445.922 50 60 00 447.023 30 04 00 f2 14 RT - L1 primitive 447.033 30 48 00 0d f2 14 RT TRDLRELP Timer Out Send RT “Radio-channel disconnection complete” 在現(xiàn)實中有大半掉線情況由于switch back失敗而導致. 一般手機在弱信號區(qū)因為話音質量的降低而導致連續(xù)的切換，用來保證手機不掉話。所以我們在性能測試時會聽到連續(xù)的DI-DI-聲，在切換過程中如果切換不成功，手機可以重新回到原來的TCH信道上進行通話,因為即使是在切換過程中原來的通