DT測試信令分析流程

會計學(xué)1DT測試信令分析流程Layer3層信令解析第三層信息（GSMLayer3），包括無線資源管理（RR）移動性管理（MM）、呼叫控制（CC）三方面信息*CC層的主要功能為建立、維持和釋放呼叫：a、有關(guān)呼叫建立的信息（CallEstablishment）:Alerting：告警信息，上下行。從網(wǎng)絡(luò)到主叫移動臺或從被叫移動臺到網(wǎng)絡(luò)，用來指示被叫手機啟動告警（即回鈴音）。Callconfirmed：呼叫確認(rèn)，該信息由被叫移動臺發(fā)出，用來確證收到呼叫請求；Callproceeding：呼叫進(jìn)程，該信息由網(wǎng)絡(luò)發(fā)向主叫移動臺，指示被請求的呼叫建立信息已經(jīng)被接收,不會再接收更多的呼叫建立信息。Connect：連接，從網(wǎng)絡(luò)到主叫移動臺或從被叫移動臺到網(wǎng)絡(luò)，用來指示連接被接受；Connect

Acknowledge：連接確認(rèn)，從網(wǎng)絡(luò)到被叫移動臺或主叫移動臺到網(wǎng)絡(luò)，指示移動臺得到一個呼叫；EnergencySetup：緊急建立，由移動臺發(fā)出，用來啟動一個緊急呼叫的建立；Progress：進(jìn)展，從網(wǎng)絡(luò)到移動臺，指示呼叫的進(jìn)程；Setup：建立，上下行，指示啟動呼叫建立；第1頁/共47頁CC層信令b、呼叫信息狀態(tài)（CallInformationPhase）Modify：修改，上下行，請求改變呼叫的承載能力；ModifyComplete：修改完成，指示對呼叫承載能力修改的完成；ModifyReject：修改拒絕，上下行，指示改變呼叫的承載能力請求的失?。籙serInformation：用戶信息,由移動臺發(fā)向網(wǎng)絡(luò)來傳輸信息到遠(yuǎn)端用戶或由網(wǎng)絡(luò)發(fā)向移動臺傳輸從遠(yuǎn)端用戶來的信息。c、呼叫清除（CallClearing）Disconnect：斷連，從移動臺到網(wǎng)絡(luò)請求清除端到端的連接，或從網(wǎng)絡(luò)到移動臺指示端到端的連接已經(jīng)被清除了；Release：釋放信道；第2頁/共47頁MM層信令*MM層的功能主要為位置管理：

a、注冊（Registration）IMSIDetatchIndication：IMSI分離指示,由移動臺發(fā)往網(wǎng)絡(luò),在網(wǎng)絡(luò)中設(shè)置一個無效指示LocationUpdatingAccept：位置更新接收,網(wǎng)絡(luò)發(fā)向移動臺,指示更新或IMSI(國際移動用戶識別碼)的附著完成LocationUpdatingReject：位置更新拒絕,網(wǎng)絡(luò)到移動臺,指示更新或IMSI(國際移動用戶識別碼)的附著失敗b、連接管理（ConnectionManagement）CMServiceAccept：CM業(yè)務(wù)接受，從網(wǎng)絡(luò)到移動臺，指示被請求的業(yè)務(wù)已經(jīng)被

接受Reject：CM業(yè)務(wù)拒絕，從網(wǎng)絡(luò)到移動臺，指示被請求的業(yè)務(wù)不能提供CMServiceAbort：CM業(yè)務(wù)中斷，從網(wǎng)絡(luò)到移動臺，指示被CM的業(yè)務(wù)中斷CMServiceRequest：CM業(yè)務(wù)請求，從移動臺到網(wǎng)絡(luò)CMRestablishmentRequest：CM重建請求，Abort：中斷,網(wǎng)絡(luò)到移動臺第3頁/共47頁RR層信令*RR層的主要功能為在無線接口上管理傳輸路徑及切換：a、信道建立ImmediateAssignment：立即指配,網(wǎng)絡(luò)給移動臺分配一個SDCCH,(只包含一個MS指配信息),包括指配信道的描述、"信道請求"的信息字段和接收到"信道請求"幀的幀號、最初的時間提前量、起始時間指示(可選).ImmediateAssignmentExtended：立即指配擴展(同時包含兩個MS指配信息),ImmediateAssignmentReject：立即指配拒絕b、切換AssignmentCommand：指配命令,網(wǎng)絡(luò)發(fā)向移動臺,指示移動臺改變當(dāng)前信道配置,切換到分配的專用信道,啟動低層連接建立AssignmentComplete：指配完成,指示主信令鏈路成功建立.AssignmentFailure：指配失敗,包括指配失敗的原因HandoverComplete：切換完成,MS發(fā)向網(wǎng)絡(luò),指示切換成功完成,網(wǎng)絡(luò)釋放原有信道.HandoverFailure：切換失敗,MS發(fā)向網(wǎng)絡(luò),網(wǎng)絡(luò)釋放新的信道PhysicalInformation：物理信息第4頁/共47頁RR層信令c、信道釋放ChannelRelease：信道釋放,包括RR原因指示、BA范圍d、尋呼PagingRequestType1：尋呼請求類型1,網(wǎng)絡(luò)給兩個移動臺發(fā)尋呼,包括尋呼模式、移動臺1和2需要的信道、移動識別1、移動識別2等PagingRequestType2：尋呼請求類型2,網(wǎng)絡(luò)給三個移動臺發(fā)尋呼,包括尋呼模式、移動臺1和2需要的信道、移動識別1、移動識別2、移動識別3等PagingRequestType3：尋呼請求類型3,網(wǎng)絡(luò)給四個移動臺發(fā)尋呼,包括尋呼模式、移動臺1和2需要的信道、移動識別1、移動識別2、移動識別3、移動識別4等PagingResponse：尋呼響應(yīng),移動臺到網(wǎng)絡(luò),包括密鑰序列號及移動識別e、系統(tǒng)信息SystemInformationType1：系統(tǒng)信息類型1,網(wǎng)絡(luò)到所有移動臺,在BCCH上發(fā)送,

