APP下载

TD—LTE设备大容量性能及测试方案研究

2017-03-07韩延涛王东李秋香徐晓东

移动通信 2016年22期

韩延涛 王东 李秋香 徐晓东

摘要:随着TD-LTE用户数量的不断增多,需要对设备大容量性能进行深入研究。重点研究了用户接入网络流程、设备大容量规格及资源管控机制,同时,研究了设备大容量性能的测试方案,最后给出实验室性能测试验证的结果。

关键词:CAPS RRC连接建立用户数 接入控制 拥塞控制

1 引言

随着TD-LTE用户数量的不断增多,在大型体育赛事、演唱会、高校等场景,TD-LTE用户大量聚集,形成典型的大话务场景,短时间内大量用户发起业务,对TD-LTE设备造成显著冲击,情况严重时将导致无线接通率急剧下降,用户感知水平显著降低。

TD-LTE基站具有恒定的系统大容量能力,其与基站主控板和基带板CPU能力和软件设计能力密切相关,基站的大容量能力包括CAPS(Call Attempt Per Second,每秒呼叫尝试建立数量)能力和小区支持的用户数量。CAPS能力衡量了基站处理并发信令的接纳能力,TD-LTE终端每次业务接入/释放、位置更新等行为需通过与基站信令交互来完成,2G/3G设备(BSC/RNC)有单独的信令控制单板,4G基站的主控板和基带板各负责处理一部分信令,主控板和基带板CPU处理能力是有限的。当大量用户同时接入小区时,CPU会瞬时冲高,CAPS能力较高的基站设备可同时处理较多数量的信令。小区支持的用户数量衡量了基站对用户数的保持能力,是基站承載能力的上限,当小区用户数超过其系统容量时,会导致部分用户无法接入,已接入用户的感知也会受到影响。

面对当前大话务场景的不断增多,需要对TD-LTE基站的大容量能力及测试方案进行深入研究,避免在用户数量过多时,基站设备负荷过高,造成基站宕机等恶劣后果。

2 TD-LTE设备大容量性能研究

2.1 终端访问网络流程

一般来说,终端访问网络包括两个流程,先是接入网络,再是分配资源。前者是随机接入流程,后者是控制信道及业务信道分配流程。随机接入是终端与网络之间建立无线链路的必经过程,只有在随机接入过程完成后,基站和终端才能进行常规的数据传输和接收,通过随机接入流程,UE可以实现与eNB之间上行同步并申请上行资源。随机接入流程如图1所示,分为5步完成,每一步称为一条消息(Message),在标准中将这5步称为Msg1~Msg5。

(1)Msg1:发送Preamble码。该消息为上行消息,由UE发送,eNB接收。Preamble码由PRACH承载,PRACH个数与时频位置都通过系统消息通知UE。PRACH一定位于上行子帧或者UpPTS。

(2)Msg2:随机接入响应。该消息为下行消息,由eNB发送,UE接收。该消息必须在随机接入响应窗内发送。UE通过检测Msg2中是否携带了其所发送的Preamble码标识来判断是否收到了随机接入响应。

(3)Msg3:第一次调度传输。该消息为上行消息,由UE发送,eNB接收。UE正确接收Msg2后,在其分配的上行资源中传输Msg3。针对不同场景,Msg3中包含不同的内容。针对初始接入,携带RRC连接请求消息;针对连接重建,携带RRC连接重建请求消息;针对切换,传输RRC切换完成消息以及UE的C-RNTI,在资源允许的情况下可同时传输BSR。

(4)Msg4:竞争解决。该消息为下行消息,由eNB发送,UE接收。eNB和UE通过Msg4完成最终的竞争解决。Msg4和Msg3内容相对应。

(5)Msg5:随机接入完成。该消息为上行消息,由UE发送,eNB接收。针对不同场景,Msg5中携带不同内容,比如针对初始接入,携带RRC连接请求完成消息。

从随机接入流程中能够看到,终端接入到LTE小区需要向基站先后发送Msg1、Msg3和Msg5消息,基站对以上消息的处理能力在一定程度上决定了终端接入小区的时延。

考虑到基站空口无线资源及设备硬件资源有限,基站只能支持一定数目的RRC连接用户数、小区激活用户数以及承载数目。因此,在终端随机接入网络时,基站需要对接入请求进行接入控制。在保证用户数和接入承载QoS的情况下,尽可能多地接入用户并保证新接入承载QoS,提高系统容量和资源利用率。

