EV-DO-RevA-空口信令流程分析指導(dǎo)書(shū)(V30)

內(nèi)部公開(kāi)▲EV-DORevA空口信令流程分析指導(dǎo)書(shū)目的與范圍本指導(dǎo)書(shū)目的是為EV-DORevA信令分析提供思路和方法。本指導(dǎo)書(shū)適用于CDMA網(wǎng)規(guī)仿真部的EV-DORevA優(yōu)化工作。術(shù)語(yǔ)和定義角色和職責(zé)系統(tǒng)模塊介紹下面對(duì)基站內(nèi)部常見(jiàn)的軟件模塊的功能作詳細(xì)介紹：S_CES:信道單元子系統(tǒng)。主要負(fù)責(zé)信道板CHM的基帶數(shù)據(jù)的調(diào)制與解調(diào),實(shí)現(xiàn)空中接口物理層的編解碼和調(diào)制解調(diào)功能。S_RCP:無(wú)線(xiàn)信道管理。主要負(fù)責(zé)進(jìn)行Overhead信道，接入信道，前反向業(yè)務(wù)信道等無(wú)線(xiàn)資源的分配與管理。S_FSP:幀選擇模塊。主要負(fù)責(zé)反向業(yè)務(wù)幀的選擇，相關(guān)協(xié)議數(shù)據(jù)包的封裝和解封裝，前向業(yè)務(wù)幀的流量控制等。S_TP:業(yè)務(wù)處理模塊。主要負(fù)責(zé)實(shí)現(xiàn)缺省應(yīng)用和多流分組應(yīng)用的RLP協(xié)議，前向RLP分組的流量控制等。S_SP:信令處理模塊。主要負(fù)責(zé)相關(guān)協(xié)議的信令消息處理，連接層的信令處理流程，完成業(yè)務(wù)信道上的位置更新流程，session的配置協(xié)商，Key交換協(xié)議流程，切換的控制等S_BSSAP:基站系統(tǒng)應(yīng)用局部。主要負(fù)責(zé)集中管理所有已登記AT的Session信息,UATI分配，AT的移動(dòng)性管理功能，快速連接過(guò)程等S_PPPSession:PPP協(xié)議會(huì)話(huà)模塊。主要負(fù)責(zé)LCP協(xié)商流程、CHAP協(xié)商流程以及PPP狀態(tài)機(jī)的整個(gè)處理的流程和機(jī)制.S_AAAClient：認(rèn)證、授權(quán)、計(jì)費(fèi)客戶(hù)端模塊。主要負(fù)責(zé)對(duì)來(lái)自AAAServer的反應(yīng)報(bào)文的解碼和處理，對(duì)AAAServer的合法性進(jìn)行驗(yàn)證等指導(dǎo)書(shū)正文Session呼叫流程Session建立流程介紹上圖表示的是AT主動(dòng)發(fā)起一次新的會(huì)話(huà)建立流程，具體每個(gè)步驟的操作如下：過(guò)程過(guò)程描述aAT在接入信道上發(fā)送接入信道capsule，包含UmaUATIRequest和UmaRouteUpdate消息，每次AT在接入信道上發(fā)送，總會(huì)包含UmaRouteUpdate消息。該capsule由S_CES透明傳送給S_BSSAP。在capsule中AT可能使用固定生成的RATI〔可能是ESN等硬件ID〕，或者隨機(jī)生成的RATI作為自己的標(biāo)識(shí)。bS_CES對(duì)收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道給AT發(fā)送UmcACAck，使用AT接入信道capsule中MAC層header中包含的RATI標(biāo)識(shí)cS_BSSAP記錄RATI，并請(qǐng)求S_RCP、S_CES通過(guò)控制信道發(fā)送UmcHardwareIDRequest消息，同時(shí)啟動(dòng)定時(shí)器THardwareIDRequest等待響應(yīng)；如果定時(shí)器超時(shí)，S_BSSAP可請(qǐng)求S_CES重發(fā)UmcHardwareIDRequest消息2次。如果2次后仍未收到UmaHardwareIDResponse消息，那么直接結(jié)束session建立過(guò)程，不發(fā)送任何空中接口消息dAT在接入信道上發(fā)送接入信道capsule，包含UmaHardwareIDResponse和UmaRouteUpdate消息。S_CES傳送capsule給S_BSSAP，S_BSSAP停止定時(shí)器THardwareIDRequest，記錄AT的HardwareID到session數(shù)據(jù)區(qū)。eS_CES對(duì)收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道發(fā)送UmcACAck，使用AT接入信道capsule中MAC層header中包含的RATI標(biāo)識(shí)。f對(duì)于128比特的UATI，S_BSSAP只負(fù)責(zé)分配低24位比特，高104位比特由SectorID[127:24]組成，Sector的128比特SectorID和SubnetMask在Overhead的SectorParameters消息中通過(guò)控制信道周期性播送。在同一子網(wǎng)中，24比特的UATI是AT的唯一標(biāo)識(shí)。為防止128比特的UATI在空中傳輸，Sector的子網(wǎng)地址由8比特的ColorCode標(biāo)識(shí)，這樣空中接口只需要傳輸8比特的ColorCode和24比特的UATI就可以標(biāo)識(shí)AT。S_BSSAP分配UATI的低24位比特〔該24比特?cái)?shù)據(jù)不能和相同子網(wǎng)中的其它UATI的低24比特相同〕，和UmaUATIRequest消息收到的Sector對(duì)應(yīng)的8比特ColorCode合成一個(gè)32比特的UATI，請(qǐng)求S_CES在控制信道發(fā)送UmcUATIAssignment消息，該消息仍然使用RATI作為AT標(biāo)識(shí)，同時(shí)啟動(dòng)定時(shí)器TUATIComplete等待指配完成。如果S_BSSAP分配UATI失敗，應(yīng)直接結(jié)束session建立過(guò)程，不發(fā)送任何空中接口消息。如果TUATIComplete超時(shí)，S_BSSAP可請(qǐng)求S_CES重發(fā)UmcUATIAssignment消息2次，如果2次后仍未收到UmaUATIComplete消息，應(yīng)認(rèn)為session建立失敗。S_BSSAP釋放為AT分配的UATI，結(jié)束session建立過(guò)程，并可通過(guò)S_CES發(fā)送UmcSessionClose消息，釋放可能在AT中已經(jīng)存儲(chǔ)的UATI。GAT在接入信道上發(fā)送接入信道capsule，包含UmaUATIComplete和UmaRouteUpdate消息，capsule中的MAC地址使用新分配的UATI而不是RATI。S_CES傳送capsule給S_BSSAP，S_BSSAP停止定時(shí)器TUATIComplete，記錄AT的UATI到session數(shù)據(jù)區(qū)。HS_CES對(duì)收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道發(fā)送UmcACAck，使用AT接入信道capsule中MAC層header中包含的UATI標(biāo)識(shí)。下面對(duì)上述的流程進(jìn)行一個(gè)簡(jiǎn)單的介紹：(1)AT在接入信道上向AN發(fā)送接入信道capsule，包含UATIRequest和RouteUpdate消息，每次AT在接入信道上發(fā)送，總會(huì)包含RouteUpdate消息,在capsule中AT可能使用ESN或隨機(jī)生成的RATI作為自己的標(biāo)識(shí)；(2)AN收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道給AT發(fā)送ACAck，使用AT接入信道capsule中MAC層header中包含的RATI標(biāo)識(shí)；(3)AN記錄RATI，并通過(guò)控制信道發(fā)送HardwareIDRequest消息，請(qǐng)求查詢(xún)AT的HarewareID信息，即查詢(xún)AT的ESN(我們的設(shè)備是這樣設(shè)計(jì)的),作為AN計(jì)算AT的UATI的參考；(4)AT在接入信道向AN發(fā)送接入信道capsule，包含HardwareIDResponse和RouteUpdate消息，同時(shí)AN記錄AT的HardwareID到session數(shù)據(jù)區(qū)；(5)AN對(duì)收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道發(fā)送ACAck，使用AT接入信道capsule中MAC層header中包含的RATI標(biāo)識(shí)；(6)對(duì)于128比特的UATI，AN只負(fù)責(zé)分配低24位比特,高104位比特由SectorID[127:24]組成,Sector的128比特SectorID和SubnetMask在Overhead的SectorParameters消息中通過(guò)控制信道周期性播送。在同一子網(wǎng)中，24比特的UATI是AT的唯一標(biāo)識(shí)。為防止128比特的UATI在空中傳輸，Sector的子網(wǎng)地址由8比特的ColorCode標(biāo)識(shí)，這樣空中接口只需要傳輸8比特的ColorCode和24比特的UATI就可以標(biāo)識(shí)AT;(7)AN分配UATI的低24位比特,和UATIRequest消息收到的Sector對(duì)應(yīng)的8比特ColorCode合成一個(gè)32比特的UATI,并在控制信道向AT發(fā)送UATIAssignment消息，該消息仍然使用RATI作為AT標(biāo)識(shí)，同時(shí)開(kāi)始等待AT發(fā)送UATIComplete；(8)AT在接入信道上發(fā)送接入信道capsule，包含UATIComplete和RouteUpdate消息，capsule中的MAC地址使用新分配的UATI而不是RATI，AN記錄AT的UATI到session數(shù)據(jù)區(qū);(9)AN對(duì)收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道發(fā)送UmcACAck，使用AT接入信道capsule中MAC層header中包含的UATI標(biāo)識(shí);RouteUpdateMeesageID：AT固定設(shè)置為0x00；MessageSequence：消息的序列號(hào)，應(yīng)該比上一個(gè)RouteUpdate消息中的序列號(hào)大1，范圍為0～255；ReferencePilotPN：參考導(dǎo)頻；ReferencePilotStrength：參考導(dǎo)頻的強(qiáng)度。該值是按照－2×10×log〔PS〕向下取整計(jì)算；其中PS為參考導(dǎo)頻強(qiáng)度ReferenceKeep：假設(shè)基準(zhǔn)導(dǎo)頻的導(dǎo)頻去掉計(jì)時(shí)器已經(jīng)超時(shí)，那么該字段設(shè)置為0，指示應(yīng)去掉參考導(dǎo)頻；否那么該字段設(shè)置為1，指示應(yīng)保存參考導(dǎo)頻；NumPilots：除參考導(dǎo)頻外的導(dǎo)頻數(shù)目；PilotPNPhase：導(dǎo)頻相位，由此可以計(jì)算出導(dǎo)頻偏置；ChannelIncluded：如果此導(dǎo)頻偏置的信道與當(dāng)前的信道不同，那么設(shè)置該字段為1，否那么設(shè)置為0；所謂信道指的是頻點(diǎn)，所以在信令中看到的該字段絕大局部是0；Channel：如果ChannelIncluded字段設(shè)置為1，那么設(shè)置它為此導(dǎo)頻對(duì)應(yīng)的頻點(diǎn)，否那么將忽略這個(gè)字段。PilotStrength：和ReferencePilotStrength類(lèi)似；Keep：和ReferenceKeep類(lèi)似。AT向AN發(fā)送RouteUpdate消息，主要用于報(bào)告AT當(dāng)前的無(wú)線(xiàn)傳播環(huán)境。該消息在每次Session呼叫都會(huì)有該條消息和UATIRequest一起上報(bào)，在切換的時(shí)候，也是由AT首先上報(bào)RouteUpdate消息開(kāi)始。切換上報(bào)的RouteUpdate和Session呼叫、Connection呼叫等呼叫流程起始的RouteUpdate有一個(gè)區(qū)別：呼叫最初上報(bào)的路由更新消息中只有起呼主導(dǎo)頻的信息，而切換最初上報(bào)的消息中那么含有多個(gè)導(dǎo)頻的信息。UATIRequestAT發(fā)送UATIRequest消息請(qǐng)求AN分配一個(gè)UATI.MessageID：固定設(shè)置為0x00；TransactionID：AT每發(fā)送一次新的UATIRequest，就將該字段增加1，該字段的范圍是0～255；ACACKAN發(fā)ACAck消息，以確認(rèn)接收到接入信道的MAC層包。MessageID：AN固定設(shè)置該字段為0x00；HardwareIDRequestAN利用這條消息請(qǐng)求獲取AT的HarewareID信息。MessageID：AN固定設(shè)置為0x03；TransactionID：每發(fā)送一個(gè)新的HardwareIDRequest，該字段增加1；HardwareIDResponseAT發(fā)送這條消息響應(yīng)HardwareIDRequest消息，該消息包含AT的HardwareID信息。MessageID：AT固定設(shè)置為0x04；TransactionID：應(yīng)該設(shè)置為所對(duì)應(yīng)的HardwareIDRequeset消息的TransactionID字段；HardwareIDType：AT將根據(jù)下面這個(gè)表格來(lái)填寫(xiě)這個(gè)字段：HardwareIDLength：如果HardwareID不是0xFFFFFF，那么AT設(shè)置這個(gè)字段為HardwareIDValue的字節(jié)長(zhǎng)度，否那么設(shè)置為0；HardwareIDValue：AT設(shè)置該字段為廠商分配給AT的唯一ID。UATIAssignmentAN通過(guò)該消息為AT分配一個(gè)UATI。MessageID：固定設(shè)置為0x01；MessageSequence：每下發(fā)一個(gè)UATIAssigment，該字段固定增加1，但是需要注意的是這里說(shuō)的UATIAssignment是針對(duì)同一個(gè)AT而言的。SubnetInclued:假設(shè)該消息包含UATI104字段和UATISubnetMask字段，那么該字段置應(yīng)設(shè)為1，否那么為0UATISubnetMask：如果AT設(shè)置SubnetInclued為0，那么忽略該字段；如果AT設(shè)置SubnetInclued為1,包含該字段，那么AN應(yīng)設(shè)置該字段為分配的UATI所屬的子網(wǎng)掩碼中連續(xù)1的個(gè)數(shù)。UATI104:如果AT設(shè)置SubnetInclued為0，那么忽略該字段；如果AT設(shè)置SubnetInclued為1,包含該字段，那么AN應(yīng)設(shè)置該字段為分配給AT的UATI的UATI[127:24]UATIColorCode：UATI顏色碼。AN應(yīng)設(shè)置該字段為UATI所屬子網(wǎng)對(duì)應(yīng)的顏色碼。UATI024:AN設(shè)置該字段為分配給AT的UATI的UATI[23:0].UpperOldUATILength：AN設(shè)置該字段為將在UATIComplete消息中發(fā)送OldUATI[127:24]從最低有效位開(kāi)始的字節(jié)數(shù)目。UATICompleteAT發(fā)送該消息證實(shí)收到的UATIAssignment消息。MessageID：固定設(shè)置為0x02；MessageSequence：設(shè)置為所對(duì)應(yīng)的UATIAssignment的MessageSequence字段；UpperOldUATILength:AT設(shè)置該字段為UpperOldUATI的字節(jié)長(zhǎng)度。UpperOldUATI：假設(shè)此消息所確認(rèn)的UATIAssignment消息中的UpperOldUATILength非零，并且OldUATI不為NULL，那么接入終端設(shè)置該字段為OldUATI[23+UpperOldUATILength*8:24]具體例子上圖是一個(gè)QXDM記錄完整的Session建立流程。RouteUpdate該條信令的具體實(shí)例見(jiàn)切換控制流程中的實(shí)例UATIRequest首先AT發(fā)起UATIRequest消息，請(qǐng)求AN分配UATI。從該條消息可以獲取以下信息：transaction_id=12,說(shuō)明在該消息之前，已經(jīng)發(fā)送過(guò)11條不同的UATIRequest消息。ACAckAN發(fā)送該消息證實(shí)接收到接入信道的MAC層包HardwareIDRequestAN發(fā)送該消息請(qǐng)求獲取AT的HardwareID，以便作為AN計(jì)算UATI的參考。從這條信令可以看出，transaction_id=0,說(shuō)明該消息是第一次發(fā)送HardwareIDRequest消息，并且可以推斷后面的HardwareIDResponse的transaction_id也為0。HardwareIDReponse該消息攜帶HarewareID的信息，從這條信令可以看出，hardware_id_length=4，hardware_id共4個(gè)字節(jié)；由于所對(duì)應(yīng)的HardwareIDRequest中的TransactionID為0，所以本消息中這個(gè)字段也為0。Hardware_id_type值設(shè)置為0x10000，說(shuō)明hardward_id屬于ESN類(lèi)型。UATIAssignment該消息為AT分配UATI，從信令中看到sub_net_included設(shè)置為0，說(shuō)明不包含UATI104和SubnetMask兩個(gè)字段；UATIColorCode設(shè)置為5，說(shuō)明UATI所屬子網(wǎng)的顏色碼為5；uati_024=196717(0x3006d),此字段的值為AN所分配的低24位的UATI的值，UpperOldUATILength為0；message_sequence=0，可以推斷出后面的UATIComplete的message_sequence也為0。UATIComplete本消息為UATIAssignment消息的應(yīng)答消息。由于所對(duì)應(yīng)的UATIAssignment消息中MessageSequence為0，所以本消息中也設(shè)置該字段為0；由于上條消息中UpperOldUATILength設(shè)置為0，所以本消息中該字段也設(shè)置為0。Session釋放AT在接入信道發(fā)起Session釋放流程介紹過(guò)程過(guò)程描述aAT在接入信道上發(fā)送接入信道capsule，包含UmaSessionClose和UmaRouteUpdate消息。bS_CES對(duì)收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道發(fā)送UmcACAck，使用AT接入信道capsule中MAC層header中包含的UATI標(biāo)識(shí)。S_BSSAP向PCF發(fā)送A9UpdateA8消息，請(qǐng)求釋放A10連接。cS_PCF判斷是否存在A10連接，如果存在，那么向PDSN發(fā)送A11RegistrationRequest，請(qǐng)求釋放A10連接dPDSN向S_PCF發(fā)送A11RegistrationReply，接受A10釋放請(qǐng)求。ePCF向S_BSSAP發(fā)送A9UpdateA8Ack，確認(rèn)釋放A10連接。S_BSSAP去除AT的session數(shù)據(jù)。該流程可簡(jiǎn)化為：(1)AT在接入信道發(fā)起Session釋放，首先在接入信道上發(fā)送SessionClose和RouteUpdate消息的capsule；(2)AN對(duì)收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道發(fā)送ACAck，使用AT接入信道capsule中MAC層header中包含的UATI標(biāo)識(shí)。(3)釋放A10連接AT在業(yè)務(wù)信道發(fā)起Session釋放流程介紹過(guò)程過(guò)程描述aAT在反向業(yè)務(wù)信道發(fā)送UmrSessionClose消息〔沒(méi)有UmaRouteUpdate〕，請(qǐng)求關(guān)閉session。bS_SP發(fā)送AvrConnectionRelease消息給S_BSSAP，通知S_BSSAP開(kāi)始釋放相應(yīng)資源。同時(shí)S_SP向S_RCP發(fā)送AbiscfConnectionRelease，請(qǐng)求釋放無(wú)線(xiàn)資源，并開(kāi)啟定時(shí)器Tabiscconnectionrelease。如果Tabiscconnectionrelease超時(shí)，S_SP去除通道表。cS_BSSAP發(fā)送AvfConnectionReleaseAck給S_SP，確認(rèn)收到通知，并開(kāi)啟定時(shí)器Tconnectionrelease，等待AvrConnectionReleaseComplete。如果Tconnectionrelease超時(shí)，S_BSSAP發(fā)起連接終止。S_RCP發(fā)送AmfConnectionRelease給S_CES，釋放前反向信道單元。dS_BSSAP發(fā)送A9ReleaseA8給PCF，啟動(dòng)釋放A8連接和A10連接。S_CES發(fā)送AmrConnectionReleaseAck給S_RCP，確認(rèn)釋放完成。ePCF向PDSN發(fā)送A11RegistrationRequest請(qǐng)求釋放A10連接。S_RCP發(fā)送AbiscrConnectionReleaseAck給S_SP，確認(rèn)無(wú)線(xiàn)資源已經(jīng)釋放。fS_SP發(fā)送AvrConnectionReleaseComplete給S_BSSAP，帶有session關(guān)閉指示,完成釋放，S_BSSAP釋放分配的選擇器和CallRefId，停止定時(shí)器Tconnectionrelease，去除AT的session數(shù)據(jù)。gPDSN向PCF發(fā)送A11RegistrationReply，確認(rèn)釋放A10連接。S_SP調(diào)用S_FSP的Deactive函數(shù)，通知FSP停止幀選擇和分發(fā)處理。hPCF向S_BSSAP發(fā)送A9ReleaseA8Complete，確認(rèn)A8連接已經(jīng)釋放。S_SP調(diào)用S_TP的Deactive函數(shù)，通知TP停止業(yè)務(wù)數(shù)據(jù)處理。該流程可簡(jiǎn)化為：(1)AT在業(yè)務(wù)信道上發(fā)起Session釋放，首先在反向業(yè)務(wù)信道上發(fā)送SessionClose消息，請(qǐng)求關(guān)閉session；(2)AN釋放無(wú)線(xiàn)資源、A8、A10連接(3)AN關(guān)閉session，去除AT的session數(shù)據(jù)區(qū)。AN發(fā)起Session釋放-Session配置失敗流程介紹過(guò)程過(guò)程描述aS_SP和AT的session協(xié)商失敗，啟動(dòng)連接釋放，通過(guò)控制信道向AT發(fā)送UmfSessionClose消息。由于AT是否回UmrSessionClose不會(huì)影響后續(xù)流程，所以S_SP不設(shè)定時(shí)器bS_SP收到AT在接入信道上發(fā)送的UmrSessionClose消息。cS_SP發(fā)送AvrConnectionRelease消息給S_BSSAP，通知S_BSSAP開(kāi)始釋放相應(yīng)資源。同時(shí)S_SP向S_RCP發(fā)送AbiscfConnectionRelease，請(qǐng)求釋放無(wú)線(xiàn)資源，并開(kāi)啟定時(shí)器Tabiscconnectionrelease。如果Tabiscconnectionrelease超時(shí)，S_SP去除通道表。dS_BSSAP發(fā)送AvfConnectionReleaseAck給S_SP，確認(rèn)收到通知，并開(kāi)啟定時(shí)器Tconnectionrelease，等待AvrConnectionReleaseComplete。如果Tconnectionrelease超時(shí)，S_BSSAP發(fā)起連接終止。S_RCP發(fā)送AmfConnectionRelease給S_CES，釋放前反向信道單元。eS_BSSAP發(fā)送A9ReleaseA8給PCF，啟動(dòng)釋放A8連接和A10連接。S_CES發(fā)送AmrConnectionReleaseAck給S_RCP，確認(rèn)釋放完成。fPCF向PDSN發(fā)送A11RegistrationRequest請(qǐng)求釋放A10連接。S_RCP發(fā)送AbiscrConnectionReleaseAck給S_SP，確認(rèn)無(wú)線(xiàn)資源已經(jīng)釋放gS_SP發(fā)送AvrConnectionReleaseComplete給S_BSSAP，帶有session關(guān)閉指示,完成釋放，S_BSSAP釋放分配的選擇器和CallRefId，停止定時(shí)器Tconnectionrelease，去除AT的session數(shù)據(jù)hPDSN向PCF發(fā)送A11RegistrationReply，確認(rèn)釋放A10連接。S_SP調(diào)用S_FSP的Deactive函數(shù)，通知FSP停止幀選擇和分發(fā)處理iPCF向S_BSSAP發(fā)送A9ReleaseA8Complete，確認(rèn)A8連接已經(jīng)釋放。S_SP調(diào)用S_TP的Deactive函數(shù)，通知TP停止業(yè)務(wù)數(shù)據(jù)處理該流程可簡(jiǎn)化為：(1)AN和AT的session協(xié)商失敗，啟動(dòng)連接釋放,通過(guò)控制信道向AT發(fā)送SessionClose消息,請(qǐng)求session關(guān)閉;(2)AN收到AT在接入信道上發(fā)送的SessionClose消息,開(kāi)始釋放無(wú)線(xiàn)資源、A8、A10連接(3)AN關(guān)閉session，去除AT的session數(shù)據(jù)SessionClose發(fā)送方發(fā)送SessionClose消息來(lái)結(jié)束SessionMessageID：固定設(shè)置為0x01;CloseReason：發(fā)送方按下表設(shè)置Close的原因MoreInfoLen：MoreInfo字段的字節(jié)長(zhǎng)度；MoreInfo：關(guān)閉的附加信息，該字段的格式取決于具體的關(guān)閉原因具體例子上圖是一個(gè)QXDM記錄完整的AN發(fā)起Session釋放-Session配置失敗流程。SessionClose從上面的信令可以看出，close_reason=5(0x5)(SessionConfigurationFailure)，說(shuō)明session關(guān)閉的原因是session配置失敗。SessionClose從上面的信令來(lái)看，close_reason=1(0x1)(CloseReply)，說(shuō)明SessionClose消息中關(guān)閉的原因是關(guān)閉響應(yīng)，即響應(yīng)上一條的由于session配置失敗的SessionClose消息Session協(xié)商流程介紹上面顯示的Session進(jìn)行協(xié)商的流程，在此之前是完整的Session建立流程和Connetion建立流程，見(jiàn)本文中的和。本局部流程中的具體操作如下：過(guò)程過(guò)程描述aAT發(fā)起Connetion建立b如果在AvfConnetionSetup消息中指示進(jìn)行協(xié)議協(xié)商，S_SP發(fā)送UmrConfigurationStart給AT。c開(kāi)始協(xié)商第一個(gè)personnality(也稱(chēng)為mainpersonality，personalityIndexStore=0)。Mainpersonality是一個(gè)Release0personality。AT發(fā)送UmrConfigurationRequest消息，協(xié)議類(lèi)型為SCP，UmrConfigurationRequest中包含AT所支持的所有非缺省Protocolsubtypes(HardLinksubtype除外，因?yàn)樗衟rotocols均支持HardLinksubtype)。協(xié)商進(jìn)入AT啟動(dòng)階段dS_SP發(fā)送UmfConfiguratonResponse消息，協(xié)議類(lèi)型為SCP，確認(rèn)或提議新的協(xié)議參數(shù)。由于mainpersonality是一個(gè)Release0personality，S_SP選擇缺省物理層、缺省FTCMAC和缺省RTCMACe-fAT發(fā)起StreamProtocol的協(xié)商g-jAT發(fā)起其它procotolsubtype協(xié)商kAT完成需要協(xié)商的協(xié)議參數(shù)以后，發(fā)送UmrConfigurationComplete，結(jié)束協(xié)商AT的啟動(dòng)階段l-m如果AN需要繼續(xù)進(jìn)行協(xié)商，S_SP發(fā)送UmrConfigurationRequest消息，協(xié)議類(lèi)型為SCP，協(xié)商進(jìn)入AN啟動(dòng)階段。n-oAN發(fā)起StreamProtocol的協(xié)商，以協(xié)商出綁定在RAN上的缺省分組的應(yīng)用p-sAN發(fā)起其它procotolsubtype協(xié)商t-w如果在前面協(xié)商中指定使用Key交換協(xié)議，那么進(jìn)入Key交換過(guò)程。xAN和AT完成mainpersonality協(xié)商后，S_SP通過(guò)UmfSoftConfigurationComplete中continue=1字段通知AT開(kāi)始下一個(gè)personality的協(xié)商，除mainpersonality是唯一的一個(gè)Release0personality外，其余的personalities均為RevApersonalityyAT選擇那些在協(xié)商mainpersonality時(shí)AT曾發(fā)起過(guò)協(xié)商的protocols，向AN推薦HardLinksubtype。采用這樣的策略，AT可以防止再對(duì)這些protocols進(jìn)行不必要的協(xié)商。z由于當(dāng)前協(xié)商的是一個(gè)RevApersonality，所以AN選擇物理層ST2，增強(qiáng)型FTCMAC和RTCMACST3。aa-bbAT發(fā)起StreamProtocol的協(xié)商cc-hhAT發(fā)起其他protocolsubtype的協(xié)商iiAT完成需要協(xié)商的協(xié)議參數(shù)后，發(fā)送UmrConfigurationComplete，結(jié)束協(xié)商的AT啟動(dòng)階段jj-kk如果AN需要繼續(xù)進(jìn)行協(xié)商，S_SP發(fā)送UmfConfigurationRequest，協(xié)議類(lèi)型為SCPll-mmAN發(fā)起StreamProtocol的協(xié)商nn-uuAN發(fā)起其他protocolsubtype的協(xié)商vv第二個(gè)personality協(xié)商完閉后，S_SP通過(guò)UmfSoftConfigurationComplete中Continue=0通知AT不必進(jìn)行其他personality的協(xié)商。同時(shí)，如果當(dāng)前活動(dòng)集中只有CHM6800的導(dǎo)頻，S_SP把UmfSoftConfigurationComplete中的SessionConfigurationToken的高4bit置為1〔即通知AT使用RevApersonality〕；否那么置為0〔即通知AT使用Rev0personality〕wwAT發(fā)送UmrSLPAck，確認(rèn)收到UmfSoftConfigurationCompletexxS_SP向S_BSSAP發(fā)送AvrSessionConfigurationComplete，把當(dāng)前協(xié)商后的協(xié)議配置參數(shù)發(fā)送給S_BSSAPyyS_SP啟動(dòng)連接關(guān)閉，發(fā)送UmfConnectionClose消息。該流程較為復(fù)雜，對(duì)該流程的梳理，詳細(xì)見(jiàn).7的介紹。ConfigurationStart該條消息用于提示開(kāi)始session協(xié)商的流程，該消息的內(nèi)容比擬簡(jiǎn)單，只有一個(gè)域MessageID，固定設(shè)置為0x01，該消息是由AN發(fā)送給AT的，一旦AN發(fā)出該消息，那么AT和AN的會(huì)話(huà)配置協(xié)議狀態(tài)都應(yīng)該跳轉(zhuǎn)到“AT始發(fā)〞狀態(tài)。在會(huì)話(huà)配置協(xié)議中共有四種狀態(tài)：非激活狀態(tài)：此狀態(tài)下，等待Activate命令。AT始發(fā)狀態(tài)：此狀態(tài)下，協(xié)商由接入終端發(fā)起。AN始發(fā)狀態(tài)：此狀態(tài)下，協(xié)商由AN發(fā)起。開(kāi)狀態(tài)：此狀態(tài)下，AT可以在任何時(shí)間啟動(dòng)會(huì)話(huà)配置過(guò)程，AN可以在任何時(shí)間請(qǐng)求AT始發(fā)會(huì)話(huà)配置。對(duì)于四個(gè)狀態(tài)之間的轉(zhuǎn)換可以結(jié)合下面的狀態(tài)機(jī)來(lái)看，也可以了解為什么流程圖中是AT先進(jìn)行協(xié)商等。下列圖為AT側(cè)會(huì)話(huà)配置協(xié)議狀態(tài)圖。剛開(kāi)始AT側(cè)是處于Inactive狀態(tài)，當(dāng)觸發(fā)以下條件時(shí)，將進(jìn)行狀態(tài)轉(zhuǎn)化觸發(fā)進(jìn)入Inactive狀態(tài)的條件：AT始發(fā)、AN始發(fā)、OPEN三種狀態(tài)，AT收到Deactive命令；觸發(fā)進(jìn)入OPEN狀態(tài)的條件：(1)Inactive狀態(tài)下，AT收到active命令；〔2〕AN始發(fā)狀態(tài)下，AT收到ComfigurationComplete消息，結(jié)束AN側(cè)的始發(fā)協(xié)商過(guò)程；或者AT收到SoftconfigurationComplete消息攜帶Continue字段為0，不需要進(jìn)行下一個(gè)Personality的協(xié)商。；觸發(fā)進(jìn)入AT始發(fā)狀態(tài)的條件：〔1〕OPEN狀態(tài)下，AT收到ConfigurationStart，開(kāi)始協(xié)商過(guò)程；或者AT發(fā)送ConfigurationRequest消息；或者AT發(fā)送任何InConfiguration消息；(2)AN始發(fā)狀態(tài)下，AT收到SoftConfigurationComplete消息攜帶Continue字段為1，需要進(jìn)行下一個(gè)Personality的協(xié)商。觸發(fā)進(jìn)入AN始發(fā)狀態(tài)的條件：〔1〕AT始發(fā)狀態(tài)下，AT發(fā)送ConfigurationComplete，結(jié)束AT側(cè)的始發(fā)協(xié)商過(guò)程；下列圖為AN側(cè)會(huì)話(huà)配置協(xié)議狀態(tài)圖：剛開(kāi)始AN側(cè)是處于Inactive狀態(tài)，當(dāng)觸發(fā)以下條件時(shí)，將進(jìn)行狀態(tài)轉(zhuǎn)化觸發(fā)進(jìn)入Inactive狀態(tài)的條件：AT始發(fā)、AN始發(fā)、OPEN三種狀態(tài)，AN收到Deactive命令。觸發(fā)進(jìn)入OPEN狀態(tài)的條件：〔1〕Inactive狀態(tài)下，AN收到active命令；〔2〕AN始發(fā)狀態(tài)下，AN發(fā)送ComfigurationComplete消息，結(jié)束AN側(cè)的始發(fā)協(xié)商過(guò)程；或者AN發(fā)送SoftconfigurationComplete消息攜帶Continue字段為0，不需要進(jìn)行下一個(gè)Personality的協(xié)商。；觸發(fā)進(jìn)入AT始發(fā)狀態(tài)的條件：1〕OPEN狀態(tài)下，AN發(fā)送ConfigurationStart，開(kāi)始協(xié)商過(guò)程；或者AN接收ConfigurationRequest消息；或者AN接收任何InConfiguration消息；(2)AN始發(fā)狀態(tài)下，AN發(fā)送SoftConfigurationComplete消息攜帶Continue字段為1，需要進(jìn)行下一個(gè)Personality的協(xié)商。觸發(fā)進(jìn)入AN始發(fā)狀態(tài)的條件：〔1〕AT始發(fā)狀態(tài)下，AN接收ConfigurationComplete，結(jié)束AT側(cè)的始發(fā)協(xié)商過(guò)程；比照上述兩個(gè)狀態(tài)圖，其實(shí)AT側(cè)的狀態(tài)轉(zhuǎn)化圖和AN側(cè)的狀態(tài)轉(zhuǎn)化圖是一一對(duì)應(yīng)的，有兩種情況將回到AT的始發(fā)狀態(tài)：(1)每次AN始發(fā)狀態(tài)，AT收到或者AN發(fā)送SoftConfigurationComplete攜帶Continue字段為1，都將回到AT的始發(fā)狀態(tài)；(2)每次AN始發(fā)狀態(tài)，AT接收或AN發(fā)送ConfigurationComplete，或者AT接收或AN發(fā)送SoftConfigurationComplete攜帶Continue字段為0，狀態(tài)都將轉(zhuǎn)化為OPEN狀態(tài)；從OPEN狀態(tài)，AT接收或AN發(fā)送ConfigurationStart，或者AT發(fā)送或AN接收ConfigurationRequest，或者AT接收或AN發(fā)送任何Inconfiguration的消息，狀態(tài)都將回到AT的始發(fā)狀態(tài)；因此這可以解釋為什么流程圖中是AT先進(jìn)行協(xié)商等ConfigurationRequest在這里需要介紹一下屬性記錄〔AttributeRecord〕這個(gè)概念。它為給定屬性定義一套建議值，屬性記錄格式被定義，可以使得接收方不能識(shí)別此屬性，那么它也能夠丟棄它并分析此記錄隨后的屬性記錄。一個(gè)屬性可以是以下三類(lèi)中的一種：簡(jiǎn)單屬性：假設(shè)屬性記錄中只包含單個(gè)值；屬性列表：假設(shè)屬性記錄包含多種單個(gè)值，它們被解釋為相同屬性標(biāo)志符的不同建議值；〔如：相同協(xié)議類(lèi)型的可能協(xié)議子類(lèi)型列表〕綜合屬性：如果屬性記錄中包含多種單個(gè)值，這些值一起形成一個(gè)特定屬性標(biāo)志符的綜合值；單個(gè)屬性和屬性列表的格式如下：其中Length是屬性記錄的長(zhǎng)度，單位為字節(jié)，但是不包含Length域本身；AttributeID是屬性標(biāo)志符，在正在配置的協(xié)議上下文中，屬性標(biāo)志符是唯一不變的；AttributeValue是屬性建議值，通常屬性建議值長(zhǎng)度是字節(jié)的整數(shù)倍。Reserved字節(jié)的長(zhǎng)度是使得屬性記錄字節(jié)對(duì)齊的最小值，如果發(fā)送方設(shè)置該域?yàn)?，那么接收方忽略該字段。綜合屬性的結(jié)構(gòu)如下所示：其中Length同樣是屬性記錄的長(zhǎng)度，也不包含Length域本身，但是包含ValueID域的長(zhǎng)度。ValueID是用來(lái)標(biāo)記一套屬性值的，每增加一套屬性值，ValueID就應(yīng)該增加1。其余字段含義和屬性記錄的字段含義一樣。MessageID：發(fā)送方設(shè)置該字段為Ox50;TransactionID:每發(fā)送一個(gè)新的ConfigurationRequest消息，該字段增加1；該消息攜帶一個(gè)或多個(gè)屬性記錄，并請(qǐng)求應(yīng)答方選擇一個(gè)屬性值。ConfigurationResponse應(yīng)答方發(fā)送ConfigurationResponse消息從所提供建議值列表中選擇一個(gè)屬性值。如果ConfigurationRequest中是單個(gè)屬性或者是屬性列表，那么就是直接選擇一個(gè)屬性值，如果Request消息中是一個(gè)綜合屬性，那么Response消息中就回復(fù)某一個(gè)ValueID。ConfigurationResponse消息一般要在Tumaround定時(shí)器內(nèi)回復(fù)給發(fā)送方，該定時(shí)器定義為2s。MessageID:固定設(shè)置為0x51;TransactionID:應(yīng)設(shè)置為對(duì)應(yīng)的ConfigurationRequest消息的TransactionID字段。該消息中應(yīng)答方回復(fù)一個(gè)屬性值或者ValueID給發(fā)送方，以協(xié)商確認(rèn)的協(xié)議屬性ConfigurationComplete發(fā)送方發(fā)送ConfigurationComplete消息，以指示它已經(jīng)完成它始發(fā)執(zhí)行的協(xié)商過(guò)程。MessageID：固定設(shè)置為0x00；TransactionID：AT為每個(gè)新發(fā)送的ConfigurationComplete消息增加該值，AN設(shè)置該字段為從AT接收到的上也ConfigurationComplete消息中的TransactionID值。SessionConfigurationToken：會(huì)話(huà)配置標(biāo)志。接入終端應(yīng)該忽略該域，AN包含該域，AN可以設(shè)置該域?yàn)榉从硡f(xié)商的協(xié)議和協(xié)商的參數(shù)。SoftConfigurationCompleteAN發(fā)送SoftConfigurationComplete消息，指示它已經(jīng)完成這個(gè)personality的協(xié)商過(guò)程。MessageID：固定設(shè)置為0x02;TransationID：AN應(yīng)設(shè)置該字段為從AT接收到最后一條ConfigurationComplete消息的TransationIDPersonalityIndexStore：AN設(shè)置該字段為即將保存的personalityindexContinue:如果AN需要協(xié)商更多的personality，那么AN應(yīng)設(shè)置該字段為1，否那么AN設(shè)置該字段為0；Commit：如果Continue字段設(shè)置為1，那么AN忽略該字段；否那么AN應(yīng)按照下面來(lái)設(shè)置該字段：如果Commit流程需要，AN設(shè)置該字段為1，否那么AN設(shè)置該字段為0；SessionConfigurationToken：如果Continue字段設(shè)置為1，那么AN忽略該字段；否那么AN包含該字段。如果Commit字段設(shè)置為1，那么該字段4個(gè)最高有效比特應(yīng)設(shè)置將要被提交的personalityindex，否那么4個(gè)最高有效比特應(yīng)設(shè)置成當(dāng)前正在使用的personalityindex；AN可能設(shè)置該字段的最低12個(gè)最低有效比特的值，以反映協(xié)商過(guò)程中所選擇的協(xié)議和協(xié)商的參數(shù)具體例子結(jié)合上述的Request和Response消息的格式以及最初的流程介紹，可以看一個(gè)比擬完整的Session配置實(shí)例,由于該流程較長(zhǎng)，分兩局部截屏。第一局部截屏從ConfigurationStart消息到出現(xiàn)第一條SoftConfigurationComplete，AT和AN完成完成了Release0personality的協(xié)商，此協(xié)商分AT始發(fā)階段的協(xié)商和AN始發(fā)階段的兩局部的協(xié)商。第二局部截屏從ConfigurationRequest消息到出現(xiàn)第二條SoftConfigurationComplete消息，AT和AN完成了RevApersonality的協(xié)商，此協(xié)商同樣也分AT始發(fā)階段的協(xié)商和AN始發(fā)階段的兩局部的協(xié)商。從實(shí)例上看，首先進(jìn)行的是Release0personality的協(xié)商，在這局部先進(jìn)行的是AT始發(fā)階段協(xié)商(即AT在反向業(yè)務(wù)信道上發(fā)送ConfigurationRequest消息，前向業(yè)務(wù)信道上應(yīng)答ConfigurationResponse消息)，AT始發(fā)階段分別進(jìn)行了Stream、RouteUpdate、Stream2MultiflowPacketApplication(即MPAStream2)等協(xié)議的協(xié)商，接著由AT發(fā)送ConfigurationComplete消息開(kāi)始AN始發(fā)階段協(xié)商，AN始發(fā)階段分別進(jìn)行Stream、FTCMAC、RTCMAC、RouteUpdate、AddressManagement、DefaultStream2等協(xié)議的協(xié)商。AN發(fā)送SoftConfigurationComplete開(kāi)始進(jìn)入RevApersonality的協(xié)商，在這局部先進(jìn)行的也是AT始發(fā)階段協(xié)商，AT始發(fā)階段分別進(jìn)行Stream、RouteUpdate、RTCMAC、MPAStream2等協(xié)議的協(xié)商，同樣也是由AT發(fā)送ConfigurationComplete消息開(kāi)始AN始發(fā)階段協(xié)商，AN始發(fā)階段分別進(jìn)行了Stream、ControlChannelMAC、AccessChannelMAC、RTCMAC、MPAStream2等協(xié)議的協(xié)商。ConfigurationStartAN發(fā)出該條信令以后，即開(kāi)始session的協(xié)商過(guò)程。ConfigurationRequest〔AT側(cè)發(fā)起協(xié)商〕首先進(jìn)行的是Release0的協(xié)商，先進(jìn)行的是AT始發(fā)階段協(xié)商，AT在反向上發(fā)送ConfigurationRequest消息，分別進(jìn)行了Stream、RouteUpdate、Stream2MultiflowPacketApplication等協(xié)議協(xié)商，這里以Stream協(xié)議協(xié)商為例。從上圖看到這里使用的是綜合屬性，protocol_type＝0x13，說(shuō)明是流層的配置協(xié)商，提供了兩套屬性建議值，stream_config[0]和stream_config[1]，這兩套屬性建議值分別用value_id=0和value_id=1進(jìn)行編號(hào)，以便在ConfigurationResponse消息中使用value_id進(jìn)行確認(rèn)選擇的屬性。ConfigurationResponse〔AT側(cè)發(fā)起的協(xié)商〕AN對(duì)AT發(fā)送的關(guān)于Stream協(xié)議協(xié)商的ConfigurationRequest消息進(jìn)行應(yīng)答，從信令可以看到此消息的Transation_id=12，對(duì)應(yīng)的ConfigurationRequest的Transation_id也為12，說(shuō)明此消息是對(duì)上一條ConfigurationRequest的應(yīng)答，從信令中可以看到，AN采用的是value_id=0的一套建議值。ConfigurationComplete通過(guò)這條消息，進(jìn)入了AN始發(fā)階段協(xié)商。這里TransactionID設(shè)置為12，所以可以推斷AN等會(huì)發(fā)送的SoftConfigurationComplete消息中該域也是12。由于是AT始發(fā)，所以token_incl=0，沒(méi)有Token域。ConfigurationRequest〔AN側(cè)始發(fā)〕AN始發(fā)階段分別進(jìn)行Stream、FTCMAC、RTCMAC、RouteUpdate、AddressManagement、DefaultStream2等協(xié)議的協(xié)商。這里以Stream協(xié)議協(xié)商為例。通過(guò)上述的內(nèi)容，AN提供了value_id=0的一套建議值ConfigurationResponse〔AN側(cè)始發(fā)〕從這條消息可以看出，AT選擇的valud_id=0的一套建議值，其中該消息的transaction_id等于前面的流層的ConfigurationRequest消息的transaction_idSoftConfigurationComplete〔AN側(cè)發(fā)送〕這里TransactionID等于前面AT發(fā)出的ConfigurationComplete消息中的TransactionID。Personality_index_store=0說(shuō)明該條消息即將保存personalityindex為0的personality；cont=1,說(shuō)明AN希望協(xié)商更多的personality，即開(kāi)始RevApersonality的協(xié)商。RevApersonlity協(xié)商在RevApersonality的協(xié)商過(guò)程和Rls0personality的協(xié)商過(guò)程類(lèi)似，也出現(xiàn)各協(xié)議的ConfigurationRequest消息和ConfigurationResponse消息的交互，以及ConfigurationComplete消息結(jié)束AT或AN的始發(fā)階段，SoftConfigurationComplete消息結(jié)束personality的協(xié)商。其信令的內(nèi)容根本類(lèi)似，因此不再獒述。Session協(xié)商過(guò)程結(jié)束后，即開(kāi)始進(jìn)入Connetion釋放流程，具體見(jiàn)后面詳細(xì)描述。Connection呼叫流程Connection建立AT發(fā)起的Connection建立流程介紹以上是AT發(fā)起的Connection建立流程。其中從AT發(fā)出ConnectionRequest到移動(dòng)臺(tái)發(fā)出TrafficChannelComplete為一個(gè)階段，該階段的主要工作是分配資源、捕獲空中前反向信道等，涉及的空口信令主要操作如下：過(guò)程過(guò)程描述aAT在接入信道上發(fā)送接入信道capsule，包含UmaConnectionRequest和UmaRouteUpdate消息，每次AT在接入信道上發(fā)送包，總會(huì)包含UmaRouteUpdate消息，該消息包含了AT以當(dāng)前時(shí)間為基準(zhǔn)的參考導(dǎo)頻和強(qiáng)度足夠的其它導(dǎo)頻，作為當(dāng)前無(wú)線(xiàn)鏈路狀態(tài)報(bào)告。該capsule由S_CES透明傳送給S_BSSAP，S_CES接入信道解調(diào)單元還將估計(jì)AT到sector的往返延時(shí)RoundTripDelay，和接入信道capsule一起發(fā)送給S_BSSAP。bS_CES對(duì)收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道發(fā)送UmcACAck，使用AT接入信道capsule中MAC層header中包含的UATI標(biāo)識(shí)。S_BSSAP分析收到的接入信道capsule，發(fā)現(xiàn)是UmaConnectionRequest消息，并且UATI對(duì)應(yīng)一個(gè)已經(jīng)存在的session，分配空閑的選擇器，分配呼叫參考號(hào)，發(fā)送AvfConnectionSetup給分配的選擇器對(duì)應(yīng)的S_SP進(jìn)程，開(kāi)啟定時(shí)器T_ConnSetup。該消息包含S_SP進(jìn)行后續(xù)呼叫處理的足夠信息，包括：呼叫參考號(hào)CallRefId；AT的標(biāo)識(shí)ATI；AT的session配置信息〔參考各協(xié)議的配置參數(shù)。如果session已經(jīng)配置，那么包含該信息〕；UmaRouteUpdate消息中包含的所有導(dǎo)頻及對(duì)應(yīng)的小區(qū)；是否需要進(jìn)行session的配置〔如果需要，還要包含session的配置參數(shù)〕；是否需要接入鑒權(quán)；是否需要位置更新〔如果需要，還要包含SID，NID，PZID等位置參數(shù)〕。cS_SP從UmaRouteUpdate消息中挑選一個(gè)PN，并構(gòu)造AbiscfConnectionSetup消息發(fā)給該小區(qū)所在BTS的S_RCP模塊，請(qǐng)求分配載頻資源、幀偏置、前反向信道單元和MACIndex，開(kāi)啟定時(shí)器T_AbiscConnectionSetup。AbiscfConnectionSetup消息包括的信息有：CallRefId、AT的相關(guān)Session信息〔包括MNID、ATI、HardwareID、物理層協(xié)議子類(lèi)型、ReverseRateLimit、FTCMAC層的配置參數(shù)DRCGating，DRCLockLength，DRCLockPeriod等；還包括了專(zhuān)用于CHM6800的MultiUserPacketsEnabled、ShortPacketsEnabledThresh、NullRateDRC38Dot4Enable、ARQMode、TransmissionMode、DataChannelPowerParameters、RRIChannelPowerParameters等參數(shù)；最后還會(huì)包含ATSupportedCDMAChannels〔用于限定數(shù)據(jù)庫(kù)分配載頻資源的范圍〕，并有可能包含AT指定在其上建立業(yè)務(wù)信道的PreferredCDMAChannels信息。dS_RCP請(qǐng)求數(shù)據(jù)庫(kù)分配前反向業(yè)務(wù)信道單元，分配載頻Channel〔一定要在AT支持的信道記錄范圍內(nèi)分配，如果AT同時(shí)指定了PreferredCDMAChannels，還必須進(jìn)一步在這個(gè)范圍內(nèi)分配載頻資源，一旦分配失敗，那么返回連接建立失敗〕，分配CE幀偏置，通過(guò)消息AmfConnectionSetup發(fā)送前反向信道單元的配置信息給S_CES。包括的信息有：CallRefId、SetupLegInfo、FrameOffset；DRCLength；包含F(xiàn)TCMAC層參數(shù)DRCGating、DRCLockLength、DRCLockPeriod等在內(nèi)的ATParameter；前反向信道單元的IP地址和端口號(hào)等等。S_RCP發(fā)送消息AmfConnectionSetup的同時(shí)，會(huì)啟動(dòng)定時(shí)器Tconnectionsetup等待應(yīng)答。eS_RCP同時(shí)向駐留在DSM上的IGWP模塊發(fā)送AcfBTSAddChannelItem消息，請(qǐng)求增加通道表；同時(shí)啟動(dòng)定時(shí)器Taddchannel等待應(yīng)答。fS_CES配置分配的前反向信道單元，成功后返回AmrConnectionSetupAck給S_RCP，并包含driver所分配的MACIndex，以及信令流的TrafficflowId和信令流流控窗口大小。g駐留在DSM上的IGWP模塊發(fā)送AcrBTSAddChannelItemAck消息給S_RCP，確認(rèn)成功添加通道表，S_RCP收到后停止定時(shí)器Taddchannel。hS_RCP成功分配所要求的無(wú)線(xiàn)資源、配置前反向信道單元并成功添加BTS側(cè)的通道表之后，向S_SP返回AbiscrConnectionSetupAck消息。S_SP收到后停止定時(shí)器T_AbiscConnectionSetup，然后再次查找UmaRouteUpdate消息，如果還有其他keep為１且包含當(dāng)前已分配載頻的PN，那么為這些PN構(gòu)造AbiscfConnectionSetup消息并發(fā)到這些小區(qū)所在BTS的S_RCP模塊，即重復(fù)c-f的步驟，會(huì)再次開(kāi)啟定時(shí)器T_AbiscConnectionSetup。如果第一次分配資源后沒(méi)有其他小區(qū)需要再次分配資源，或者有其他小區(qū)需要分配資源且S_SP已經(jīng)接收完所有小區(qū)的連接建立應(yīng)答消息，那么停止定時(shí)器T_AbiscConnectionSetup并繼續(xù)后面的流程；如果第一個(gè)T_AbiscConnectionSetup超時(shí)，那么連接建立失敗，向AT發(fā)送UmcConnectionDeny消息，并啟動(dòng)相應(yīng)的資源釋放流程，如果啟動(dòng)了第二個(gè)T_AbiscConnectionSetup定時(shí)器且該定時(shí)器超時(shí)時(shí)還有未收到確認(rèn)的小區(qū)，那么不做異常處理，繼續(xù)后面的流程，在后續(xù)流程中只使用已經(jīng)成功分配資源的小區(qū)。i-jS_SP接收所有小區(qū)的AbiscrConnectionSetupAck消息后，確定將要為該連接效勞的活動(dòng)集腿數(shù)SoftHandoffCount，根據(jù)這個(gè)信息查找公共數(shù)據(jù)區(qū)〔該公共數(shù)據(jù)區(qū)由駐留在HSDU上的RSPAux進(jìn)程負(fù)責(zé)維護(hù)〕，獲取必要的配置信息，包括DRCLength，DRCChannelGain，AckChannelGain，DSCChannelGain〔這幾個(gè)參數(shù)是SoftHandoffCount的函數(shù)，SoftHandoffCount取值1~6，分別對(duì)應(yīng)有不同的配置〕，DRCErasureThreshold參數(shù)〔6X6的數(shù)組，E(x,y)是AT的SoftHandoffCount由x躍遷到y(tǒng)時(shí)的刪除門(mén)限，E(y,y)是躍遷到y(tǒng)完成后的刪除門(mén)限〕等等，構(gòu)造消息AbiscfSetDRCAndAckInfo發(fā)給所有分配無(wú)線(xiàn)資源的CES反向信道單元RXC，構(gòu)造消息AbiscfSetDRCLengthTransition發(fā)給所有分配無(wú)線(xiàn)資源的CES前向信道單元FTC，前向鏈路使用SoftHandoffCount幫助確定RPC信道反向功控比特的功率分配，反向鏈路使用SoftHandoffCount作為反向功控算法的因子。DRCAndAckInfo提供反向鏈路適當(dāng)?shù)慕庹{(diào)性能。S_SP同時(shí)根據(jù)當(dāng)前活動(dòng)集構(gòu)造消息AvrNeighborListRequired給S_BSSAP，請(qǐng)求獲得活動(dòng)集中所有PN的鄰區(qū)信息；S_SP同時(shí)根據(jù)當(dāng)前活動(dòng)集構(gòu)造消息AvrBSCChItemRequired給S_BSSAP，請(qǐng)求獲得每條腿的媒體面IP地址〔在ABPM上為該腿增加通道表時(shí)需要用到該信息〕，由于連接建立時(shí)按缺省ProfileId來(lái)分配帶寬資源，需要預(yù)留的帶寬資源為０，所以無(wú)需在這條消息中包含預(yù)留帶寬的信息。S_SP在發(fā)出上述4條消息后，同時(shí)開(kāi)啟3個(gè)定時(shí)器：T_DRCAndAckInfo、T_AvNeighborListRequired、T_AvBSCChItemRequired等待消息接收方的應(yīng)答。k-lCES的前反向信道單元發(fā)送AbiscrSetDRCAndAckInfoAck消息和AbiscrSetDRCLengthTransitionAck消息給S_SP，確認(rèn)完成對(duì)前反向信道單元的配置。如果S_SP已收到所有前反向信道單元確實(shí)認(rèn)消息，那么停止定時(shí)器T_DRCAndAckInfo；如果T_DRCAndAckInfo超時(shí)，還有未收到確認(rèn)的腿，那么認(rèn)為連接建立失敗，向AT發(fā)送UmcConnectionDeny消息，并啟動(dòng)相應(yīng)的資源釋放流程。S_BSSAP發(fā)送AvfNeighborListUpdate給S_SP，帶回當(dāng)前活動(dòng)集對(duì)應(yīng)的所有鄰區(qū)信息。如果T_AvNeighborListRequired超時(shí)，那么認(rèn)為連接建立失敗，向AT發(fā)送UmcConnectionDeny消息，并啟動(dòng)相應(yīng)的資源釋放流程。S_BSSAP發(fā)送AvfBSCChItemRequiredAck給S_SP，帶回為每條腿分配的媒體面IP地址，如果T_AvBSCChItemRequired超時(shí)，那么同樣認(rèn)為連接建立失敗，向AT發(fā)送UmcConnectionDeny消息，并啟動(dòng)相應(yīng)的資源釋放流程。mS_SP收到AvfBSCChItemRequiredAck消息后，啟動(dòng)加通道表流程：向駐留在ABPM上的IGWP模塊發(fā)送AcfBSCAddChannelItem消息，啟動(dòng)定時(shí)器T_AddChannelItem等待應(yīng)答。n駐留在ABPM上的IGWP模塊發(fā)送AcrBSCAddChannelItemAck消息給S_SP，確認(rèn)成功添加通道表，S_SP收到后停止定時(shí)器T_AddChannelItem。o上述資源配置流程結(jié)束之后，S_SP通過(guò)內(nèi)部函數(shù)調(diào)用方式激活處于同一個(gè)RSP進(jìn)程實(shí)例的S_FSP模塊，入?yún)ㄐ谟诋?dāng)前連接的所有前反向信道單元地址、信令流Id以及信令流窗口大小等。S_FSP建立信令流的映射關(guān)系，并創(chuàng)立邏輯流信道。信令流邏輯流信道Id固定為0。pS_SP還要通過(guò)內(nèi)部函數(shù)調(diào)用方式激活處于同一個(gè)RSP進(jìn)程實(shí)例的S_TP模塊。s接下來(lái)S_SP按照協(xié)議構(gòu)造控制信道MAC分組UmcTrafficChannelAssignment發(fā)送給S_CES，由S_CES通過(guò)控制信道發(fā)送給AT。同時(shí)啟動(dòng)定時(shí)器T_ForwardDesired等待反向AT捕獲和前向DRC捕獲。tAT收到UmcTrafficChannelAssignment消息后，開(kāi)始在反向發(fā)送導(dǎo)頻和DRC。u各反向信道單元捕獲到AT發(fā)送的反向?qū)ьl和DRC，向S_SP發(fā)送AbiscrMobileAcquired消息，參數(shù)包括CallRefId和該條腿的腿號(hào)信息。反向信道單元還要把捕獲的DRC信息〔DRC值和DRCCover〕發(fā)給前向信道單元，作為前向鏈路調(diào)度算法的參數(shù)。vS_SP向所有BTS的反向信道單元RXC發(fā)送AbiscfATAcquired，通知AT已經(jīng)捕獲，請(qǐng)求將功控模式由Pattern模式改變?yōu)镹ormal模式。為防止功控模式的轉(zhuǎn)換出現(xiàn)異常，S_SP需要開(kāi)啟定時(shí)器T_ATAcquired等待應(yīng)答。w-x前向信道單元比擬收到的DRCCover和本小區(qū)分配的DRCCover，如果一致，向S_SP發(fā)送AbiscrForwardDesired消息，以指示S_SP可以通知S_FSP向本小區(qū)發(fā)送前向MAC幀。由于在之前的連接建立應(yīng)答消息中已經(jīng)把默認(rèn)翻開(kāi)的信令流流控窗口大小告知S_SP，這里不再需要發(fā)送額外的流控指示。S_SP收齊AbiscrMobileAcquired和AbiscrForwardDesired消息后，停止定時(shí)器T_ForwardDesired。yS_SP收到來(lái)自所有BTS的反向信道單元RXC的AbiscrATAcquiredAck消息后，確認(rèn)功控模式被正常修改，停止定時(shí)器T_ATAcquired。T_ForwardDesired和T_ATAcquired都被正常停止后，S_SP需要啟動(dòng)另一個(gè)定時(shí)器T_TCC等待來(lái)自AT的UmrTrafficChannelComplete消息。zS_SP分別向S_FSP和S_TP發(fā)送ConnectionOpened指示。aaS_FSP收到ConnectionOpened指示后，發(fā)送UmfRTCAck，向AT確認(rèn)已經(jīng)收到反向業(yè)務(wù)信道導(dǎo)頻和DRC，該消息使用SLP的Reliable效勞。bbS_TP收到ConnectionOpened指示后，通過(guò)調(diào)用內(nèi)部函數(shù)OpenDataFlowChannel()的方式通知S_FSP翻開(kāi)主RLP流。補(bǔ)充FSP到CES的翻開(kāi)流的消息。ccAT發(fā)送UmrTrafficChannelComplete給S_SP，消息中攜帶對(duì)UmcTrafficChannelAssignment消息的SLP層確認(rèn)。該消息使用SLP的Reliable效勞。ddS_SP發(fā)送UmfSLPAck，作為對(duì)UmrTrafficChannelComplete消息的SLP層確認(rèn)。eeS_SP發(fā)送AvrConnectionSetupAck給S_BSSAP，確認(rèn)無(wú)線(xiàn)鏈路已經(jīng)建立完成。消息參數(shù)包括CallRefId以及由S_TP模塊生成的主A8的RLPGREKey。S_BSSAP停止定時(shí)器T_ConnSetup。由于上面的流程操作描述較多，在這里做一個(gè)簡(jiǎn)單的介紹：(1)AT在接入信道上發(fā)送接入信道的Capsule，包含ConnectionRequest和RouteUpdate消息，每次AT在接入信道上發(fā)送包，總會(huì)包含RouteUpdate消息，該消息包含了參考導(dǎo)頻和強(qiáng)度足夠的其它導(dǎo)頻，作為當(dāng)前無(wú)線(xiàn)鏈路的報(bào)告.(2)AN對(duì)收到的接入信道的Capsule進(jìn)行確認(rèn)，通過(guò)控制信道發(fā)送AcAck，使用AT接入信道的Capsule中MAC層中header中包含的UATI標(biāo)識(shí).。(3)AN分析收到的接入信道Capsule，發(fā)現(xiàn)是ConnectionRequest消息，并且UATI對(duì)應(yīng)一個(gè)已經(jīng)存在的Session，那么AN開(kāi)始為RU消息里的PN分配前反向業(yè)務(wù)信道單元，分配載頻資源，分配CE幀偏置，MACindex等資源。(4)上述資源分配完成以后，AN通過(guò)控制信道向AT發(fā)送TrafficChannelAssignment消息，開(kāi)始等待反向AT捕獲和前向DRC捕獲。(5)AT收到TrafficChannelAssignment消息后，開(kāi)始在反向發(fā)送導(dǎo)頻和DRC，AN捕獲AT發(fā)送的反向?qū)ьl和DRC，開(kāi)始發(fā)送RTCAck，向AT確認(rèn)捕獲反向業(yè)務(wù)信道導(dǎo)頻和DRC，該消息使用SLP的Reliable效勞.(6)AT發(fā)送TrafficChannelComplete消息給AN，證實(shí)收到TrafficChannelAssignment消息，通知AN業(yè)務(wù)信道已經(jīng)建立完成其中RouteUpdate、ACAck等在前面已經(jīng)介紹過(guò)，下面主要介紹ConnectionRequest、TrafficChannelAssignment、ResetReport、RTCAck、TrafficChannelComplete等消息。ConnectionRequestAT發(fā)送ConectionRequest消息請(qǐng)求建立一個(gè)連接MessageID：AT固定設(shè)置該字段為0x01；TransactionID：AT每發(fā)送一個(gè)新的ConnectionRequest，該字段增加1；RequestReason：該字段為0，表示終端發(fā)起，為1，表示AN發(fā)起，此外的值是不允許的。TrafficChannelAssignmentAN發(fā)送TrafficChannelAssignment消息通知AT改變激活集MessageID：AN設(shè)置該字段為0x01；MessageSequence：消息的序列號(hào)，應(yīng)該比上一個(gè)TrafficChannelAssignment消息中的序列號(hào)大1，范圍為0～255；ChannelIncluded：同RouteUpdate消息；Channel：同RouteUpdate消息；FrameOffset：用于反向的幀偏置，RevA將一幀的時(shí)間分解成為16個(gè)幀偏置；DRCLength：申請(qǐng)一個(gè)DRC所需要的時(shí)隙，該字段設(shè)置值所對(duì)應(yīng)的時(shí)隙數(shù)如下表所示：DRCChannelGain：用于指示AT發(fā)送DRC消息時(shí)候所采用的增益；該增益是DRC信道與反向業(yè)務(wù)信道的導(dǎo)頻信道的比值，取值范圍為-9dB~6dB.ACKChannelGain：用于指示AT發(fā)送ACK消息時(shí)候所采用的增益；該增益是DRC信道與反向業(yè)務(wù)信道的導(dǎo)頻信道的比值，取值范圍為-3dB~6dBNumPilots：TrafficChannelAssignment消息中所攜帶導(dǎo)頻的數(shù)目；PilotPN：導(dǎo)頻偏置；SofterHandoff：這個(gè)字段是用來(lái)標(biāo)記導(dǎo)頻之間的軟或者更軟切換關(guān)系的。當(dāng)這個(gè)字段設(shè)置為0，說(shuō)明這個(gè)導(dǎo)頻和排在它前面的那個(gè)導(dǎo)頻不是更軟切換關(guān)系，如果設(shè)置為1，說(shuō)明這個(gè)導(dǎo)頻和排在它前面的那個(gè)導(dǎo)頻是更軟切換關(guān)系(也就是說(shuō)是同一個(gè)基站不同扇區(qū)的導(dǎo)頻)；MACIndex：設(shè)置該字段為由此扇區(qū)指配給接入終端的MACIndex；DRCCover：設(shè)置該字段為指定扇區(qū)相關(guān)的DRC覆蓋的索引，所以切換態(tài)下的每個(gè)扇區(qū)的DRCCover都不會(huì)相同；RABLength：接入網(wǎng)設(shè)置該域?yàn)榉聪蚣せ畋忍匕l(fā)送所占用的時(shí)隙數(shù)，如下表所示：RABOffset：用來(lái)確定每個(gè)RAB比特發(fā)送的初始時(shí)刻，需要符合TmodRABLength＝RABOffset這個(gè)條件RTCACKAN發(fā)出這條命令表示已經(jīng)捕捉到了反向業(yè)務(wù)信道。AN網(wǎng)絡(luò)使用該AT當(dāng)前的ATI來(lái)發(fā)送該條消息。TrafficChannelComplete格式如下：AT在反向業(yè)務(wù)信道上發(fā)送這條消息，是對(duì)TrafficChannelAssignment消息確實(shí)認(rèn)。其中MessageID固定為0x02，MessageSequence等于它所確認(rèn)的TrafficChannelAssignment消息中的MessageSequence。具體例子上圖是一個(gè)QXDM記錄的AT發(fā)起的Connection建立流程。ConnectionRequest其中RequestReason為0，表示該ConnectionRequest消息是AT發(fā)出的。TransActionID＝19，表示該AT在此之前已經(jīng)發(fā)出過(guò)19個(gè)ConnectionRequest消息。TrafficChannelAssignment：從該條信息中可以獲得如下信息：message_sequence為0，因此對(duì)應(yīng)證實(shí)的TrafficChannelComplete消息中的message_sequence也應(yīng)該為0；TCA消息中配置了前向業(yè)務(wù)信道MAC的參數(shù)：DRCLength＝1〔也就是說(shuō)一個(gè)DRC占用兩個(gè)時(shí)隙〕，DRCChannelGain為－3×0.5dB〔－3補(bǔ)碼表示為61〕，ACKChannelGain為3×0.5dB；drc_cover=1，配置了PN108的DRCCvoer為1；TCA消息中配置了反向業(yè)務(wù)信道MAC的參數(shù)：ra_channel_gain=2(0x2)(-12dB)，配置了RAChannelGain為-12dB,說(shuō)明RA信道的增益為-12dB；rab_length=1，根據(jù)協(xié)議當(dāng)該字段的值為1，對(duì)應(yīng)的反向激活比特發(fā)送所占用的時(shí)隙數(shù)為16；Rab_offset=4，每個(gè)RAB比特發(fā)送的初始時(shí)刻，需要符合TmodRABLength＝RABOffset這個(gè)條件TCA消息中分配了一個(gè)導(dǎo)頻PN108，由此可以推斷AT的激活集只有一個(gè)PN108導(dǎo)頻，判斷AT激活集有哪些導(dǎo)頻可以通過(guò)TCA消息分配的導(dǎo)頻可以看出。具體可見(jiàn)協(xié)議中有一段這樣的描述：該協(xié)議說(shuō)明在TCA消息中，如果分配的導(dǎo)頻沒(méi)有在原來(lái)的激活集中，那么需要加導(dǎo)頻。另外還可根據(jù)協(xié)議中有這樣一段描述：該協(xié)議說(shuō)明在TCA消息中，如果在原來(lái)的激活集中TCA消息中沒(méi)有列出，那么需要去導(dǎo)頻。所以TCA消息中的導(dǎo)頻為活動(dòng)集的導(dǎo)頻。RTCAck：AN發(fā)出該消息，那么證實(shí)捕獲反向業(yè)務(wù)信道。TrafficChannelComplete：當(dāng)AN收到AT發(fā)出TCC消息后，證實(shí)業(yè)務(wù)信道已經(jīng)建立完成，同時(shí)停止TCC定時(shí)器，TCC定時(shí)器是在TCA消息發(fā)出的時(shí)候啟動(dòng)的。從TCC消息中可以看出message_sequence=0，此message_sequence等于前面TCA的message_sequence，表示該條TCC消息對(duì)前面TCA消息的證實(shí)。AN發(fā)起的普通Connection建立流程介紹過(guò)程過(guò)程描述aPDSN有分組數(shù)據(jù)發(fā)給AT，在已經(jīng)建立的A10業(yè)務(wù)連接上發(fā)送數(shù)據(jù)給PCF。bPCF發(fā)送A9BSServiceRequest消息給S_BSSAP，消息中帶有Data所在IPFlow對(duì)應(yīng)的SRID的信息，請(qǐng)求建立無(wú)線(xiàn)鏈路，并啟動(dòng)Tbsreq定時(shí)器。cS_BSSAP發(fā)送A9BSServiceResponse給PCF，確認(rèn)收到請(qǐng)求。如果Tbsreq定時(shí)器超時(shí)，PCF會(huì)將A9BSServiceRequest消息重發(fā)兩次，如果仍然超時(shí)，那么不作后續(xù)處理。dS_BSSAP發(fā)現(xiàn)主A8連接不存在，會(huì)啟動(dòng)新連接建立流程。首先向在最近收到的RouteUpdate消息中包含的PN對(duì)應(yīng)的小區(qū)播送UmcPage消息。eAT在接入信道上發(fā)送接入信道capsule，包含UmaConnectionRequest和UmaRouteUpdate消息，來(lái)響應(yīng)Page消息。該消息包含了AT以當(dāng)前時(shí)間為基準(zhǔn)的參考導(dǎo)頻和強(qiáng)度足夠的其它導(dǎo)頻，作為當(dāng)前無(wú)線(xiàn)鏈路狀態(tài)報(bào)告。該capsule由S_CES透明傳送給S_BSSAP。fS_BSSAP分析收到的接入信道capsule，發(fā)現(xiàn)是UmaConnectionRequest消息，并且UATI