5GNR網絡端到端時延優化【摘要】目前中國電信5G網絡已經開始運行，在網絡實際運行的過程中，時延是最明顯的感知指標，5G時延和4G相比，從20ms降低至1ms，有著非常大的提升，也是URLLC（Ultrareliableandlowlatencycommunication）超可靠且超低的時延業務所需求的。本案例結合影響時延的各個網元節點，對時延優化進行深入分析，并結合地市實際情況進行問題處理，從端到端對影響時延的各個因素進行總結排查，并解決問題。【關鍵字】時延、端到端【業務類別】參數優化問題描述5G網絡的1毫秒時間延遲，最初是由：四IMT-2020M.2410-0（4.7.1）關于IMT-2020系統的設計最小需求中提到的。其適用的范圍是URLLC（Ultrareliableandlowlatencycommunication）超可靠且超低的時延業務，這里的時延是針對用戶面時延。用戶面時延，是指我們平時使用手機發送數據的時間延遲，區別于控制面時延：手機注冊網絡或者狀態轉換經過的信令流程所花費的時間（控制面時延不做討論）。另外，1毫秒指的是無線網絡空中接口（手機和基站之間，不包括核心網，互聯網等網絡節點）的雙向延遲時間。總時間二T1+T2圖1-1：雙向延遲雙向延遲(RoundTripTime,RTT)，指的是信息從發送方到達接收方，加上接受方發信息給發送方所花費的總時間。雙向延遲在工程中更加常見，因為我們可以只在信息發送方或者接收方的其中一方就可以測量到雙向延遲(利用ping等工具)。在5G網絡中，時延是一個重要的關注點，如何優化改善網絡時延，是需要重點關注的方面。分析過程5GURLLC滿足極低時延極高可靠業務，2016年，3GPP開始了5G的需求分析和研究項目，為了滿足ITU所設置的URLLC極高的可靠性和極低的時延要求，在6的需求研究項目TR38.913Studyonscenariosandrequirementsfornextgenerationaccesstechnologies中的用戶面KPI中針對URLLC業務用戶面時延定義了上行0.5ms和下行0.5ms的要求，加起來正好是1ms的雙向時延。需求的定義明確了，接下來進入了研究如何實現技術需求的階段，2016年3月，3GPPTSGRAN71次會議通過了TR38.912StudyonNewRadio(NR)accesstechnology，這項研究工作致力于提出可行的無線技術來滿足ITU-2020制定的56需求。而從研究項目伊始，URLLC就做為一項不可缺少的56需求被考慮進來。從2016年的研究項目開始到2018年中第一版本5G標準(release15NSA&SA)的出爐，低時延的設計貫穿了整個5G無線系統，我們就從用戶面的每個層(物理層PHY，媒體接入控制層MAC，無線鏈路控制層RLC)看看為了實現1ms的目標都做了怎樣的努力。5G中物理層的主要作用是：編解碼，調制解調，多天線映射等。因為低時延是與URLLC的另一部分需求：極高的可靠性(9.999%)被共同捆綁在一起的。如果單單考慮低時延會比低時延高可靠簡單很多，因為要滿足極高的可靠性慣常采用更多的控制信令開銷，重傳，冗余，這些手段往往會提升時間延遲的水平。所以如何在保證可靠性的同時改善時延水平在物理層的設計中是難上加難°5G物理層用了哪些手段來改善時延呢？

