朱濤，趙瓊，應波，宋巍

（1 中國移動通信集團浙江公司杭州分公司，杭州 310012；2 中國移動通信集團設計院浙江分公司，杭州 310012）

1 AICIC技術原理與實現架構

1.1 R8 ICIC標準支持與應用問題

隨著ICIC技術研究深入，其性能增益一直在爭議之中，因此，ICIC技術在LTE R8正式版本中是一項重要但不是必須支持的技術，也導致了部分異廠商設備之間無法進行干擾協調。

1.1.1 ICIC標準支持

LTE R8版本中對靜態ICIC、半靜態ICIC和動態ICIC進行了劃分。

靜態ICIC：無需小區間進行信息交互，小區中心和邊緣的頻帶分配模式在系統的初始化階段就已經確定，并且不會隨著調度TTI的變化而變化。該頻帶分配模式的配置時間周期達到天級或以上。

半靜態ICIC：需要進行一定的小區間信息交互，以便盡快針對網絡干擾和負荷環境的變化進行合適的資源配置，即小區中心和邊緣的頻帶分配模式在系統的初始化階段確定之后，可以隨TTI的變化而變化，一般要經過多個TTI才會進行一次重配置，該協調配置周期可達到秒級。

動態ICIC：理想的動態ICIC應能達到TTI級的資源協調與配置，但是在基于服務或突發性數據業務的多小區調度中，其可行性受到質疑。一般協調配置周期達到毫秒級可認為是動態ICIC技術。

為了支持上述ICIC技術，尤其是半靜態ICIC和動態ICIC，有必要進行適當的信息交互，3GPP標準[1]給出了3種可選測量上報機制建議。

機制1：除了支持頻率選擇性調度和鏈路自適應所需的CQI報告，不增加額外的測量上報機制；

機制2：增加對當前小區和鄰小區的平均路損（包括陰影衰落）的測量上報，每100 ms上報一次；

機制3：在機制2的基礎上再增加對復用頻率集的平均干擾測量上報，每100 ms上報一次。

除了必要的測量上報，半靜態ICIC和動態ICIC還需要進行鄰小區之間的干擾信息交互。鄰區列表由X2接口建立時的登記機制來實現，而干擾指示信息都封裝在負載信息（Load Information）中通過X2接口進行交互[2]。LTE R8定義了2個上行指示參數和1個下行指示參數來進行基站之間的干擾信息交互。

1.1.2 ICIC應用問題

同頻干擾問題一直是LTE網絡建設關注的焦點，中國移動在LTE網絡建設初期就引入了ICIC功能，但是由于現網的X2接口限制以及半靜態和動態ICIC功能的不成熟，現網中應用主要為靜態ICIC技術，根據我們對靜態ICIC功能的仿真結果顯示，如表1所示，在2天線，30%負載場景下，下行靜態ICIC邊緣吞吐率增益為3.83%，可見在建網初期，網絡輕載情況下靜態ICIC增益并不明顯，主要因為LTE系統具有“寬帶組網，窄帶傳輸”的特點，本小區所占用的PRB分布相對于其他小區是隨機分布的，這使得LTE系統本身具備一定的抑制同頻干擾能力[3]，而在高負荷場景下，靜態ICIC由于不能靈活設置中心用戶和邊緣用戶的頻帶分配而損害小區整體吞吐量。仿真結果顯示雖然下行靜態ICIC邊緣吞吐率增益可達10%左右，但是其下行的小區整體吞吐率出現下降。

表1 下行靜態ICIC仿真性能增益結果統計

1.2 AICIC技術引入與實現架構

1.2.1 AICIC技術引入

AICIC技術是一種自適應的干擾協調技術，通過對連片小區的負載與干擾判斷，將需要進行干擾協調的小區接入集中控制器，并開啟AICIC功能。集中控制器根據下連各基站上報的測量信息，感知小區間負載和干擾的變化，并自動配置小區邊緣頻帶模式分配。

對于接入了集中控制器中的小區來說，AICIC技術對其干擾和負載設置判別門限，當LTE小區干擾和負載低于該門限時，采用干擾隨機化策略，即將相鄰小區占用的PRB資源盡量錯開，達到異頻組網的效果；當LTE小區干擾和負載高于該門限時，采用ICIC策略，集中控制器向該小區下達合適的頻帶模式指令，使其與相鄰小區的邊緣頻帶盡量錯開，達到小區邊緣異頻組網的效果。該門限值可以通過不斷優化調整以適應網絡的發展。

目前AICIC可支持4種頻帶選擇模式：1/6頻帶模式、1/3頻帶模式、1/2頻帶模式和2/3頻帶模式，指小區邊緣可用帶寬范圍。集中控制器對各小區的干擾和負載評估主要通過LTE R8的ICIC技術建議的測量上報機制，由基站上報小區CQI、鄰區RSRP、小區PRB占用、小區調度用戶數、邊緣調度用戶數、邊緣PRB占用等參數進行聯合計算。

1.2.2 AICIC實現架構

AICIC技術是針對現網中X2接口部署限制提出的，意在通過增加集中控制器，采用集中式干擾處理來達到基于X2接口的分布式半靜態ICIC的效果，既繞過了X2接口限制，又彌補了靜態ICIC性能增益不理想的缺陷。

