RRU共小区方案提高GSM频谱利用率.doc

资料编码产品名称GSM-BSS使用对象方案开发产品版本编写部门服务方案开发资料版本V1.0RRU共小区方案提高GSM频谱利用率拟 制：徐开平 00143936日 期：2011-6-29审 核：日 期：审 核：日 期：批 准：日 期：华 为 技 术 有 限 公 司版权所有 侵权必究修订记录日期修订版本描述作者2011-6-29V1.0多RRU共小区提高GSM频谱利用率的方案构思徐开平关键词：RRU共小区、GSM频谱利用率、Re-farming摘 要： 近两年基于不同客户对就提高频谱利用率的诉求，各大提供商通过新技术手段提出了不同的解决方案，试验结果各有千秋，但随着频率复用率的提高都伴随着一定的KPI恶化。针对这一情况本文提出采用多RRU共小区方案，从资源共享可提高业务承载角度提高频谱利用率的方法。并结合T运营商某区域网络实例，从容量提升、改造费用两方面着手讨论。缩略语清单：参考资料清单：R13_高速覆盖性能解决方案GSM RRU共小区组网解决方案Refarming服务解决方案背景1. 2008年印度政府授予GSM新牌照运营商4.4M频谱，预计话务量增加后免费扩展到6.2M频谱满足运营商要求。但随后政府因为2G腐败案至今未承诺另外1.8M频谱资源的兑现，并有可能对剩余频率资源进行拍卖，起拍1.8M频谱全国license达到165亿卢比（合3.5亿美元）。基于现网4.4M频谱，很多业务比较好的运营商都面临网络拥塞造成KPI恶化。同时相对于过低ARPU值，新增基站将面临盈利压力，因此运营商都希望寻求在现有频谱、现有站点基础上增加容量的技术解决方案。2. 随着UMTS、LTE的的推广，GSM频率re-farming在很多国家得到应用。但是针对频谱少于8M的运营商在计划UMTS re-farming时很可能会面临GSM网络容量问题，如目前8M左右频谱的运营商3G re-farming方案应用后可用于GSM的频点只有3M，5-6M频谱的运营商通过1.4/3M LTE re-farming频谱资源支持的站型（如S211）很难满足话务需求。 运营商也希望寻求能够平滑承载现网GSM业务的解决方案。多RRU共小区方案多RRU共小区技术设计本来是为了满足高速铁路/隧道频繁切换场景下的解决方案。但是频率资源受限的场景可以考虑，多RRU共小区技术用于市区宏基站。如图：图 1 使用多RRU共小区技术前后网络蜂窝结构此时将三个小区(定向)改全向，在不改变基站总TRX数的情况下，受益于小区间载频资源/频率资源共享，同GOS可以承载可以更高的话务量。那么通过定向改全向如何增加容量呢？具体增加多少话务承载呢？我们可以通过印度新牌运营商的4.4M频谱资源举例。在考虑TCH和BCCH邻频影响可以容忍的情况下，目前印度新牌运营商普遍规划为BCCH采用4x3规划： 12 频点TCH采用1x1跳频： 10频点网上主流容量站点配置为S332,S422.如果采用多RRU共小区方案，按照成熟的规划方法为： BCCH采用7x1规划：7频点BCCH/TCH隔离频点：1频点TCH采用1x1跳频：14频点考虑满足1/2跳频负荷的情况下，支持最大配置S8.两种方案业务承载能力如下：（考虑到现网PS业务主要为动态信道，计算中统一为CS业务。加上手机因素，最高半速率比例上限在80%左右）普通定向解决方案多RRU共小区方案典型站型S332S422S8TCH数TrafficTCH数TrafficTCH数Traffic100%FR, GOS=2%CELL0/12214.93021.96049.6CELL22214.9148.2-CELL3148.2148.2-SITE3838.349.6HR占50%, GOS=2%CELL0/1292140318068.7CELL229211912.3-CELL31912.31912.3-SITE54.355.668.7HR占80%, GOS=2%CELL0/13627.35040.310088CELL23627.32315.8-CELL32315.82315.8-SITE70.471.988从上表对比可以看出，在GOS取2%时，100%全速率场景下，多RRU共小区方案比普通定向方案单站承载容量提升30%50%半速率场景下，多RRU共小区方案比普通定向方案单站承载容量提升23%-26%80%半速率场景下，多RRU共小区方案比普通定向方案单站承载容量提升22%-25%在3MHZ频谱下采用多RRU共小区方案（S4），单站承载容量可以比S211提升50%。如果再考虑到三小区方案因为话务不均衡问题造成的的拥塞，多RRU共小区方案实际容量提升比例更大。关键技术可行性分析1. BCCH 全网7x1邻频规划组网的实现全向小区7x1规划是蜂窝技术中典型方法，在频率复用同频属性上已无争论。但是如上图 1， 在特定背景下，实现BCCH 7x1规划的频点将是连续的7个邻频频点，而有别于GSM初期采用的间隔频点如选择1,3,5,7 针对该问题，可以考虑用于re-farming方案的180Khz滤波属性（GRFU/MRFU, RRU3008），降低邻频的影响。在上行接收灵敏度方面还可以考虑开发新的多天线接收技术，充分发挥多共小区的优势。另外，由于BCCH7x1全邻频组网方案只涉及BCCH上的干扰问题，只选择大于3个7x1蜂窝的区域，通过信道分配优先级的设置，很容易对BCCH进行CS满负荷以及PSCS业务满负荷压力测试。2.共小区RRU载波限制前面提到多RRU共小区技术设计目的是为了高铁覆盖，话务负荷不会过高，设备主要支持6TRX共小区。如果采用该技术被用于提高频谱利用率，首先要满足的是4.4M以上带宽条件需要支持大于8TRX共小区。另外考虑900M频谱re-farming后，部分双频运营商会采用同心圆技术组成900M1800M双频小区，最基本的配置会是8TRX+8TRX共小区的情况。关于共小区TRX的限制，想要产品侧确认。方案应用该方案应用主要是目前频带低于5M的运营商和未来900M 频率re-farming（UMTS/LTE）后剩余的低于5M带宽上组网。硬件1. 针对现网4M以上频谱的运营商，其RFU模块应该是1GRFU/MRFU或者1-2DRFU，采用多RRU共小区时的话务站点配置应该在6-10TRX。考虑到功率问题，推荐采用双GRFU/MRFU配置。硬件成本方面运营商每站需要增加3个GRFU，或者DRFU更换GRFU，成本比较高，现阶段被采用的可能性不大。但对非大话务站点，可以利用现网GRFU配置4-5TRX共小区2. 针对re-farming策略，增量配置准则应该为MRFU，对于GSM话务量已经明显降低的情况，可以保留1个RFU支持4-5TRX共小区策略，另外的MRFU可以直接用于re-farming.如果运营商保留给GSM的频谱在4M以上，在GSM话务量未明显降低前使用双MRFU配置，选择其中一个MRFU作为GL共用模块。随着GSM业务向LTE转移，GSM占用RFU可以逐渐过渡到1个RFU。硬件方面re-farming场景主要考虑利用现网硬件资源，少量站点硬件投资。软件和服务1. 首先多RRU共小区高铁覆盖方案已经得到业界认同，方案导入前后网络总TRX数基本不变而容量增加，客户在获益之后很容接受license付费。且功能可在设备上用license控制。2. 因为方案执行时小区结构发生了很大变化，站点集成服务将是必须的。硬件调整方面视是否增加RFU模块而定，但是都不需要涉及天线部分的服务，成本可控。服务方面也可以参考基站扩容服务。3.NTS服务方面主要是小区结构改变后的详细规划，该方面服务成本/价格可以根据现有基线按基站计算。另外方案导入总体方案应该归属NTS服务，针对具体国家情况，方案实施前后实行网络质量保障。整个服务可以参照搬迁割接服务等级。主要服务为DT monitoring，OMC 48小时monitoring， 方案导入后的RF例行优化及现场培训。相关技术应用同时在引进多RRU共小区技术后，还可以考虑的频率利用率提升技术有：IBCA方案：（Interfere Based Channel Allocation），基于频率软复用SFR（Soft Frequency Reuse）算法，减少小区边缘干扰。同心圆方案：为不同的小区簇选择不同的外圆跳频频率，减少小区边缘干扰。可参考LTE的部分频率复用方案FFR，(Fractional Frequency Reuse)多天线接收技术：可以在现有4天线接收基础上开发6天线接收，也可以改进算法动态选择6路接收天线信号中的4路，保证选择用户所在方向2路天线信号和另外两小区各1路信号。F.A.Q1.根据GSM基本理论，提高频谱利用率的方法是小区分列（故意错别字）。现在小区是定向了，为什么你说将小区合并反而能提高频谱利用率呢？通常小区分 列是全网提高频谱利用率的正常手段，但是代价是增加更多基站，所以那只是理论。现实中运营商必须考虑每个基站的利益最大化，当然也就是如何利用最少的频率做到单个站点的最大业务承载。对GSM理论，频谱资源固定的情况下，通过合并小区得到的容量总是比分 列小区的方法提供的业务量更高。2. 但是为什么GSM一直采用的是三扇区覆盖，而未采用全向覆盖或者定向天线的共小区技术呢？答; a，受限覆盖功率问题，大家都知道3. 关于7*1 规划：其实7*1规划的同频干扰出是现在第四层邻区上，按照全向蜂窝7*1规划同频复用距离为4.65R，如果按照本文提及的规划方法，同频复用距离是3.97R， 且这时候的小区半径的概念已经扩大为原来定向小区的覆盖距离。4.关于改全向站后的优化调整：本文所述的改为全向并不是替换天线，而是在现有定向天线的基础上将三个扇区合并为一个小区。至于RF优化调整，可以完全集成定向基站的天线属性。