20xxtd-scdma呼叫時延專題研究總結(jié)報告(編輯修改稿)
2024-09-06 22:21 本頁面
【文章內(nèi)容簡介】 需要等待上行同步時間，RRC連接時間后再等T312超時嚴(yán)重影響用戶感知。對于無線環(huán)境良好的TDSCDMA此參數(shù)可以適當(dāng)減小。N312為最小默認(rèn)配置值，從XXTDSCDMA網(wǎng)絡(luò)的接通率很好的前提下不需要變動既可滿足專用信道的可靠度和時延最小化。所以綜上所述：可適當(dāng)減小T312,保留N312最小默認(rèn)配置。即T312由5改為3 網(wǎng)絡(luò)資源對呼叫時延的影響 RNC負(fù)荷分析通過觀察現(xiàn)網(wǎng)RNC級一周的CS域話務(wù)量和PS域業(yè)務(wù)流量，RNC的負(fù)荷處于較小級別。時間RNCCS域話務(wù)量PS域業(yè)務(wù)流量06010607NTHRNC0106010607NTHRNC0206010607NTHRNC03 NODE B負(fù)荷通過對現(xiàn)網(wǎng)載頻級碼資源利用率的匯總并提選碼資源利用率最大的TOP載頻。既本地網(wǎng)絡(luò)碼資源利用率維持在較低水平。NODEB負(fù)荷較低，不存在由于碼資源不足引起接入時延過長現(xiàn)象。如下表：時間小區(qū)載頻碼資源利用率上行碼資源利用率下行碼資源利用率0607CellName=海門供電局, CellID=44101載頻索引=SECONDARY_1, 小區(qū)標(biāo)識=4410125464320605CellName=海門供電局, CellID=44101載頻索引=SECONDARY_1, 小區(qū)標(biāo)識=4410123464320604CellName=如皋文峰大世界, CellID=54071載頻索引=SECONDARY_1, 小區(qū)標(biāo)識=540712146432 尋呼問題對時延的影響尋呼問題一般都表現(xiàn)為：主叫完成RAB指派以及CC Setup，在等待Alerting消息的時候收到CN發(fā)來的Disconnect直傳消息。被叫從UE的信令流程一般看不出異常，但也出現(xiàn)過UE收到Paging消息而沒有發(fā)起RRC連接建立請求。從被叫的RNC單用戶跟蹤可以看出收到CN下發(fā)的Paging消息，但沒有后續(xù)的消息。通常尋呼問題分析流程如下圖所示：尋呼問題分析流程圖具體分析過程如下所示：1. RNC沒有下發(fā)Paging消息如果是RNC收到CN下發(fā)的paging消息后UU口沒有下發(fā)，可能是尋呼信道的容量不夠（現(xiàn)階段由于網(wǎng)絡(luò)負(fù)載很低，出現(xiàn)的概率很小，在以后網(wǎng)絡(luò)負(fù)載較高時，可能會出現(xiàn)UU口paging消息阻塞的情況），或者是設(shè)備異常。2. 尋呼指示信道的功率偏低尋呼指示信道PICH發(fā)射功率，影響小區(qū)的尋呼范圍和性能。設(shè)置過大，會導(dǎo)致PCCPCH的發(fā)射功率值無法正常設(shè)置到規(guī)劃需要的強(qiáng)度。設(shè)置過小，將會導(dǎo)致小區(qū)邊緣的UE無法偵聽到PICH。3. UE發(fā)生位置更新在尋呼的時候UE發(fā)生了位置區(qū)/路由區(qū)更新，而尋呼消息仍在原來的位置區(qū)/路由區(qū)下發(fā)，導(dǎo)致UE無法收到尋呼消息。 呼叫建立信令流程分析 信令流程主叫呼叫建立流程：MOC過程是指UE主叫其他用戶的過程：對一個MOC過程來說，可以分為隨機(jī)接入過程、初始直傳/上下行直傳、安全模式控制、呼叫建立、RAB建立過程和振鈴/接聽六各子過程。這六個子過程關(guān)系見下圖所示：隨機(jī)接入過程：當(dāng)用戶撥號時，一系列原語從MMICCMMRRC，原語中包含消息CM SERVICE REQUEST。參數(shù)：CM業(yè)務(wù)類型，Ciphering key sequencenumber，Mobile Identity （IMSI IMEI TMSI等)。初始直傳/上下行直傳(NAS信令建立流程)：NAS信令建立流程是在UE與UTRAN之間的RRC連接建立成功之后，UE通過RNC建立與CN的信令連接，用于UE與CN交互NAS信息，如鑒權(quán)，業(yè)務(wù)請求，連接建立等。UE與CN的交互信令，對于RNC而言，都是直傳消息。RNC在收到第一條直傳消息時，即：初始直傳消息（Initial Direct Transfer），將建立與CN之間的信令連接，該連接建立在SCCP之上。安全模式控制：由網(wǎng)絡(luò)側(cè)用來向無線接入網(wǎng)側(cè)發(fā)送加密信息的。在此過程中，核心網(wǎng)的網(wǎng)絡(luò)側(cè)將與無線接入網(wǎng)協(xié)商對用戶終端進(jìn)行加密的算法，使得用戶在后續(xù)的業(yè)務(wù)傳遞過程中使用加密算法；并且在終端用戶發(fā)生切換后，盡可能的仍使用此加密算法－即用于加密的有關(guān)參數(shù)會送到切換的RNC。根據(jù)測試結(jié)果：對于語音呼叫，；對于VP呼叫。但是出于網(wǎng)絡(luò)安全考慮，當(dāng)網(wǎng)絡(luò)開始正常營運的時候應(yīng)采用多種鑒權(quán)的組合方式，例如位置更新鑒權(quán)采用二分之一鑒權(quán)，部分業(yè)務(wù)如語音、VP、短信等采用了在此基礎(chǔ)上的同步方式，其他的業(yè)務(wù)則采用“總是”鑒權(quán)方式。修改小區(qū)A的鑒權(quán)加密流程，將每次呼叫都進(jìn)行鑒權(quán)加密改為不鑒權(quán)加密或每10次呼叫進(jìn)行一次鑒權(quán)加密。呼叫建立過程：（1）、當(dāng)UE發(fā)起一個呼叫的時候，UE的應(yīng)用層（MMI：ManMachine Interface，人機(jī)界面）將首先發(fā)起一個呼叫建立的請求。如果是發(fā)起一個普通呼叫，CC實體將首先向網(wǎng)絡(luò)發(fā)送一條SETUP消息，此消息主要包含TI（會話標(biāo)識，Transaction Identifier）、承載能力（bearer capability）、被叫用戶號碼（called party BCD number）、被叫用戶子地址（called party subaddress）、SI（流量標(biāo)識，Stream Identifier，只有當(dāng)UE支持多個呼叫時才存在）以及一些和普通呼叫相關(guān)的參數(shù)；如果是發(fā)起一個緊急呼叫，CC實體將首先向網(wǎng)絡(luò)發(fā)送一條EMERGENCY SETUP消息，此消息主要包含TI、承載能力以及一些和緊急呼叫相關(guān)的參數(shù)。（2）、消息發(fā)出后，CC實體將等待網(wǎng)絡(luò)處理后的返回消息，此時可對應(yīng)3種情況：注：這里只考慮正常的呼叫建立過程，還有一些如定時器溢出，低層出錯等異常情況這里不予描述。后面所述的其它進(jìn)程也與之相同。①網(wǎng)絡(luò)依次返回CALL PROCEEDING、ALERTING和CONNECT消息；②網(wǎng)絡(luò)依次返回ALERTI
公司管理相關(guān)推薦
鄂ICP備17016276號-1