终端随机接入到网络后,基站根据其数据传输请求为其分配上下行资源,LTE系统中数据传输包括上行调度和下行调度两个过程。上行调度时,UE通过PUCCH发送SR(Schedule Request)向eNB请求上行资源,eNB通过PDCCH将资源分配结果告知UE,UE即可知道在哪个时间哪个载波上传输上行数据以及采用的调制编码方案,eNB在每个TTI动态给UE分配资源,并在PDCCH上传输相应的C-RNTI。下行调度时,eNB根据UE上报的下行信道质量为UE分配下行资源,并在PDSCH根据资源分配结果填充数据,并在PDCCH上传输C-RNTI。

2.2 4G基站的大容量规格及资源管控机制

从2.1节终端访问网络流程能够看出,TD-LTE基站和列车车厢非常类似,同样具有“车门”和“座位”,终端通过随机接入流程接入TD-LTE无线网络,类似于乘客通过“车门”进入车厢。车厢中的“座位”数量是有限的,同样地,基站支持接入的用户数和承载数量都是有限的。基站为终端分配上下行资源的过程类似于乘客在车厢找到相应“座位”的过程。

为了规范基站的“车门”宽度和“座位”数量,在通信领域,有两个重要的衡量指标,一个是设备的CAPS能力,另一个是设备的容量。此外,接纳拥塞控制机制保证了终端顺利通过“车门”,找到“座位”。

(1)CAPS能力(基站“车门”宽度)

CAPS指的是设备处理并发信令的接纳能力,也就是“车门”的宽度,衡量基站每秒处理进出信令流量的能力,基站的CAPS能力与其硬件能力密切相关。根据随机接入流程的特点,终端需要先后向基站发起Msg1、Msg3消息接入系统,基站需要先后处理Msg1、Msg3消息。4G小区车厢拥有两道“车门”,其一处理Msg1消息,一般由基带板承担;其二处理Msg3消息,一般由主控板承担(部分厂家设备Msg3消息也由基带板处理)。因此,TD-LTE基站CAPS及容量示意图如图2所示,其中,左侧圆柱体表示基站的两道“车门”,右侧的绿色方框表示基站的车厢容量,橙色小方框表示“车座”。

基站主控板和基带板的处理能力都是有限的,每一条信令消息都将消耗主控板或者基带板CPU资源,CPU负荷反应了CPU资源的使用情况。当终端均匀接入TD-LTE小区且单位时间信令进出流量低于基站CAPS能力时,信令通行速度顺畅,用户可较快接入小区。当小区中存在大量终端频繁发起业务触发随机接入时,并发的信令流量大于“车门”宽度,导致信令拥塞,CPU负荷随之升高,信令处理能力随之降低。在较为极端的情况下,并发的信令流量会瞬间冲高且伴随着信令雪崩效应,可能会导致CPU以极高负荷运行并最终导致单板复位、宕机。譬如同时寻呼单小区中所有用户场景下,假设小区中存在300用户,TD-LTE系统能够在1 s内寻呼到所有用户(1 s最多可寻呼1600用户),300用户会在1 s内向基站发起随机接入请求,基站仅能同时处理部分用户。根据协议,若某个UE未收到Msg2,该UE将在10 ms后重发Msg1,若未收到Msg4,将在64 ms后重发Msg1,大量信令重发将继续增大信令接入压力,造成信令雪崩效应,可能会导致基站系统彻底瘫痪、宕机。Msg1信令雪崩效应示意图如图3所示:

因此,为了确保通信系统安全运行,一方面需要提高CAPS能力,另一方面必须为CPU运行设置安全门限,采取适当、合理的过载保护机制。譬如,當CPU负荷超过一定门限时,基站启动过载保护机制,保护已接入用户的体验并丢弃部分新接入用户的信令消息。基站设备CAPS能力并非要求无限高,其评估量化原则是保障并发用户接入时延体验,这在大话务场景表现地尤为明显。比如说,小区中有100个用户同时发起网页浏览业务,如果设备CAPS能力为20,所有人能够浏览网页需要5 s时间,如果设备CAPS能力为100,所有人能够浏览网页需要1 s时间。因此,在量化CAPS能力时,用公式(1)进行量化。

CAPS=并发用户数/用户接入时延 (1)

(2)设备容量(基站“座位”数量)

基站容量指的是基站支持RRC连接用户数及有效RRC连接用户数(或称激活用户数)的保持能力,也就是基站的“座位”数量,它衡量了基站业务承载能力的上限。RRC连接用户是指处于RRC Connected状态的UE,可以监听下行控制信道获知是否有上下行数据需要传输。有效RRC连接用户是指上行或者下行调度Buffer中有数据的用户,该部分用户一定处于RRC Connected状态,而且有数据传输的需求。基站的硬件以及软件设计决定了其支持的RRC连接用户数及有效RRC连接用户数能力。对于有效RRC连接用户数的统计,3GPP协议规定的测量采样周期最多为100 ms,对周期T内的采样数据进行平均后获得有效RRC连接用户数值。