指示RACH的控制信息及小區(qū)配置信息SystemInformationType2：系統(tǒng)信息類型2,網(wǎng)絡(luò)到所有移動臺,在BCCH上發(fā)送,

指示RACH的控制信息及鄰小區(qū)的BCCH信息SystemInformationType3：系統(tǒng)信息類型3,網(wǎng)絡(luò)到所有移動臺,在BCCH上發(fā)送,指示RACH的控制信息、小區(qū)識別號、位置區(qū)識別號、控制信道信息及小區(qū)選擇參數(shù)等第5頁/共47頁RR層信令SystemInformationType4：系統(tǒng)信息類型4,網(wǎng)絡(luò)到所有移動臺,在BCCH上發(fā)送,指示RACH的控制信息、位置區(qū)識別號、小區(qū)選擇參數(shù)、CBCH信道描述、CBCH移動配置SystemInformationType5：系統(tǒng)信息類型5,網(wǎng)絡(luò)到所有移動臺,在SACCH上發(fā)送,指示鄰小區(qū)的BCCH信息SystemInformationType6：系統(tǒng)信息類型6,網(wǎng)絡(luò)到所有移動臺,在SACCH上發(fā)送,小區(qū)識別號、位置區(qū)識別號、允許的NCC等SystemInformationType7：系統(tǒng)信息類型7,用于小區(qū)重選SystemInformationType8：系統(tǒng)信息類型8,用于小區(qū)重選第6頁/共47頁

DT測試詳細(xì)的信令流程及消息1MS主叫流程2MS被叫流程3掛機流程

4位置更新流程

5SMS尋呼流程6切換流程7系統(tǒng)消息第7頁/共47頁MS主叫流程(MO)－簡圖第8頁/共47頁MS主叫流程(MO)第9頁/共47頁二、MS被叫流程(MT)第10頁/共47頁三、掛機流程第11頁/共47頁四、位置更新流程第12頁/共47頁六、SMS尋呼流程第13頁/共47頁

MS切換流程消息目標(biāo)小區(qū)描述目標(biāo)信道切換參考號是否同步第14頁/共47頁系統(tǒng)消息（TYPE1-8)SystemInformationType1：系統(tǒng)信息類型1,網(wǎng)絡(luò)到所有移動臺,在BCCH上發(fā)送,指示RACH的控制信息及小區(qū)配置信息。SystemInformationType2：系統(tǒng)信息類型2,網(wǎng)絡(luò)到所有移動臺,在BCCH上發(fā)送,指示RACH的控制信息及鄰小區(qū)的BCCH信息。SystemInformationType2bis：系統(tǒng)信息類型2bis,網(wǎng)絡(luò)到所有移動臺,在BCCH上發(fā)送,指示RACH的控制信息及擴展的鄰小區(qū)的BCCH信息。SystemInformationType3：系統(tǒng)信息類型3,網(wǎng)絡(luò)到所有移動臺,在BCCH上發(fā)送,指示RACH的控制信息、小區(qū)識別號、位置區(qū)識別號、控制信道信息（T3212）及小區(qū)選擇參數(shù)等。SystemInformationType4：系統(tǒng)信息類型4,網(wǎng)絡(luò)到所有移動臺,在BCCH上發(fā)送,指示RACH的控制信息、位置區(qū)識別號、小區(qū)選擇參數(shù)、CBCH信道描述、CBCH移動配置。系統(tǒng)消息第15頁/共47頁SystemInformationType5：系統(tǒng)信息類型5,網(wǎng)絡(luò)到所有移動臺,在SACCH上發(fā)送,指示鄰小區(qū)的BCCH信息。SystemInformationType5bis：系統(tǒng)信息類型5bis,網(wǎng)絡(luò)到所有移動臺,在SACCH上發(fā)送,指示擴展的鄰小區(qū)的BCCH信息。SystemInformationType6：系統(tǒng)信息類型6,網(wǎng)絡(luò)到所有移動臺,在SACCH上發(fā)送,小區(qū)識別號、位置區(qū)識別號、允許的NCC等。SystemInformationType7：系統(tǒng)信息類型7,用于小區(qū)重選。SystemInformationType8：系統(tǒng)信息類型8,用于小區(qū)重選。系統(tǒng)消息第16頁/共47頁Systeminformationtype5MeasurementReport:其中鄰區(qū)BCCH-FREQ下內(nèi)容為BA表中之順序號(FROM0)