UE圖2-2：物理層UE圖2-2：物理層2.1包結構在4GLTE的時延分析中提到過的系統處理時間在時延中所占的分量比較大，而且改善較為不易。這部分時延包括了接收包，獲取控制信息，調度信息，解調數據，以及錯誤檢測。在4GLTE中是采用下圖左側這種方形的包結構，傳輸的信息分為三部分，導頻信息（Pilot），控制信息（controlinformation），以及數據（data）。這種設計方式被廣泛的用來對抗信道衰落。但是在5G中URLLC包采用的是下圖右側這種設計方式，導頻信息，控制信息，以及數據依次在時域上排列，這樣做的好處是信道估計，控制信道解碼，數據的獲取可以串行的進行，通過這樣的方式這樣減少了處理時間。圖2-3：4GLTE和5GURLLC包結構對比從手機收到資源分配（Grant）指令到數據的傳輸時間要求如下，中間部分是5G不同子載波間隔(SubcarrierSpacing)配置下的不同要求：Table14.1MinimumProcessingTimeinOFDMSymbolsFromGrantReceptiontoDataTransmissionDeviceCapabilrtySubcarrierSpacingLTERel815kHz30kHz60kHz120kHzBaselineAggressive0-71ms0,18-0.39rns0.43ms0.OB—0.2ms0.41msQ.32ms3ms圖2-4：子載波從手機收到資源分配（Grant）指令到數據的傳輸時間要求2.2信道編碼4GLTE采用Turbo和Simplecode來編解碼數據達到無線傳輸的可靠性。在G中使用的是LDPC和Polar碼來提升數據和控制信道的編解碼效率，經過編碼界研究的不懈努力編解碼的性能和計算復雜度的提升對于降低時延也有所幫助。2.3更短的傳輸時間間隔從更短的時間間隔這點說5G是天然優勢一點都不為過，LTE規定的一個子載波傳送信息的最小頻域單位是15KHz，時間域是1ms（正常情況下）。5G所需要支持的頻率范圍非常廣，中低頻從450MHz~6000MHz（FR1），高頻從24.25GHz~52.6GHz（FR2）。高頻意味著更高的相位噪聲，所以需要設計更加寬的子載波間隔來抵御相位噪聲的干擾。更寬的子載波間隔，意味著時域上更短的時隙，更短的傳輸時間間隔，我們在4GLTE時代千方百計想要降低的傳輸時間間隔在G時代只需要使用更高的頻段，更寬的子載波間隔就輕而易舉的降低了。而且根據不同的頻段可以選擇15KHz,30KHz到120KHz的子載波間隔，可以簡單的理解為，5G子載波間隔相比于LTE15KHz增加了多少倍，那么在時域上的傳輸時間間隔就減少相應的倍數。頻域子載波間隔成倍增加，時域符號時長相應倍數減少。ISAHrSCSWfcHrSQISAHrSCSWfcHrSQ國臨新I而川mini而iiiiiiwiiiiiii而iii而111血||血|||血iiniiii［而Hiif?癡福圖2-5：NR子載波2.4微時隙調度微時隙調度繼承了LTE中減小傳輸時間間隔subslot）的設計理念，將最小的傳輸時間間隔由子幀拓展到了符號上。第一優先級最小的調度間隔根據情況可以選擇2個符號，4個符號，7個符號。下圖是一個下行數據傳輸的示例，數據包到達了基站，基站經過符號的處理以及等待合適的，?。（3如時間，隨后通過兩個符號的微時隙調度將數據傳輸給用戶。數據包到達圖2-6：數據傳輸MAC的作用是多路邏輯信道的復用，HARQ（混合重傳），以及調度相關的功能。關于時延的改善的技術在MAC層有：2.5異步HARQ當無線環境出現問題等原因造成傳輸的數據出錯，在MAC層會由HARQ功能來發起重新傳輸流程，在LTE中，HARQ的時間間隔（從收到數據到發送反饋給發送方是否正確接收信息指令）是固定的（FDD，TDD根據子幀結構變化）。而在5G中，HARQ的時間間隔是動態指派的，更加的靈活，也符合低時延的設計要求。5G與4GHARQ流程時間對比:Tabte13』MinimumProcessingTime(PDSCHMappingTypeA,FeedbackonPUCCH)DM-RSConfigurationDeviceCapabililySubcarriafSpacing15kHz30蚌It60kHi120kHzRel8Front-loadedAdditionalBaselineAggressiveBaselineAggressive0-57ms018-D29rns0.92ms005ms0.36ms000-017ms046ms04ms030ms036ms0.18ms0.21ms:匚rr一仃；2.3ms圖2-7：5G與4GHARQ流程時間對比2.6上行免調度傳輸和4GLTE一樣，5G可以周期性的給用戶分配上行資源（半靜態調度）來減少上行的傳輸時延，而且5G更加進了一步。在4G中半靜態調度的資源一般是給每個用戶單獨分配的，所以當網絡中用戶較多的時候，造成的浪費是非常大的，因為預留的無線資源終端不一定會使用。在5G中可以將預留資源分配給一組終端用戶，并且設計了當多個用戶同時在相同的無線資源上發生沖撞的解決機制。這樣在降低時延的同時使寶貴的無線資源的利用率也得到了保證。圖2-8:5G上行免調度傳輸typel和type22.7預清空調度預清空調度的意思是為某個高優先級的用戶清空原來已經分配給其他用戶的資源，打個比方，我們去餐館吃飯，沒有位置了，餐館老板認識我們是高級VIP，所以把一桌正在吃飯的人趕走了，把桌子留給了咱們。通過這樣的方式達到了對時間延遲要求高的用戶可以立即傳輸數據，從而降低了時延。下圖是一個示例：用戶A已經在一個時隙上被調度了數據，但是這時用戶被標記為對時延要求高的數據需要傳輸。如果這時有空閑的時頻域資源可用，用戶B會被優先調度空閑的資源但是如果此時網絡負荷較大，沒有空閑的資源可用，用戶B就會搶占其他用戶的（例如用戶A）的資源。這種方式有個弊端就是會影響原本被分配資源的A的用戶的數據傳輸（在被用戶B搶占的資源上），當然優秀的5G系統也設計了方案來解決這個問題，方式有：HARQ重傳用戶A受影響的傳輸數據，或者是直接通過控制信令DCI2-1）通知用戶A,哪些傳輸的數據受到了影響。圖2-9:預清空調度RLC層主要負責RLC數據的切分，重復數據去除，RLC重傳的工作。在RLC層中關于低時延的技術考量主要體現在：在GLTE中RLC層還需要負責保證數據的按順序傳遞（In-sequencedelivery，即前面的包沒有向上層傳遞之前，排在后面的包需要等待。在5G中去掉了這樣的功能要求來保障低時延水平。這樣做的好處是，如果之前有某些包因為某些原因（例如無線環境突然變差）丟失了需要重傳，在5G中后面的包不需要等到前面的包重傳完畢就可以直接向上層傳遞。那么通過以上關鍵技術的組合，是怎么一步步使5G無線網絡時間延遲降低到1毫秒的呢？表2-1:雙向延遲通過使用30KHz的子載波間隔，上行免調度，以及兩個符號的微時隙HG系統配置方案，可以達到低于雙向時延1ms以下的要求。如果采用5G高頻通信，使用120KHz的子載波間隔，時延可以更低。至此，1ms夢寐以求的目標終于達成，但是科技工作者們仍沒有停下探索的腳步，目前的研究轉向了5G物理層的增強對URLLC業務的支持，而新的研究項目也已經成功立項并完成：StudyonphysicallayerenhancementsforNRultra-reliableandlowlatencycase(URLLC),在下一版本5Grelease16中，URLLC將從PDCCH，UCI，PUSCH(上下行控制信道以及上行數據信道)獲得更多的提升。同時還研究支持對時延和可靠性要求極高的工業互聯網應用StudyonNRindustrialInternetofThings(IoT)。解決措施5G做ping時延測試，一般是在連接終端UE的筆記本電腦上面進行ping包，為了排除，外網時延的影響，一般采用pingFTP內網服務器IP地址的方式。3.1ping測試問題的分析思路由于ping包測試電腦和測試終端JE的影響不可控，排除這這個因素后，需要重點分析PING環回時延的空口時延和傳輸時延兩部分。當測試得到的環回時延較大時，甚至不能