运营商对基站设备的容量均有明确规定,如中国移动企标中要求设备支持1200 RRC连接用户数和400有效RRC连接用户数;对于VoLTE业务,在保证VoLTE业务性能的前提下,时隙配比3DL:1UL时,支持高清12.65 k/23.85 k有效RRC连接用户数不低于250/200;时隙配比2DL:2UL时,支持高清12.65 k/23.85 k有效RRC连接用户数不低于500/400。

在现网应用时,上下行空口资源会影响到小区实际容纳的用户数量,由于中国移动采用3DL:1UL时隙配比方案,一般来说上行空口资源(包括PUCCH及SRS等)会成为用户数量瓶颈。PUCCH承载的内容主要是SR(调度请求)、ACK/NACK和CQI,通过配置PUCCH PRB数量及PUCCH各参数及SRS的周期,可以有效地控制小区用户数量,PRB数量越多、周期越大,可容纳的用户数量越多。

(3)资源管控机制

设备的大容量规格是设备能力的上限要求,资源管控机制的目的是在最大化资源利用率时,通过接入控制和拥塞控制保持系统的稳定性。

1)接入控制机制

接入控制的主要作用是在基站收到新的业务请求时,根据请求的资源要求、小区当前资源使用状况等,决定是否接纳业务请求,以防止新的业务接入后系统出现过载状态,从而保持系统稳定。同时,在资源允许的情况下,尽可能多地接入业务,从而充分利用系统资源,提高系统的容量,降低运营成本。

接纳控制场景可包括空闲态下初始业务请求、连接态下无线承载激活、切换请求等。接纳控制的判决因素包括激活承载数、连接态UE数量、PRB利用率等。

2)拥塞控制机制

拥塞控制是在基站出现系统拥塞的情况下,进行合理的资源控制。TD-LTE系统的拥塞控制一般区分信令和数据,拥塞控制启动需要满足一定条件,即监控负载状态达到拥塞状态。对于信令,拥塞状态一般通过主控板、基带板CPU占用率来进行判定,当CPU占用率高于门限时,采用渐进式方式限制Msg2或者Msg4的响应次数,对部分RRC建立请求回Reject消息来降低信令风暴的风险。对于数据,拥塞状态的判定一般通过PRB利用率或者QoS业务满意率评估,当小区拥塞后,从当前已接入业务中选择低优先级业务进行释放,或者通过切换、重定向迁移部分用户至异系统小区。

3 设备大容量性能测试方案

根据TD-LTE基站处理信令的特点,系统CAPS能力可以用系统每秒正确处理的Msg3消息的数量进行衡量,正确率(Msg5/Msg3)不低于95%。测试方案需要模拟现网大量信令并发的场景,通过终端测试仪表记录设备Msg3的处理数量,进而计算得到设备CAPS能力。

系统容量性能可以通过验证小区内接入及进行数据传输的用户数量进行判定,根据现网中用户不断动态接入的现实情况,测试方案中模拟了信令动态接入的场景,同时利用终端测试仪表检测小区中的RRC连接用户数和有效RRC连接用户数。

系统吞吐量的测试可以有效验证系统的整体性能,其测试方案也需要考虑信令的冲击。

3.1 第一类:设备CAPS能力及容量性能测试

(1)用例一:信令冲击场景,设备CAPS能力和RRC连接用户数性能测试

测试方法:

1)通过终端测试仪表设置1200个用户,分别以每秒20、50、100、200、400的速率通过Attach接入小区,并处于RRC Connected状态。

2)持续信令冲击10分钟,记录RRC连接建立成功率、RRC连接用户数、每秒Msg3消息数量等。

考察点:

1)系统稳定性:每种冲击场景,设备无退服、宕机现象。

2)RRC连接用户数性能:基站支持的RRC连接用户数。

3)CAPS能力:记录不同冲击粒度时,基站每秒钟处理Msg3消息的数量和RRC连接建立成功率(Msg5/Msg3),RRC连接建立成功率为95%时的Msg3消息处理数量即为设备的CAPS能力。

(2)用例二:信令冲击场景,设备CAPS能力和激活用户数性能测试

测试方法:

1)通过终端测试仪表设置400个用户,分别以每秒20、50、100、200、400的速率通过Attach接入小区,并进行上下行数据传输。

2)持续测试10分钟,记录RRC连接建立成功率、激活用户数、每秒Msg3消息数量等。

考察点:

1)系统稳定性:每种冲击场景,设备无退服、宕机现象。

