【文章內(nèi)容簡(jiǎn)介】 套建議值。178。 ConfigurationResponse（AT側(cè)發(fā)起的協(xié)商）在此消息中AN對(duì)Request消息做了應(yīng)答，AckSeqNo等于上一條request消息中的SeqNo，采用ValueID＝1時(shí)候的一套建議值。178。 ConfigurationComplete通過(guò)這條消息，進(jìn)入了AN開(kāi)始協(xié)商配置的階段。這里TransactionID設(shè)置為1，所以可以推斷AN等會(huì)發(fā)送的Complete消息中該域也是1。由于是AT始發(fā)，所以沒(méi)有Token域。178。 ConfigurationRequest（AN側(cè)始發(fā)）在這個(gè)階段AN共發(fā)出了四條協(xié)商請(qǐng)求，分別是流層（0x12）、前向業(yè)務(wù)信道MAC層（0x03）、反向業(yè)務(wù)信道MAC層（0x04）和缺省分組應(yīng)用層（0x16）。 通過(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ù)。178。 ConfigurationResponse（AN側(cè)始發(fā)）AT對(duì)于AN發(fā)出的各種Request都進(jìn)行了回復(fù)，就不抓圖列舉了。178。 ConfigurationComplete（AN側(cè)發(fā)送）這里TransactionID等于前面AT發(fā)出的Complete消息中的該域。由于是AN發(fā)出該Complete消息，所以包含SessionConfigurationToken。178。 ConnectionColse階段進(jìn)入釋放流程，具體見(jiàn)后面詳細(xì)描述，此處就不再描述釋放流程的相關(guān)信息。3 Connection呼叫流程 AT發(fā)起Connection建立AT發(fā)起的Connection建立過(guò)程相對(duì)以往所了解的1x語(yǔ)音呼叫流程來(lái)說(shuō)，復(fù)雜不少，因此將此過(guò)程分解成為兩大階段來(lái)介紹，分別是空中信道指配捕獲階段和流應(yīng)用階段。 信道指配捕獲階段 流程介紹以上是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_CEC透明傳送給S_BSSAP，S_CEC接入信道解調(diào)單元還將估計(jì)AT到sector的往返延時(shí)RoundTripDelay，和接入信道capsule一起發(fā)送給S_BSSAP。bS_CEC對(duì)收到的接入信道capsule進(jìn)行確認(rèn)，通過(guò)控制信道發(fā)送UmcACAck，使用AT接入信道capsule中MAC層header中包含的UATI標(biāo)識(shí)。kS_SP構(gòu)造控制信道MAC分組UmcTrafficChannelAssignment發(fā)送給S_CEC，S_CEC通過(guò)控制信道發(fā)送給AT。信號(hào)內(nèi)容和空中接口消息中包含字段一致。lS_SP構(gòu)造控制信道MAC分組UmcResetReport發(fā)送給S_CEC，S_CEC通過(guò)控制信道發(fā)送給AT。信號(hào)內(nèi)容和空中接口消息中包含字段一致。ResetReport消息是為了控制AT發(fā)送RouteUpdate消息。在某些情況下，AN可能不能分配RouteUpdate消息中包含的所有PNOffset對(duì)應(yīng)小區(qū)的無(wú)線(xiàn)資源，在發(fā)送TCA消息后，AT可能又會(huì)發(fā)送RouteUpdate消息，包含先前已經(jīng)發(fā)送但AN未指配的PNOffset。通過(guò)發(fā)送ResetReport消息，AT只有當(dāng)看到新的導(dǎo)頻或者要去掉活動(dòng)集中的導(dǎo)頻時(shí)才發(fā)送RouteUpdate消息，消息中也允許包含先前的導(dǎo)頻。nAT收到UmcTrafficAssignment消息后，開(kāi)始在反向發(fā)送導(dǎo)頻和DRC。tS_SP發(fā)送UmfRTCAck，向AT確認(rèn)收到反向業(yè)務(wù)信道導(dǎo)頻和DRC。使用SLP的Reliable服務(wù)。uAT發(fā)送UmrTrafficChannelComplete給S_SP，消息中攜帶對(duì)前面消息SLP層的確認(rèn)。該消息確認(rèn)收到UmfTrafficChannelAssignment消息。使用SLP的Reliable服務(wù)，vS_SP發(fā)送UmfSLPAck，作為對(duì)UmrTrafficChannelComplete消息的SLP層確認(rèn)。 雖然上面的流程操作描述比較復(fù)雜，但是其實(shí)和1x的流程有點(diǎn)類(lèi)似，都遵循了起呼、應(yīng)答、信道指配、前反向捕獲、指配完成這幾個(gè)階段，抓住這一點(diǎn)，就好理解。其中RouteUpdate、ACAck、SLPACK等在前面已經(jīng)介紹過(guò)，下面主要介紹ConnectionRequest、TrafficChannelAssignment、ResetReport、TrafficChannelComplete等消息。 ConnectionRequestMessageID：固定設(shè)置為0x01；TransactionID：AT每發(fā)送一個(gè)新的ConnectionRequest，就增加該字段；RequestReason：該字段為0，表示終端發(fā)起，為1，表示AN發(fā)起，此外的值是不允許的。 TrafficChannelAssignmentMessageID：固定設(shè)置為1；MessageSequence：消息的序列號(hào)，應(yīng)該比上一個(gè)TrafficChannelAssignment消息中的序列號(hào)大1，范圍為0～255；ChannelIncluded：同RouteUpdate消息；Channel：同RouteUpdate消息；FrameOffset：用于反向的幀偏置，和1x系統(tǒng)類(lèi)似，將一幀的時(shí)間分解成為16個(gè)幀偏置；DRCLength：申請(qǐng)一個(gè)DRC所需要的時(shí)隙，該字段設(shè)置值所對(duì)應(yīng)的時(shí)隙數(shù)目如下表所示：DRCChannelGain：用于指示AT發(fā)送DRC消息時(shí)候所采用的增益；ACKChannelGain：用于指示AT發(fā)送ACK消息時(shí)候所采用的增益；NumPilots：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，對(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。ResteReport消息的作用可以參考協(xié)議中對(duì)RouteUpdate消息發(fā)送原則的描述。 RTCACK前向發(fā)出這條命令表示已經(jīng)捕捉到了反向業(yè)務(wù)信道。AN網(wǎng)絡(luò)使用該AT當(dāng)前的ATI來(lái)發(fā)送該條消息。 TrafficChannelComplete格式如下：這條消息是對(duì)TrafficChannelAssignment消息的確認(rèn)，其中MessageID固定為0x02，MessageSequence等于它所確認(rèn)的TrafficChannelAssignment消息中的MessageSequence。 具體例子上圖為Connection呼叫中空口的流程，有部分信令沒(méi)有顯示出來(lái)：前向的ResetReport消息、反向的Pilot+DRC、前向的SLPACK。其中ResetReport消息應(yīng)該是測(cè)試軟件丟失了，按照目前的設(shè)計(jì)，是AN發(fā)送了TCA消息后，就立即發(fā)送ResetReport。178。 ConnectionRequest其中RequestReason為0，表示該ConnectionRequest消息是AT發(fā)出的。TransActionID＝10，表示該AT在此之前已經(jīng)發(fā)出過(guò)10個(gè)ConnectionRequest消息。178。 AT接收到AN發(fā)出的TrafficChannelAssignment：從該條信息中可以獲得如下信息：該消息對(duì)AT的SeqNo為2的消息進(jìn)行了應(yīng)答，并且要求AT也對(duì)本消息進(jìn)行應(yīng)答，SeqNo為0；MessageID為3，因此對(duì)應(yīng)的TrafficChannelComplete消息中的MessageID也應(yīng)該為3；幀偏置為0，DRCLength＝1（也就是說(shuō)一個(gè)DRC占用兩個(gè)時(shí)隙），DRCChannelGain為－3（－3補(bǔ)碼表示為61），ACKChannelGain為6；178。 AT收到AN發(fā)來(lái)的ResetReport：178。 AN收到AT發(fā)來(lái)的TrafficChannelComplete：178。 RTCACK該消息要求AT進(jìn)行確認(rèn)，AT將在下一條TrafficChannelComplete消息中進(jìn)行確認(rèn)，也就是說(shuō)TrafficChannelComplete中的AckSeqNo將等于本消息中的SeqNo。 流應(yīng)用階段 流程介紹下圖為Connection連接過(guò)程中，AT向AN發(fā)送了TrafficChannelComplete消息之后的流程，主要是完成流的應(yīng)用工作，包括PPP連接、接入認(rèn)證、位置更新等，其中PPP連接是必不可少的部分。過(guò)程過(guò)程描述x下面流程假定session配置已經(jīng)完成，并且Stream1配置為缺省分組應(yīng)用的Access Stream，Stream2配置為缺省分組應(yīng)用的Service Stream。如果在AvfConnectionRequest消息中要求進(jìn)行接入認(rèn)證，S_SP啟動(dòng)打開(kāi)Stream1流控協(xié)議，發(fā)送UmfDataReady (SNP = Stream1)給AT，使用SLP Best Effort服務(wù)，并啟動(dòng)定時(shí)器Tfcresponse。yAT響應(yīng)UmfDataReadyAck，確認(rèn)收到UmfDataReady。zAT發(fā)送UmrXonRequest（SNP = Stream1）給S_SP，使用SLP Best Effort服務(wù)，請(qǐng)求打開(kāi)Stream1應(yīng)用以傳送RLP分組。aaS_SP發(fā)送UmfXonResponse（SNP = Stream1）給AT，使用SLP Best Effort服務(wù)，確認(rèn)收到消息UmrXonRequest，并打開(kāi)Stream1流應(yīng)用。b