如圖1所示，網元eCoordinator即集中控制器，M2000/LMT為網管服務器，集中控制器將基站上報的負載與干擾測量信息匯聚到一起進行集中處理，然后向各基站統一下發干擾控制指令，如頻帶模式分配。在該架構下，基站側只需完成相應的測量上報，如服務小區CQI和負載、鄰區RSRP等并按照集中控制器下達的頻帶模式進行資源調度，所有的數據處理過程均由集中控制器完成，計算量較大，因此建議集中控制器獨立設置在無線接入側，以便更快響應基站的干擾與負載變化需求。

圖1 AICIC組網架構

2 AICIC性能探討

2.1 AICIC單用戶最大增益分析

我們在H城商業中心選擇了2個鄰區進行測試，站間距約360 m，cell1為主測小區，掛高28 m，方向角為210°，下傾角6°，cell2為干擾源小區，掛高37 m，方向角為180°，下傾角11°。在主測小區cell1的近點（SINR≈20 dB）、中點（SINR≈10 dB）及其與cell2的重疊區域的遠點（SINR<5 dB）分別放置1部終端，并進行下行FTP業務。在cell2與cell1的重疊區域放置1部終端，進行UDP灌包。

對比AICIC開啟前后的可調度資源情況，可以發現，位于cell1近點和中點的終端在AICIC功能開啟后，從Index=32的RB至Index=63的RB可調用子載波數降至原來的5%左右，無法進行業務傳輸，而對于cell1的遠點用戶，則僅可在上述32個RB上傳輸數據，可用RB數占總RB數的30%，即1/3頻帶模式。觀察cell2的干擾終端，在AICIC開啟后則不在這32個RB上傳輸數據，這樣，對于兩個小區的重疊區域用戶，就實現了“異頻”調度，cell1小區邊緣吞吐量增益達到了62.8%，如圖2所示，由于位于小區中心位置的好點和中點用戶可用資源降低，其吞吐量也呈現下降趨勢，但是小區總吞吐量沒有明顯波動。

2.2 AICIC多用戶定點場景性能分析

為驗證多用戶場景AICIC增益，我們在上述單用戶場景上增加了一個鄰小區cell3，其與cell1相距約350 m，與cell2相距約510 m，cell3掛高34 m，方向角75°，下傾角12°。

圖2 AICIC單用戶場景吞吐量性能對比

cell2和cell3作為干擾小區進行虛擬加載，主測小區cell1分別在近、中、遠點（遠點位于3小區重疊區域）各放置了3部終端進行FTP下載業務。AICIC開啟前，遠點終端可用頻帶是滿頻帶，AICIC開啟后，遠點終端根據其承載負荷自動選擇1/3頻帶模式，即遠點的邊緣用戶只在1/3頻帶內進行調度，測試結果表明遠點平均吞吐量增益為48.6%，小區整體吞吐量沒有明顯變化。如圖3所示。

圖3 AICIC多用戶場景平均吞吐量性能對比

2.3 AICIC移動場景性能分析

AICIC移動場景測試選用了2.1小節中的2個相鄰小區，cell1為主測小區，在其近、中、遠點分別放置1部終端進行定點FTP下載業務，另外1部終端UE4在cell1小區中心和小區邊緣之間移動并開啟FTP下載業務，cell2作為干擾小區，進行虛擬加載。當終端UE4移動至cell1中心時，集中控制器根據其負載及干擾情況，自動選擇1/3頻帶模式，即中心用戶可用頻帶為滿頻帶的2/3，當UE4移動到cell1邊緣時，自動選擇1/2頻帶模式。如圖4所示，測試結果表明小區邊緣用戶吞吐量增益達到41.53%，總體吞吐量略有提升。

2.4 集中器時延分析

圖4 AICIC移動場景下平均吞吐量性能對比

AICIC需要部署集中控制器，基站到集中控制器的時延決定了AICIC策略對網絡負荷和用戶分布變化響應的及時性，影響AICIC功能的性能增益。我們基于現網的傳輸網絡部署了一臺ECO6910集中控制器，通過向本地區4個不同基站的IP地址輪流發起Ping業務，記錄Ping時延，結果顯示4個基站的平均延時為3.3 ms，時延分布如圖5所示，由圖可知約97.5%的樣本落在2～4 ms之間，相對于半靜態ICIC對X2接口時延不大于20 ms要求，集中控制器的時延完全可以滿足AICIC策略對網絡負荷、用戶分布等信息需求。

3 結論及未來工作

圖5 AICIC部署的集中控制器的時延分析

由于目前LTE基站間X2接口尚未打通，AICIC技術通過設置集中控制器采用集中式干擾協調方式來達到3GPP規范中定義的半靜態ICIC即通過X2接口進行信息交互的分布式干擾協調的性能效果。本文闡述了AICIC的原理與實現架構，并通過單小區的定點與移動場景測試，驗證AICIC技術可以在不損害小區整體吞吐量性能條件下，能夠較大提高小區邊緣的性能增益。同時對基站到集中控制器的時延進行了現網測試分析，結果表明該時延水平完全可以滿足AICIC策略制定需求。

目前測試只驗證了AICIC技術的功能性增益，下一步將選擇現網的連片試點區域，驗證AICIC技術在連片小區中的平均增益，觀察其對不同負載小區的頻帶策略制定，及不同負載下的邊緣用戶增益和小區平均吞吐量增益。

[1]3GPP TR-25.814 Physical layer aspects for evolved Universal Terrestrial Radio Access （UTRA).release 7, v.7.1.0[S].2006.

[2]3GPP TS-36.423 Evolved Universal Terrestrial Radio Access（EUTRA); X2 application protocol （X2AP)[S].2011.

[3]沈嘉，徐霞艷，杜瀅, 等.LTE同頻組網關鍵問題分析[J].移動通信, 2010,10:5-10.