文献标识码:A
文章编号: 0258-7998(2013)07-0103-03
LTE(Long Term Evolution)项目是3G的演进,是3.9 G的全球标准,它改进并增强了3G 的空中接入技术。相比3G,LTE在系统带宽、网络时延、移动性方面都有了跨越式的发展。在LTE 中多用户、小数据量的应用(例如VoIP)其数据包的大小相对比较固定,而且数据包之间的时间间隔也满足一定的规律性,针对这种业务,LTE提出了一种全新的调度方式——半静态调度SPS(Semi-Persistent Scheduling),而HARQ(Hybrid Automatic Repeat reQuest)对保证传输质量有着重要作用。相对于下行资源,上行资源更为宝贵。为此,首先介绍了上行调度中的半静态技术以及其HARQ操作,着重分析了HARQ过程中造成的资源碰撞问题并提出了解决方案。
1 半静态调度传输
演进基站eNB(evolve Node B)在连接建立时就配置好半静态调度的参数,再通过PDCCH激活半静态调度。一旦SPS调度被激活,UE将认为在固定周期的子帧上存在固定的频域资源进行数据的收发。可见,SPS调度具有一次授权、周期使用的特点,这非常适合VoIP、视频流等IP业务的传输。半静态调度传输,可以充分利用话音数据包周期性到达的特点,一次授权,周期使用,可以有效地节省LTE系统用于调度指示的PDCCH资源,从而可以在不影响通话质量和系统性能的同时,支持更多的话音用户,并且仍然为动态调度的业务保留一定的控制信息以供使用。
完整的半静态调度传输分为4个步骤:半静态参数配置、半静态调度激活、上下行半静态传输与HARQ以及半静态调度释放。本文主要着重分析上行半静态调度机制及其HARQ过程。
1.1半静态参数配置(上行)
网络端RRC在连接建立时将参数配置给UE端的RRC层,经UE端RRC层解析出来之后保存,同时发给底层的MAC层。上行半静态调度的主要参数包括:
semiPersistSchedC-RNTI
上行半静态配置:
semiPersistSchedIntervalUL
ENUMERATED{10 ms,20 ms,32 ms,40 ms,64 ms,80 ms,
160 ms,320 ms,640 ms}
impliciReleaseAfter
ENUMERATED{e2,e3,e4,e8}
twoIntervalsConfig
ENUMERATED{true}
1.2 上行半静态调度及HARQ过程
第N次半静态数据传输的位置可以由下面的公式推算得出:
(10×SFN+subframe)=[(10×SFNstart time+subframestort time)+
N×semiPersisSchedIntervalUL]mod 102 40
这里,SFN为上行半静态数据传输的无线帧号,subframe为上行半静态数据传输的子帧号,SFNstart time与subframestort time上行半静态调度激活后第一次半静态数据传输对应的无线帧号和子帧号,其中,N≥0,N=0对应激活后的第一次上行半静态数据传输。
LTE协议中规定,对于上行半静态传输,数据的重传方式可以是同步自适应HARQ或同步非自适应HARQ两种方式,非自适应重传用的是上一次传输所使用的资源和调制编码方式。上行为同步HARQ,数据的初始传输以及重传都有固定的时间间隔,所以会存在半静态数据的非自适应重传和周期性到达的新数据的碰撞问题,降低了资源利用率,本文以TDD(Time Division Dual)简述存在的碰撞问题。
对TDD上下行配置2,上行半静态周期(semiPersistSchedIntervalUL)10 ms,如图1所示。
UE在子帧3收到SPS C-RNTI 扰码的PDCCH,且DCI和NDI均符合半静态激活条件时,在子帧7上进行半静态调度的初始传输,且每隔10 ms发送一次上行数据。在子帧3上收到进程0的NACK反馈[1],可以看到,进程1新数据的上行传输和进程0的重传是在同一子帧,从而产生资源碰撞问题。
由以上分析可知,对于进程0,第一次的上行重传就产生碰撞,这对于系统的资源利用率和系统的稳定性有很大影响,对此,LTE提出了双周期半静态调度的解决方案。twoIntervalsConfig值置为true,且对于不同的初始上行半静态调度起始位置,有相对应的子帧偏移(Subframe_Offset)[2],第N次半静态数据传输的位置可以由下面的公式推算得出:
(10×SFN+subframe)=[(10×SFNstart time+subframestort time)+
N×semiPersisSchedIntervalUL+Subforam_Offset×
(N mod 2)]mod10240
其中,N≥0,N=0对应激活后的第一次上行半静态数据传输。针对上面的情况,具体的调度方式如图2。
由图2可以看出,进行双周期配置后上行半静态调度的周期变为:semiPersistSchedIntervalUL+SubframeOffset和semiPersistSchedIntervalUL+SubframeOffset。图2中半静态调度的周期变为5 ms和10 ms交替,且进程0的重传次数由一次变为两次,重传次数的增加对于VoIP等业务的质量有了一定的提升。
2 问题分析及解决办法
在LTE系统中,对于TDD系统,一个VoIP包进行4次传输才基本上可以保证其传输质量[3]。对于上例中所述,相对于无双周期的上行半静态调度,双周期配置的调度方式数据包重传次数增加了一倍,但是对于VoIP的业务质量并有较大的提升。在重点研究了半静态调度的初始调度位置和周期后,提出了以下解决方案。
2.1上行半静态调度周期的选择方案
根据1.2节的分析可以看出,选择一个合适的半静态周期可以相应地增加半静态重传的次数,对于双周期配置,不同的上下行配置和上行半静态初始位置,所对应的子帧偏移(Subframe_Offset)不同,第N1个半静态数据包传输的位置可由下式得到:
SPS initial place+(N1-1)×semiPersisSchedIntervalUL+
Subframe_Offset×(N1-1)mod2
而某个数据的第N2次重传的位置可由下式得到:
Re transmission initial place+(N2-1)×Re transmissionInterval
如果两式相等,则可以判断重传是否与新数据的传输发生碰撞。可以得到下式:
SPS initial place+(N1-1)×semiPersisSchedIntervalUL+
Subframe_Offset×(N1-1)mod2=Re transmission interval place+
(N2-1)×Re transmissionInterval
由于具有双周期配置的上行半静态调度周期是短周期和长周期的交替,故只需选择短周期和长周期上各一个数据包的传输案例,就可以代表整个半静态调度的传输。以第一次和第二次半静态数据包传输为例,针对不同的半静态起始位置,分析满足上述两次传输的重传都满足至少4次传输的semiPersistSchedIntervalUL。
对于上下行配置2,上行半静态调度初始位置7,上行半静态调度周期20 ms,子帧偏移为-5 ms,其新数据的传输次数与处于长周期和短周期的数据传输次数的仿真波形如图3所示,图中横坐标为新进程传输次数,纵坐标为重传数据的传输次数。从图3中可以看出,在SPS周期为20 ms时,处于短周期和长周期的上行进程在第4次重传时才与新数据发生碰撞,相对于上行半静态调度周期10 ms,重传次数增加。
而在上行半静态调度周期40 ms,子帧偏移为-5 ms的情况下,其新数据的传输次数与处于长周期和短周期的数据传输次数的仿真波形如图4所示。
处于长周期和短周期的进程重传次数增加到8次,相对于上行周期20 ms,对于TDD系统,8次重传已经足以保证一个VoIP包的传输质量。
对于不同的上下行配置以及半静态传输起始位置,通过2.1节中的公式仿真并进行分析,满足处于长周期和短周期的数据传输次数至少4次的周期配置见表1。
2.2 碰撞进程延迟方案
碰撞进程延迟方案原理:在上行半静态周期配置较小的情况下,UE端利用2.1节中的公式进行判断,若新数据与重传数据发生碰撞,则延迟发送新进程到下一个半静态发送时刻且将半静态资源用于重传数据的发送,这种牺牲新数据实时性的调度,保证了更多数据包的传输质量,且在周期配置较小的情况下,新数据延迟时间相对较小,对新数据的传输影响也相对较小,同时降低了资源碰撞的概率,提高了系统的性能。具体调度方式见图5。
如图5所示,在上行半静态周期配置10 ms,子帧偏移值为-5 ms时,进程0的重传数据本来与进程2的新数据在子帧7上发生碰撞,这里将新进程2延迟到下一个半静态传输时刻进行传输,这样虽然进程2的新数据传输延迟了20 ms,但是使得进程0和进程1的数据传输次数达到4次,4次重传已基本上可以保证一个VoIP数据包的传输质量,虽然进程2数据的发送延迟了20 ms,但是这种调度提高了整个系统数据包传输的有效性,相对于时延,数据包传输质量的提高给用户带来更好的业务体验。
调度是判断一个系统好坏的重要因素。本文通过对上行半静态调度机制的深入研究,分析了上行半静态调度碰撞的原因,针对不同上下行配置和半静态起始传输位置分别配置具有针对性的上行半静态周期,同时提出并设计了在半静态周期较小时的资源冲突解决方案,通过分析可以看出该方案能够有效提高系统的稳定性和资源利用率。
参考文献
[1] 3GPP TS 36.213 V9.0.1. Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures[S]. 2009.
[2] 3GPP TS 36.321 V9.1.0. Evolved Universal Terrestrial Radio Access (E-UTRA) Medium Access Control (MAC)protocol specification[S].2009.
[3] 白炜.LTE 系统的半静态调度传输解决方案[J].邮电设计技术,2010(01):45-48.