RXLEV-NCELL數(shù)值=實際接收電平+110818994739175第17頁/共47頁Layer3層信令分析DT問題分析流程GPRS信令分析目錄第18頁/共47頁DT考核項目介紹考核項目

1里程掉話比定義：里程掉話比=（≥-94dBm的測試路段里程數(shù)）/掉話總次數(shù)；2公路覆蓋率＝（≥-94dBm測試路段里程數(shù)）/測試路段總里程數(shù)×100％；3城區(qū)覆蓋率＝（≥-90dBm測試路段里程數(shù)）/測試路段總里程數(shù)×100％；4接通率定義：接通率＝接通總次數(shù)/試呼總次數(shù)×100％；

5掉話率定義：掉話率＝掉話總次數(shù)/接通總次數(shù)×100％

6話音質(zhì)量定義：取MOS值第19頁/共47頁DT測試統(tǒng)計接通率，定義：接通率＝接通總次數(shù)/試呼總次數(shù)×100％；說明：試呼次數(shù)：以channelrequest和CMservicerequest同時出現(xiàn)來確定試呼開始。接通次數(shù)：當(dāng)一次試呼開始后出現(xiàn)了Connect，ConnectAcknowledge消息中的任何一條就計數(shù)為一次接通。接通率＝總（Connect或ConnectAcknowledge）數(shù)/總（channelrequest和CMservicerequest）數(shù)×100％接通率取主叫測試手機的統(tǒng)計結(jié)果。第20頁/共47頁DT測試統(tǒng)計掉話率，定義：掉話率＝掉話總次數(shù)/接通總次數(shù)×100％；說明：接通次數(shù)：當(dāng)一次試呼開始后出現(xiàn)了Connect，ConnectAcknowledge消息中的任何一條就計數(shù)為一次接通掉話次數(shù)：在一次通話中如出現(xiàn)Disconnect或ChannelRelease中任意一條，就計為一次呼叫正常釋放。只有當(dāng)兩條消息都未出現(xiàn)而由專用模式轉(zhuǎn)為空閑模式時，才計為一次掉話。（如通話時間不足規(guī)定時長，出現(xiàn)釋放，要求通過層3信令解碼判斷原因）掉話率取主、被叫手機的統(tǒng)計結(jié)果掉話率＝（主叫掉話+被叫掉話）/（主叫接通+被叫接通）×100％第21頁/共47頁DT測試統(tǒng)計覆蓋率，定義：覆蓋率＝（>=-90dBm的采樣點數(shù)）/總采樣點數(shù)×100％；說明：取主、被叫手機的測試結(jié)果話音質(zhì)量說明：取MOS值。話音質(zhì)量取主、被叫手機的統(tǒng)計結(jié)果之和?？疾祉椖科骄艚薪r延說明：呼叫建立時延：出現(xiàn)最后一條channelrequest到alert的時間差（以幀號差計算）。取所有測試的平均時長。取主叫手機的測試結(jié)果第22頁/共47頁DT分析流程－掉話第23頁/共47頁DT分析流程－掉話第24頁/共47頁DT分析流程－覆蓋差

信號覆蓋差分析1、通常認(rèn)為接近或低于測試規(guī)范定義的有效覆蓋電平即認(rèn)為是覆蓋

2、如果屬于無主覆蓋而且質(zhì)量較差，也認(rèn)為是覆蓋差。第25頁/共47頁DT分析流程－話音質(zhì)量第26頁/共47頁DT分析流程－切換問題