2)激活用户数性能:基站支持的激活用户数。

3)CAPS能力:同用例一。

3.2 第二类:设备吞吐量性能测试

(1)用例三:设备峰值吞吐量性能测试

测试方法:配置单站支持六小区,每小区接入共400用户,分别进行FTP上行業务、FTP下行业务、FTP上下行并发业务,测试系统峰值吞吐量。

考察点:峰值吞吐量。

(2)用例五:设备平均吞吐量性能测试

测试方法:

1)静态模型:配置单站支持六小区,每小区接入400用户,按照极好点(SINR>22 dB):好点(SINR 15 dB ~20 dB):中点(SINR 5 dB~10 dB):差点(SINR -5 dB~0 dB)=2:4:8:6的比例进行分布,进行FTP上下行吞吐量测试。

2)动态模型:配置单站支持六小区,每小区接入400用户,按照静态模型的比例分布用户,并以60 km/h的速度运动,进行FTP上下行吞吐量测试。

考察点:平均吞吐量,静态模型和动态模型下,系统平均吞吐量。

(3)用例六:信令冲击场景,设备吞吐量性能测试

测试方法:

1)通过终端测试仪表设置400个用户,分别以每秒20、50、100、200、400的速率通过Attach接入小区,并进行上下行数据传输。

2)持续测试10分钟,记录上下行吞吐量。

考察点:冲击场景设备上下行的吞吐量性能。

(4)用例七:典型业务下的系统吞吐量性能测试

测试方法:配置单站支持六小区,每小区接入400用户,按照一定比例对400用户进行分组,分别进行FTP、HTTP、UDP、Ping大数据包/小数据包业务,测试系统吞吐量及PRB使用数量。

考察点:系统吞吐量和PRB使用数量。

4 测试结果分析

按照第3节的测试方案对厂商A和厂商B的设备进行测试,本节重点分析设备CAPS的测试结果,通过测试结果分析,可以有效地验证设备的CAPS能力以及其资源管控机制。

厂商A测试结果如图4所示,当每秒接入用户数为20~200时,RRC连接建立成功率(Msg5/Msg3)均满足95%要求,而且设备每秒处理Msg3数量也在9~19的范围内,因此该设备的CAPS能力小于20。

当每秒接入用户数从20逐渐增加到200时,虽然Msg5/Msg3比率保持在95%以上,但Msg5/Msg1比率逐渐下降,说明当每秒接入用户数高出设备CAPS能力后,随着CPU负荷的不断升高,系统开启了拥塞控制机制,并优先限制了Msg2消息的响应次数。

设备支持的RRC连接用户数在1000左右,可由绿色曲线得出。

厂商B的测试结果如图5所示,当每秒接入用户数为20~40时,RRC连接建立成功率(Msg5/Msg3)均满足95%要求,而且设备每秒处理Msg3数量也在20~40的范围内,因此该设备的CAPS能力在40左右。

当每秒接入用户数高于40时,Msg5/Msg3和Msg5/Msg1比率开始不断下降,且下降趋势大致相同,说明当每秒接入用户数高出设备CAPS能力后,系统开启了拥塞控制机制,并优先限制了Msg4消息的响应次数。

设备支持的RRC连接用户数在1200左右,可由绿色曲线得出。

5 结束语

设备大容量性能是TD-LTE系统的重要指标,本文重点介绍了TD-LTE系统的大容量规格及资源管控机制以及大容量性能的测试方案,包括设备的CAPS能力、RRC连接用户数及有效RRC连接用户数和吞吐量性能,通过对测试结果进行分析可知,测试方案可以有效验证设备大容量性能。

参考文献:

[1] 3GPP TS 36.211. Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation, Release 8.9.0[S]. 2009.

[2] 3GPP TS 36.211. Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation, Release 9.1.0[S]. 2010.

[3] 贾民丽,刘林南,余立,等. TD-LTE网络容量评估方案研究[A]. LTE网络创新研讨会[C]. 2014.

[4] 3GPP TS 26.101. Mandatory speech codec speech processing functions; Adaptive Multi-Rate (AMR) speech codec frame structure[S]. 2009.

[5] 3GPP TS 36.322. Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification[S]. 2013.

[6] 3GPP TS 36.300. Evolved Universal Terrestrial Radio Access (E-UTRA); Overall description[S]. 2010.

[7] 3GPP TS 36.212. Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and channel coding[S]. 2010.

[8] 3GPP TS 36.213. Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures[S]. 2012.

[9] 3GPP TS 36.321. Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification[S]. 2015.

[10] 3GPP TS 36.331. Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC) Protocol specification[S]. 2009.★