滿足PING包測試指標要求時，需要將ping時延分解成下面兩部分單獨進行分析：無線空口時延，即UE和基站間的交互時延，傳輸側交互時延。分解為兩部分統計環回時延的目的是判斷出時延較大的原因是由空口造成還是傳輸引起的。如果空口時延較大，則需要從調度算法上考慮優化，這塊由版本和無線參數來保證；若傳輸時延較長，那就是非接入層的原因，可以從基站側pingEPC或PINGFTP服務器來確認是否受到傳輸網絡的影響，確認是傳輸的問題，需要請傳輸側工程師協助解決。3.2無線空口時延分析方法無線空口時延，即UE和基站間的交互時延主要受基站無線參數設置及無線環境的影響。主要分析方法是通過QXDM或者其他測試工具在終端UE側進行抓log分析，如果有時延差異的話就需要對相關信令流程和無線參數進行分析定位。3.3影響ping時延的無線參數影響ping時延的無線參數主要有3類，分別介紹如下。3.3.1ping包調度模式多元域編碼的設計動態調度（0）基于收到SR置大的模擬BSR模式（1）混合調度模式（2）增強型混合調度模式（3）基于預調度模式（4）VSWc2單板的ping包時延具有3中調度模式，見DV參數表中V2調度參數---ping包優化開關：基于收到SR置大的模擬BSR模式Large-TB-basedDynamicSchedule(0)混合調度HybridSchedule(1)MmX尊WHiT.K心tthbrUWFT5-械9…瞄唱予弦，頃?，―動態調度DynamicSchedule(2)*ww?F1VI網.仲母禎璉*電MmX尊WHiT.K心tthbrUWFT5-械9…瞄唱予弦，頃?，―Ping包時延5種調度模式具體介紹如下:第一種、動態調度對于當前5G系統，動態調度未打開ping包優化開關條件下，Ping包過程及各段時延分析。圖3-11：Ping包調度過程Ping包過程（動態調度）正常的動態調度模式下，當UE的MAC層收到高層的上行業務請求，會觸發一俶（ScheduleRequest）請給給基站，基站收到響應后，發送一個小的上行授權，UE用來報告BSR（BufferStatusReport,用來告訴基站有多少數據需要發送）。基站收到BSR之后，根挪5日給UE上行授權，UE使用該授權發上行的PING的內容，PING的數據就發送到基站側。第二種、基于收到SR置大的模擬BSR模式這是目前版本默認設置的模式。其基本原理是基于SR上報，根據前一個TTI需要調度的UE個數，基站主動下發一個較大的上行資源，使建可以利用該資源發送上行數據，減少了UE^送BSR然后eNB根據BSR進行調度的流程。第三種、混合調度模式混合調度模式是在預調度持續時間內，定時主動向UE發送上行資源，UE利用該資源發送上行數據。由于基站是周期性的對E分配上行資源，減少TUE^送SR的流程，因此使得PING包的時延縮短。具體為:。￡發送5日請求，基站檢測至后日后，產生虛擬的BSR＞行正常的調度處理，啟動預調度周期PingPreSchPeriodTimer和預調度持續時間PingPreSchHoldTime默認2048ms)；在PingPreSchHoldTimer超時前，每隔PingPreSchPeriodTimer站主動產生虛擬BSR并進行調度；UE利用預調度的資源發送ING包的上行數據和可能的3SR。混合調度模式對所有的SR均做同樣的處理，如果商用系統中用戶量較大，大量的上行資源預授權將導致基站反向干擾加重，嚴重影響基站反向解調性能。商用局環境下不建議采用這種模式。第四種、增強型混合調度模式為了避免混合調度模式帶來的負面影響，增強型混合調度模式能夠對PING的業務進行識別，識別出PING業務的周期和大小之后，僅僅在ING的周期到來時，給一定長度及相應大小的預授權即可。這樣能大大減緩預授權帶來的帶寬損失，可提升上行的有效載荷。第五種、基于預調度模式預調度模式下，UE直接發送ping包，沒有SR及BSR預授權協商過程，這種模式只能用于單用戶實驗室測試，屬于極限測試。3.3.2SR傳輸周期Ping包測試時，上行傳輸默認使用LargeBSR方式傳輸。終端首先發起SR(SchedulingRequest)，在基站進行上行資源授權之后，終端再發起BSR(BufferStatusRequest)和ping數據包一起上傳。注意當JE高層要求發送SR的時候，并不是在每一個時隙都可以發送，而是需要在SR周期內的某一個時隙才能發送。SHIPffTtFTFlfll圖3-12：SR傳輸周期網管參數在無線參數---上下行物理信道配置表：UESR傳輸周期(ms)如果配置SR周期為10ms，那么SR發送前的等待時間為1?10ms，平均等待時間為5ms。協議規定的最小SR周期是5ms，SR周期最短只能設置到51^，目前我司默認配置是10ms，其實有些場景下如果S1傳輸時延太大導致ping時延離驗收標準只差幾略的時候，可以把SR周期改為5ms，使得SR發送前的平均等待時間縮小至2.5ms。通過將SR傳輸周期從10ms修改為5ms，使得ping時延平均值減少了3ms。需要注意的是，將SR周期從10ms修改為5ms，將會使得PUCCHSR信道支持的最大用戶數減少一倍，我司默認參數是按照每載扇00激活用戶配置的，修改后會使得UCCH信道容量減少。在網絡負載比較小的場景下修改這個參W響不大。主要包括碼字設計和系統設計。碼字設計的目標是設計協作傳輸的效率更高，與各個分支鏈路信道條件相匹配的信道編碼；系統設計的內容包括用戶配對、路由選擇和資源調度等。網絡編碼是與部署場景密切相關的，具體方案需要針對某一種場景進行優化，例如，協作中繼和節點雙向傳輸兩種場景對空口標準的影響程度就有所不同。3.3.3DRX參數鏈路DRX功能開啟之后，在沒有數據傳輸的時候，終端會進入休眠狀態以節省電源，這時候上/下行數據的發送都可能會被延遲，進行ping業務會造成時延變長。在NGBRDRX打開和關閉前后進行ping對比測試，關閉DRX時ping平均時延減少了3~4ms。3.4無線環境對ping時延的影響如果無線環境較差，或者無線環境的突然變化，都會造成空口發送的數據包解碼錯誤而產生HARQ重傳，重傳一次的額外時延是8ms。下圖是通過QXDM抓取的一個ping包測試log數據，利用QCAT進行分析，在系統幀和子幀1099時上行MAC層發了一個ping包數據。msLM■-Lif*甘》^知-LSn^-sdinED-*，■甘abki-Krmrp?rl!IglE-&岷:I3JbcsifejlElm>■M.DaLuj.CiMrpaiAJda11■Pracsrirfruf由"-]III■:Inii-m-miI|H?riii陽f由m『￥出TbI*iHMlKfE：IMt+ncIIB4l?irrfl|讓DEEI￥J.iOKUllCff|in.|q|￡-khc|i|i?a|.|ic>iIhrf'|<-anc|11unmif-aica|me|■||||TOC\o"1-5"\h\zIIIIIIII'IIIIl||||IIIIIIIIIIII41HlIIIIIIIIIIIIIII-IlIII

