最近發(fā)現(xiàn)在分析ATU測(cè)試的時(shí)候遇到一個(gè)問(wèn)題，至今未解，終端收到大量的RRCConnectionSetup消息，在回了RRCConnectionSetup Complete后還會(huì)繼續(xù)收到，夾雜在各種信令中，鑒權(quán)，加密之后也會(huì)有，感覺(jué)終端一直在接收，我發(fā)現(xiàn)大部分的情況這時(shí)候終端處于CELL_FACH狀態(tài)，而CELL_FACH狀態(tài)網(wǎng)上有如下解釋?zhuān)?/p>

CELL_FACH狀態(tài)具有如下特征:
* 沒(méi)有給UE分配專(zhuān)用傳輸信道
* UE連續(xù)監(jiān)聽(tīng)一個(gè)下行FACH信道
* 為UE分配了一個(gè)默認(rèn)的上行公共信道或上行共享傳輸信道例如RACH 使之能夠在接入過(guò)程中的任何時(shí)間內(nèi)使用
* UE的位置在小區(qū)級(jí)為UTRAN所知具體為UE最近一次發(fā)起小區(qū)更新時(shí)報(bào)告的小區(qū)

在CELL_FACH子狀態(tài)UE執(zhí)行下面的動(dòng)作:
* 監(jiān)聽(tīng)一個(gè)FACH
* 監(jiān)聽(tīng)當(dāng)前服務(wù)小區(qū)的BCH傳輸信道解碼系統(tǒng)信息消息
* 在小區(qū)變?yōu)榱硪粋�(gè)UTRA小區(qū)時(shí)發(fā)起一個(gè)小區(qū)更新過(guò)程
* 除非選擇了一個(gè)新小區(qū)否則使用在當(dāng)前小區(qū)中分配的C-RNTI作為公共傳輸信道上的UE標(biāo)識(shí)
* 在RACH上傳送上行控制信令和小數(shù)據(jù)包

從這個(gè)解釋中可以看到這時(shí)候終端下行占用FACH信道連續(xù)監(jiān)聽(tīng)FACH和當(dāng)前服務(wù)小區(qū)的BCH傳輸信道解碼系統(tǒng)信息消息，所以能收到其他的終端的RRCConnection Setup消息，但是通常分析數(shù)據(jù)可以發(fā)現(xiàn)一般語(yǔ)音測(cè)試時(shí)終端大部分處于兩種狀態(tài)IDLE和CELL_DCH，為什么終端這時(shí)候會(huì)進(jìn)入了CELL_FACH狀態(tài)的？從狀態(tài)轉(zhuǎn)移看有空閑態(tài)進(jìn)入CELL_FACH有RRC請(qǐng)求，那是什么RRC請(qǐng)求原因呢？查了寫(xiě)資料顯示CELL_FACH狀態(tài)適合傳輸少量數(shù)據(jù)和信令的是不因?yàn)闆](méi)有占用專(zhuān)用信道無(wú)法建立語(yǔ)音業(yè)務(wù)？求各位遇到過(guò)這種情況的大神，網(wǎng)優(yōu)兄弟解答，一起討論。

就是FACH擁塞 了嘛。  解決辦法如下圖：

因?yàn)橛锌赡躌NC沒(méi)有下發(fā)RRCConnectionSetup給UE，UE發(fā)RRC請(qǐng)求后會(huì)監(jiān)聽(tīng)FACH信道的消息，大量的RRCConnectionSetup是RNC發(fā)給其他小區(qū)的，不是發(fā)給其的，其只是收而已，發(fā)現(xiàn)不是其的又收其他的了。至于可能RNC沒(méi)有下發(fā)的話要慢慢排查了