第27頁/共47頁DT分析流程－切換問題第28頁/共47頁DT分析流程－切換問題第29頁/共47頁Layer3層信令分析DT問題分析GPRS信令分析目錄第30頁/共47頁TBF的建立流程兩步接入第31頁/共47頁TBF的建立流程一步接入第32頁/共47頁TBF數(shù)據(jù)傳輸指配上行TBF網(wǎng)絡(luò)側(cè)在PACKETUPLINKASSIGNMENT或PACKETTIMESLOTRECONFIGURE消息中指定下列參數(shù)來描述上行TBF：唯一的TFI（MS應(yīng)按照這個TFI值設(shè)置每個上行RLC數(shù)據(jù)塊的TFI域）；用于上行傳輸?shù)囊唤MPDCH；TBF啟動時間（可選項，用于動態(tài)或擴展動態(tài)分配）。第33頁/共47頁TBF數(shù)據(jù)傳輸下行RLC模式的傳送網(wǎng)絡(luò)側(cè)通過設(shè)置PACKETDOWNLINKASSIGNMENT或PACKETTIMESLOTRECONFIGURE消息的RLC_MODE比特來設(shè)置下行TBF的RLC模式。上行RLC模式的傳送MS可通過PACKETRESOURCEREQUEST或PACKETDOWNLINKACK/NACK消息中的RLC_MODE比特來設(shè)置上行TBF的RLC操作模式。在一階段接入過程中，RLC模式缺省為RLC確認(rèn)模式。在CDS的RLC/MAC的BLOCKHEADER的信令分析中，我們可以去分析上行信號或者下行信號的ACK消息，從而得知BSS或MS是否收到RLC數(shù)據(jù)包第34頁/共47頁TBF的釋放流程如果下面七種情況出現(xiàn)，則TBF釋放：在上行方向沒有數(shù)據(jù)傳送并且下行延遲釋放定時器或者擴展上行定時器超時GPRS/EGPRS終端發(fā)生了小區(qū)重選上行TBF丟失發(fā)生持續(xù)TA信息的PDCH被預(yù)清空或者發(fā)生故障GSL發(fā)生故障小區(qū)被閉塞小區(qū)支持GPRS的功能被激活第35頁/共47頁TBF的釋放流程根據(jù)MS的能力和MS的RAC是否在BSS已知，上行TBF可以兩種模式：

非擴展上行TBF模式：如果MS是RR99版本以前或者是MS的RAC信息在BSS中未知擴展上行TBF：如果MS是R4版本和BSS已知MS的RAC信息如果R4的手機的RAC信息BSS了解后，TBF可以由非擴展模式進(jìn)行擴展模式。上行TBF在定時器ULDELYA內(nèi)仍然保持激活。在超時之前，如果MS需要發(fā)生數(shù)據(jù)，則在原有的TBF發(fā)生，而不需要重新建立TBF。MS允許終端定時器的計數(shù)并在同一TBF下發(fā)生數(shù)據(jù)。如果沒有數(shù)據(jù)傳送并且定時器超時。則上行TBF釋放。第36頁/共47頁

ATTACH流程

第37頁/共47頁ATTACH流程從空口的消息來看，attachrequest到attachaccept共有7條信令在傳送，其中只有attachrequest由于要傳送34個byte，當(dāng)采用CS-1時，一個Radioblock可傳送20個byte，因此需要2個Radioblock。當(dāng)采用CS-2時，一個Radioblock可傳送30個byte，因此也需要2個Radioblock。其他的信令消息都比較小，只要1個Radioblock。一個Radioblock需20ms，空口共需要160ms。從手機發(fā)送attachrequest到attachaccept接收完，完全必須在空口傳送的消息只有attachrequest，第一個PacketUplinkAck/Nack，PacketDownlinkAssignment和attachaccept。其他的消息都是Ack消息，在這種短數(shù)據(jù)業(yè)務(wù)的傳送中可以滯后傳送也并不會影響實際的時延。因此空口最短只需要傳送5個Radioblock，共100ms。得出不包括手機鑒權(quán)的Attach過程在空口上的理論傳輸時延在100ms~160ms。第38頁/共47頁PDP流程第39頁/共47頁PDP流程從空口的消息來看，ActivatePDPContextRequest到ActivatePDPContextAccept共有9條信令在傳送，信令消息都比較小，只要1個Radioblock。一個Radioblock需20ms，空口共需要180ms。但從實際需要來看，從手機發(fā)送ActivatePDPContextRequest到ActivatePDPContextAccept接收完，完全必須在空口傳送的消息只有標(biāo)記為紅色的消息是必須發(fā)的。也就是空口只需要傳送7個Radioblock，共140ms。滯后傳送也并不會影響實際的時延。得出PDP激活過程在空口上的理論傳輸時延在140ms~180ms。與Attach類似，根據(jù)經(jīng)驗PDP信令在空口上傳輸時延也只占無線側(cè)時延近三分之一左右的時間，無線側(cè)實際的時延主要體現(xiàn)在系統(tǒng)解Radioblock，建立下行TBF，以及手機解開包的時間。這些時間非常依