Miu.ii的“imMfr■■awiTEvw-OiTd^KKwg，r■IEw甘—in4.ife-1-I,U.'Sria^nnILlHiI<KBllh■*2-村1rwj-p■■>■￡j.srli?S|■Xa.rvinEri.9r■.IIfiflJ|口|￡?J?d上：JkhIIfiflJ|口|￡?J?d上：Jkhtin|n-jr-Frjt>rrf?|ix-|tb|rr-|fhru^-|nuiiirrajiuMu\|ji=Eijiir?rTOC\o"1-5"\h\ziiii|9ic-Edruciiinillii=勺m』■>陌*IIIlliIIIIImlElcwrlsiIImlilIxisl<1rriml］r-aratiin:；［l|isiiM”ii甘IIIlliIIIIIiizliis??nltIIImlilI啊I■!ir圖3-13：Ping包數據在系統幀和子幀1123時才收到下行MAC層返回的ping包數據，時延為1123-1099=24ms，這個商用局的S1口傳輸時延為10ms，即使扣除這個S1口10ms時延后，14ms也明顯大于基站內部標準處理時延6ms。在LTEPDSCHStatIndication消息中查看，發現在系統幀子幀1115時的CRCResult是fail，導致HARQ重傳，在8ms后的系統幀子幀1123重新收到了ping包數據，這時候的CRCResult為pass，正確解碼。從這個例子中可以看出空口解碼錯誤導致的HARQ重傳，會增加ping包時延8ms。S1口時延指PingReq從基站出去（發往UE需要Ping的服務器）-＞基站收到服務器返回的PingReply的時延，該段時延應該小于1ms，而不是單單指的基站與核心網的傳輸交互時延。S1口時延測試有三種方法：第一種、IP通道質量測試確定S1口時延這個功能可實現通過在OMC客戶端上進行操作，發起以“基站”做為ping操作的起點，對目標IP地址的IP通道質量通道檢測。目標IP地址選擇核心網MME或者SGW的IP地址。正常情況下，從基站ping核心網MME或者SGW的時延應該在1~2ms，如果偏大的話將會導致UEping時延增大，需要聯系傳輸側排查S1口時延。第二種、Wireshark在基站VSWc2板debug口抓包確定傳輸時延Telnet6，并padMGR.exe，登錄到平臺管理進程，敲入MirrorToDebug0,0，在QE進行端口映射，然后開啟wireshark，在CC板debug口抓包。詳細抓包方法請參考附錄ADebug口抓包方法。在Ping之前，打開Wireshark工具，點擊Capture捕獲窗口，選擇正確的interface,對應的服務器地址，在過濾欄指定IMCP消息，選擇Updatelistofpacketsinrealtime。使用完成之后使用BspClearESwitchMirror清除鏡像，以免出現其他問題。

