【正文】 以本消息中這個(gè)字段也為0。178。 UATIComplete本消息為UATIAssignment消息的應(yīng)答消息。 Session配置 流程介紹上面顯示的Session進(jìn)行配置的一部分流程，在此之前是完整的空口信道指配捕獲階段流程，見(jiàn)Connection呼叫流程中的第一個(gè)部分。yAT發(fā)送UmrSessionConfigurationRequest消息，協(xié)議類(lèi)型為SCP，首先進(jìn)行SCP協(xié)議的協(xié)商。zS_SP發(fā)送UmfSessionConfigurationResponse消息，協(xié)議類(lèi)型為SCP，確認(rèn)或者提議新的協(xié)議參數(shù)。bbS_SP發(fā)送UmfSessionConfigurationResponse消息，協(xié)議類(lèi)型為T(mén)ypeX，確認(rèn)或者提議新的協(xié)議參數(shù)。dd如果在前面協(xié)商中指定使用Key交換協(xié)議，則開(kāi)始Key交換過(guò)程。eeAT發(fā)送UmrKeyResponse消息，包含AT的公共DHKey。ggAT進(jìn)行和AN相似的計(jì)算，并把計(jì)算結(jié)果和UmfANKeyComplete消息中的KeySignature比較，把比較結(jié)果放在UmrATKeyComplete消息通知AN。否則，Key交換過(guò)程失敗，Session配置過(guò)程結(jié)束。協(xié)商進(jìn)入AN啟動(dòng)階段。jjS_SP發(fā)送UmfSessionConfigurationRequest消息，協(xié)議類(lèi)型為T(mén)ypeY，進(jìn)行該類(lèi)型協(xié)議的協(xié)商。llAN完成協(xié)議協(xié)商，發(fā)送UmfSessionConfigurationComplete。pp~qqS_SP啟動(dòng)連接關(guān)閉，發(fā)送UmfConnectionClose消息。由于上面的流程操作描述較多，在這里做一個(gè)簡(jiǎn)單的介紹：當(dāng)AT發(fā)送ConnectionRequest消息給BSSAP后，BSSAP將發(fā)送AvfConnectionSetup給S_SP，如果該AvfConnectionSetup中指示進(jìn)行協(xié)議協(xié)商，那么在空中信道指配捕獲結(jié)束之后，將不是按照Connection呼叫流程中的啟用Stream1和Stream2等流程，而是開(kāi)始協(xié)議協(xié)商。在y、z以及hh、ii等四步是進(jìn)行SCP（會(huì)話(huà)配置協(xié)議）的協(xié)商，該協(xié)議協(xié)商的作用是啟動(dòng)AT或者AN進(jìn)行會(huì)話(huà)配置協(xié)議協(xié)商，其中y、z是啟動(dòng)AT的SCP協(xié)商，hh、ii是啟動(dòng)AN的SCP協(xié)商，但是在實(shí)際的前臺(tái)信令中，沒(méi)有看到空口流程中有type值為0x12的信令，這有兩種可能：178。 當(dāng)前配置參數(shù)不需要進(jìn)行SCP的協(xié)商。將流程重新梳理一遍，在y、z處，啟動(dòng)AT的SCP協(xié)商，啟動(dòng)成功之后，aa處AT向AN發(fā)出了ConfigurationRequest消息，請(qǐng)求各種協(xié)議的配置，并等待AN的應(yīng)答。目前后臺(tái)設(shè)置的協(xié)商方式多為ANInCharge 或者Negotiation，而沒(méi)有ATInCharge，所以最終的協(xié)商結(jié)果基本上是以AN協(xié)商結(jié)果為主。本小節(jié)沒(méi)有涉及KEY交換方面流程介紹。 ConfigurationStart該條消息的內(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)。 非激活狀態(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啟動(dòng)會(huì)話(huà)配置。下圖為AT側(cè)會(huì)話(huà)配置協(xié)議狀態(tài)圖。它為給定屬性定義一套建議值，屬性記錄格式被定義，可以使得接收方不能識(shí)別此屬性，則它也能夠丟棄它并分析此記錄隨后的屬性記錄。 簡(jiǎn)單屬性：假如屬性記錄中只包含單個(gè)值；178。 綜合屬性：如果屬性記錄中包含多種單個(gè)值，這些值一起形成一個(gè)特定屬性標(biāo)志符的綜合值；單個(gè)屬性和屬性列表的格式如下：其中Length是屬性記錄的長(zhǎng)度，單位為字節(jié)，但是不包含Length域本身；AttributeID是屬性標(biāo)志符，在正在配置的協(xié)議上下文中，屬性標(biāo)志符是唯一不變的；AttributeValue是屬性建議值，通常屬性建議值長(zhǎng)度是字節(jié)的整數(shù)倍。綜合屬性的結(jié)構(gòu)如下所示：其中Length同樣是屬性記錄的長(zhǎng)度，也不包含Length域本身，但是包含ValueID域的長(zhǎng)度。其余字段含義和屬性記錄的字段含義一樣。如果ConfigurationRequest中是單個(gè)屬性或者是屬性列表，那么就是直接選擇一個(gè)屬性值，如果Request消息中是一個(gè)綜合屬性，那么Response消息中就回復(fù)某一個(gè)ValueID。 ConfigurationComplete發(fā)送方發(fā)送ConfigurationComplete消息，以指示它已經(jīng)完成它始發(fā)執(zhí)行的協(xié)商過(guò)程。SessionConfigurationToken：會(huì)話(huà)配置標(biāo)志。 具體例子結(jié)合上述的Request和Response消息的格式以及最初的流程介紹，可以看一個(gè)比較完整的Session配置實(shí)例。178。178。從上圖看到這里使用的是綜合屬性，type＝0x13，說(shuō)明是流層的配置協(xié)商，Length＝10，這是因?yàn)锳ttributeID和ValueID各占用一個(gè)字節(jié)，StreamXApplication各占用2個(gè)字節(jié)。178。178。這里TransactionID設(shè)置為1，所以可以推斷AN等會(huì)發(fā)送的Complete消息中該域也是1。178。 通過(guò)上述的內(nèi)容，可以看出AN在流層協(xié)商了各個(gè)流層的應(yīng)用，在前向業(yè)務(wù)信道MAC層協(xié)商了DRCLockPeriod和DRCLockLength兩個(gè)參數(shù)，在反向業(yè)務(wù)信道MAC層協(xié)商了反向速率控制的概率值，在分組應(yīng)用層中，協(xié)商了是否主動(dòng)發(fā)起位置更新的參數(shù)。 ConfigurationResponse（AN側(cè)始發(fā)）AT對(duì)于AN發(fā)出的各種Request都進(jìn)行了回復(fù)，就不抓圖列舉了。 ConfigurationComplete（AN側(cè)發(fā)送）這里TransactionID等于前面AT發(fā)出的Complete消息中的該域。178。3 Connection呼叫流程 AT發(fā)起Connection建立AT發(fā)起的Connection建立過(guò)程相對(duì)以往所了解的1x語(yǔ)音呼叫流程來(lái)說(shuō)，復(fù)雜不少，因此將此過(guò)程分解成為兩大階段來(lái)介紹，分別是空中信道指配捕獲階段和流應(yīng)用階段。其中從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ú)線鏈路狀態(tài)報(bào)告。bS_CEC對(duì)收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道發(fā)送UmcACAck，使用AT接入信道capsule中MAC層header中包含的UATI標(biāo)識(shí)。信號(hào)內(nèi)容和空中接口消息中包含字段一致。信號(hào)內(nèi)容和空中接口消息中包含字段一致。在某些情況下，AN可能不能分配RouteUpdate消息中包含的所有PNOffset對(duì)應(yīng)小區(qū)的無(wú)線資源，在發(fā)送TCA消息后，AT可能又會(huì)發(fā)送RouteUpdate消息，包含先前已經(jīng)發(fā)送但AN未指配的PNOffset。nAT收到UmcTrafficAssignment消息后，開(kāi)始在反向發(fā)送導(dǎo)頻和DRC。使用SLP的Reliable服務(wù)。該消息確認(rèn)收到UmfTrafficChannelAssignment消息。 雖然上面的流程操作描述比較復(fù)雜，但是其實(shí)和1x的流程有點(diǎn)類(lèi)似，都遵循了起呼、應(yīng)答、信道指配、前反向捕獲、指配完成這幾個(gè)階段，抓住這一點(diǎn)，就好理解。 ConnectionRequestMessageID：固定設(shè)置為0x01；TransactionID：AT每發(fā)送一個(gè)新的ConnectionRequest，就增加該字段；RequestReason：該字段為0，表示終端發(fā)起，為1，表示AN發(fā)起，此外的值是不允許的。當(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，對(duì)于前向業(yè)務(wù)信道，MACIndex可以是5～63；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í)刻，需要符合T mod RABLength ＝RABOffset這個(gè)條件，公式中的RABOffset等于TrafficChannelAssignment消息中RABOffsetRABLength/8； ResetReport該消息是AN用來(lái)復(fù)原AT發(fā)送RouteUpdate消息時(shí)的狀況，結(jié)構(gòu)如下：其中MessageID固定設(shè)置為0x03。 RTCACK前向發(fā)出這條命令表示已經(jīng)捕捉到了反向業(yè)務(wù)信道。 TrafficChannelComplete格式如下：這條消息是對(duì)TrafficChannelAssignment消息的確認(rèn)，其中MessageID固定為0x02，MessageSequence等于它所確認(rèn)的TrafficChannelAssignment消息中的MessageSequence。其中ResetReport消息應(yīng)該是測(cè)試軟件丟失了，按照目前的設(shè)計(jì)，是AN發(fā)送了TCA消息后，就立即發(fā)送ResetReport。 ConnectionRequest其中RequestReason為0，表示該ConnectionRequest消息是AT發(fā)出的。178。 AT收到AN發(fā)來(lái)的ResetReport：178。 RTCACK該消息要求AT進(jìn)行確認(rèn)，AT將在下一條TrafficChannelComplete消息中進(jìn)行確認(rèn)，也就是說(shuō)TrafficChannelComplete中的AckSeqNo將等于本消息中的SeqNo。過(guò)程過(guò)程描述x下面流程假定session配置已經(jīng)完成，并且Stream1配置為缺省分組應(yīng)用的Access Stream，Stream2配置為缺省分組應(yīng)用的Service Stream。yAT響應(yīng)UmfDataReadyAck，確認(rèn)收到UmfDataReady。aaS_SP發(fā)送UmfXonResponse（SNP = Stream1）給AT，使用SLP Best Effort服務(wù)，確認(rèn)收到消息UmrXonRequest，并打開(kāi)Stream1流應(yīng)用。ccS_TP發(fā)送AsdrFlowControlOpenedAck消息給S_SP，確認(rèn)收到FlowControlOpened。AT不發(fā)送UmrXonRequest消息打開(kāi)流控協(xié)議，而直接發(fā)送RLP分組，S_TP收到AT在Stream1上發(fā)送的分組，認(rèn)為Strea