圖3-14:傳輸時延采集在InterControlMessageProtocol里：Sequencennumber:確定該Ping包的序列號，Data里確定一次Ping包的大小。傳輸時延=Echo(ping)reply的frame23里的Arrivaltime-Echo(ping)request的frame24里的Arrivaltime。第三種、UE側log分析確定傳輸時延通過Ue側Mog來看，看上行包發出去時間及下行接收到的時間差，將這個時間差減去基站內部處理時延，既可以得到傳輸時延了。通常基站內部處理時延正常值為6ms。使用QXDM抓包時注意把所有LTE相關設置都選上，否則可能引起MAC層抓包不全，無法記錄下所有上下行數據包的信息。抓包完成后，使用QCAT把記錄的LOG打開，并使用以下條件過濾，見下圖：Ping包是32字節，在加了各個協議層的開銷之后，在MAC層看到的就是引L-niJRLWj29恥Me.■:ec?IJI141^M3；n8-^n￥T^^ETZ...iiL:..J:_—LdtL■iill?Ik■Lrur-■:.■-r?'■-IM-Hr；>rjIth-'t--i/NT'awid、牝司I"1ILJrllw1*11A*rH[<-r"I.-:iiJHiT曰FlHF.Vliwh*nluprMlDK<1iphifMaIfjmjaMan]iiaiew%[寸bomarft:tHr*項1m.yiKJinIZHmEHDm]ST?-FFMLtTfl丁口町1"匚撕AdjcdFB■iX，Etebln]頑[trjKi*fcTKTUfl：cjIci]SIE9血/*皿11tsr:Ca93llh.j?:aJ:C7Kelv1-1明虞WuiInanw-Prnud；wn-lmGic:tt-UJJ.kSOl.iU.Mf-L1!],On-：W.GL.U.12|r|i*l1"iil■bl?"，■■；AIIIIMS：：K*+fr也Ir?||r：i■：>:￥rllw1*11A*rH[<-r"I.-:iiJHiT曰FlHF.Vliwh*nluprMlDK<1iphifMaIfjmjaMan]iiaiew%[寸bomarft:tHr*SIE9血/*皿11tsr:Ca93llh.j?:aJ:C7在0xB064LTEMACULTransportBlock中找到LCID為3或者4，長度為64的包，為UE側數據包發出的時間。在上行數據附近的0xB063LTEMACDLTransportBlock找到LCID為3或者4，長度為64的包，對應的幀號子幀號為UE側收到ping包的ACK的時間，如下：I?IE5FIITnEILEGPlUDGIi際頑|n■:IriaantlISfT|^j^n|wrTn-a|IE^T>|4|I，|r-EJTilIfil~-ari|Ii|r-arilIi|!u-i￡irE|Ii|L-airx|Ii|匚由駐|的raIfiilL-13!III?IE5FIITnEILEGPlUDGI4|I，|r-EJTilIfil~-ari|Ii|r-arilIi|!u-i￡irE|Ii|L-airx|Ii|匚由駐|的raIfiilL-13!II&iFiidL-1S!III|ruL-3ZIJkficlrhdL-!ZIAtm|lhdL-5±Il-5心壬jlHL-5^|ijxif]]r戲eIjXIF]]EOH3IIXIF31皿皿IIXIF]]C>3IEi：xifaaeta■I軍iFa誼ital|E￡iF93maar-oirij■dkB|Hii[a[wadnrivtiI1-5113|F-LIl|?IF1X13。1C-JTTIIC-1TT]7:.TJI1D|列1ml，l1L跑*LFLF，ip血出iF業空|21-11-L|1汕31C-JKTIIQ51TI111跆M131131Pt^un^l-U,CJSIJ0dI11LF~nPaiHLvrl-lI圖3-16：MAC層消息采集故上述ping包在網絡側的時延為5448(DLreceive)-5441(ULsend)=7ms。基站側內部處理時延正常的情況下，S1口時延為7ms-6ms=1ms。3.5隨機接入基本過程在小區搜索過程之后，UE與小區取得了下行同步，因此UE能夠接收下行數據。但UE只有與小區取得上行同步，才能進行上行傳輸。UE通過隨機接入過程(RandomAccessProcedure)與小區建立連接并取得上行同步。控制面時延主要關注接入過程中MSG1-5的時延。目前皿MSG1-MSG5的空口時間，在CPE的LMT上都可以看到，信令的lot號就是空口時間。_!'Flf『■布_!'Flf『■布7>=■RUtmMlL^KX^k3t■HJjl1.fl圖3-17:隨機接入過程3.6接入時延優化過程3.6.1時延目標流程msg1-msg2實測3ms目標3msmsg2-msg3實測5ms目標3msmsg3-msg4實測17.5ms目標msg1-msg2實測3ms目標3msmsg2-msg3實測5ms目標3msmsg3-msg4實測17.5ms目標6.5ms需優化msg4-msg5實測5.5ms，目標3.5ms下行NR2.0|宜:3口1I34：或:5911：11213ALSISIT1?01Z34587EI'DIL111314LiJ617U：9IT0CLusesICFIFmiITEC3ITSG4IFHT.IDEPF￡<-XPX3.5ts■CFf■Ft=eI■圖3-18:各流程時延目標3.6.2控制面時延的優化方案Msg1-Msg2實測值與目標值一致，時延正常。Msg2-Msg3CPE收到msg2之后，CPE內部處理時間CPEProcl太長，CPE側進行進程優化，使得msg3提前了4個slot（2ms）出空口，從而滿足時延要求。

Msg3-Msg4①msg3->msg4的流程圖圖3-19：圖3-19：MSG3-MSG4流程圖②mcc->pps/mcc->spa流程圖UC發出UE上下文給MCC，在此過程中存在板間傳輸時延（VSW->VBP）,MCC先給PPS發上下文消息（因為SPA建立上下文需要PPS生成的UEID），后PPS將消息通過調用平臺OP接口發給MCC，之后MCC給SPA的組件SMC發上下文消息，SMC的啟動時間是每個slot的起始位置offset=0，錯過后SPA只能到下個slot收到上下文消息，SMC再給UAC配置上下文消息，從圖中看出RAC在200微秒的位置啟動，UAC在310微秒的位置啟動，所以UAC微秒的位置啟動，所以UAC收到上下文后，不能在slotN給RAC調