半静态调度SPS专题.docx

半静态调度SPS专题.docx

《半静态调度SPS专题.docx》由会员分享，可在线阅读，更多相关《半静态调度SPS专题.docx（15页珍藏版）》请在冰豆网上搜索。

半静态调度SPS专题

Semi-PersistentScheduling

（SPS，半永久性调度）

一、SPS简介

Semi-PersistentScheduling，简称SPS，半永久性调度，又称为半静态调度。

与动态调度时每个TTI为UE分配一次无线资源不同（通过PDCCH指定），SPS允许半静态配置无线资源，并将该资源周期性地分配给某个特定UE。

简单地说，eNodeB在某个TTI使用SPSC-RNTI加扰的PDCCH指定UE所使用的无线资源（这里将其称为SPS资源），每过一个周期，UE就使用该SPS资源来收或发数据。

eNodeB无需在该子帧（这里将其称为SPS子帧）下发PDCCH来指定分配的资源。

由于SPS有“一次分配，多次使用”的特点，不需要在每个TTI都为UE下发DCI（包括上行或下行的DCI），从而降低了对应的PDCCH开销。

SPS灵活性稍差，但控制信令开销小，适合突发特征不明显，有保证速率要求的业务，主要用于周期性小包业务，如VoIP。

这类业务的timing和所需的无线资源都是可预测的。

目前中兴只针对QCI为1的VoIP语音业务进行SPS。

协议规定只有PCell支持SPS。

这是因为SPS主要应用于低速业务，负载低，没有必要使用多个载波单元。

中兴eNodeB支持20ms和40ms的半静态调度周期。

当半静态调度周期配置为20ms时，语音报文在eNodeB的调度时延较少，VoLTE用户从而可以获得更高的语音质量；当半静态调度周期配置为40ms时，eNodeB支持的SPS用户数翻倍，但语音报文在eNodeB的调度时延将增加，VoLTE用户的语音质量将稍有下降。

SPS周期由eNodeB通过RRC消息传送给UE。

VoIP业务的通话期与静默期状态由PDCP层进行判决，判决为通话期时，激活半静态调度；判决为静默期时，释放已分配的半静态资源；当业务从静默期转为通话期时，需要重新激活半静态调度。

在以下场景下，eNodeB采用动态调度作为半静态调度的补充：

●半静态调度期间的QCI1承载上的大包，RB资源过载时，会动态调度过载的资源。

●半静态初传对应的自适用HARQ重传数据。

●当进入静默期，释放半静态资源，对静默期的数据包采用动态调度。

TDD系统中，协议规定TTIbundling只支持子帧配比0、配比1和配比6，且跟半静态调度互斥。

二、SPS配置

配置了SPS调度的UE才可以同时进行动态调度，所以需要区分PDCCH是用于动态调度还是SPS调度。

因此，配置了SPS调度的UE有2个标志：

一个“正常的”C-RNTI，用于动态调度，在随机接入过程中分配；另一个是SPSC-RNTI，用于SPS调度，通过SPS-Config的semiPersistSchedC-RNTI字段配置。

UE的半静态调度是通过IE:

SPS-Config配置的。

见图1：

图1：

SPS-Config

图2：

RRC连接重配置（SPS-config实例）

三、SPS激活/释放

UE配置了SPS后，还不能使用，必须使用SPSC-RNTI加扰的PDCCH进行激活。

eNodeB通过SPSC-RNTI加扰的PDCCH来激活/释放UE的SPS。

这里将用于指示SPS激活的PDCCH所在的子帧称为“SPS激活子帧”，将用于指示SPS释放的PDCCH所在的子帧称为“SPS释放子帧”，而其它周期性发送PDSCH（虽然下行SPS激活子帧也携带PDSCH，但这里不包含在内）或PUSCH的SPS相关子帧称为“SPS子帧”。

只有满足如下条件，UE才会验证接收到的PDCCH是否用于SPS的激活或释放：

●PDCCH的CRC校验位使用SPSC-RNTI进行加扰；

●NDI域设置为0。

对于DCIformat2/2A/2B/2C而言，支持2个TB，存在2个NDI域，每个NDI域对应一个TB。

每个TB使能SPS是通过将对应的NDI域设置为0而独立配置的。

（中兴认为SPS只能是单流）

满足了上述条件后，UE还会根据36.213的Table9.2-1（SPS激活）和Table9.2-1A（SPS释放）进一步验证PDCCH如下字段：

图3：

SPSActivation/ReleasePDCCHValidation

如果对应DCIformat中的所有字段都按图3所示来设置，则验证成功，否则验证失败。

图4：

SPS激活PDCCH的DCI内容（上行SPS激活子帧，ULGrantinfo）

图5：

SPS激活PDCCH验证成功（上行SPS激活子帧）

如果验证成功，UE会将接收到的DCI当做一个有效的SPS激活/释放来处理；如果验证失败，UE会认为接收到的DCI使用了一个不匹配的CRC。

注意：

DCI中的其它字段含义没有改变，SPS使用的无线资源（称为SPS资源）和MCS等就是通过用于激活SPS的DCI来指示的。

（1）从36.213的Table9.2-1可以看出，指示SPS激活的PDCCH中的“Resourceblockassignment”（用于下行）和“Resourceblockassignment（andhoppingresourceallocation）”（用于上行）字段是用于指示无线资源的，也就是说，对于下行，该PDCCH是与对应的PDSCH一起发送的，对于上行，该PDCCH还指定了PUSCH的资源；但从36.213的Table9.2-1A可以看出，指示SPS释放的PDCCH中的“Resourceblockassignment”（用于下行）和“Resourceblockassignment（andhoppingresourceallocation）”（用于上行）字段为“全1”，即该字段是不用于指示无线资源的。

简单地说：

SPS激活时可以同时传输PDSCH和PUSCH（有一定的timing），但SPS释放时不能同时传输PDSCH和PUSCH。

（2）从36.213的Table9.2-1可以看出，指示SPS激活的PDCCH的5bit“Modulationandcodingscheme（andredundancyversion）”字段的MSB（mostsignificantbit，最高位）为0，即

的取值范围为0~15，而不是通常的0~31。

这里主要是由于VOIP数据包通常比较小，所以I_TBS没必要太大，以提高这类业务的可靠性。

对于下行传输，如果接收到的DCI指示下行SPS激活，则DCI中的TPCcommandforPUCCH字段将指示从4个PUCCH资源中选择1个用于回复ACK/NACK。

该4个PUCCH资源是通过SPS-ConfigDL的n1PUCCH-AN-PersistentList来配置的（对于2天线传输，第二个天线端口的4个PUCCH资源通过n1PUCCH-AN-PersistentListP1-r10配置）。

图6：

TPCcommandforPUCCH字段在SPS中的含义

在激活了SPS后，UE就可以周期性地使用配置的SPS资源来接收和发送数据。

四、下行SPS（36.321的5.10节）

1、下行SPS

下行半静态调度的优先级低于广播、寻呼等公共控制信息，高于用户级控制信令和数据面的传输。

eNodeB在指定的半静态资源上周期发送数据，UE在指定的半静态调度资源上周期接收数据。

半静态调度激活时，根据VoIP数据包大小和UE上报的全带宽CQI，为用户分配MCS和RB。

半静态调度激活后，根据半静态IBLER测量值判决是否需要进行半静态重激活。

如果配置并激活了下行SPS，则UE会认为在满足下面公式的子帧里（称为SPS子帧）被分配了SPS下行资源（此时无需收到PDCCH）：

（10*SFN+subframe）=[（10*SFNstarttime+subframestarttime）+N*semiPersistSchedIntervalDL]mod10240

其中N>0（初始为0，每过一个周期加1），SFNstarttime和subframestarttime为UE接收到指示下行SPS激活的PDCCH的系统帧号和子帧号。

modulo10240是因为系统帧使用10bit表示，取值范围为0~1023，每隔1024个系统帧需要做一次反转。

semiPersistSchedIntervalDL指明UE每隔semiPersistSchedIntervalDL个子帧被分配一次下行SPS资源，即下行SPS周期。

公式中semiPersistSchedIntervalDL可能不是10的倍数，比如sf32，这个时候，如果恰好那个子帧不是下行咋办？

Semi-persistent scheduling interval in uplink, see TS 36.321 [6]. Value in number of sub-frames. Value sf10 corresponds to 10 sub-frames, sf20 corresponds to 20 sub-frames and so on. For TDD, the UE shall round this parameter down to the nearest integer （of 10 sub-frames）, e.g. sf10 corresponds to 10 sub-frames, sf32 corresponds to 30 sub-frames, sf128 corresponds to 120 sub-frames.TDD的会强制变成10的倍数。

图7：

SPS激活PDCCH验证成功（下行SPS激活子帧）

图8：

SPS激活PDCCH的DCI内容（SPS激活子帧:

8859下发了PDCCH调度信息）

图9：

下行SPS（8859激活下行SPS以后，在SPS子帧8879、8899等分配了下行SPS资源）

2、下行SPSHARQ

对于下行HARQ，只有新传会使用SPS资源，重传需要通过SPSC-RNIT加扰的PDCCH显式地分配资源，这是因为eNodeB支持下行HARQ使用异步、自适应的方式。

半静态调度的PDCCH授权中，不包含HARQ进程信息，会出现下行半静态的重传数据不能确定其HARQ进程，导致重传与初传数据无法合并的问题。

为了解决半静态调度的下行HARQ合并问题，协议3GPPTS36.321规定，为下行半静态调度预留HARQ进程，预留的HARQprocessnumber字段通过RRC信令下发给UE。

图10：

下行HARQprocessnumber字段（RRC连接重配置）

当UE接收到指示下行SPS激活的PDCCH时，其对应的HARQprocessID是通过下面的公式计算的（DCI中的HARQprocessnumber域被置成0，floor为向下取整）：

HARQprocessnumber=[floor（CURRENT_TTI/（下行半静态调度的周期））]mod配置的下行半静态调度HARQ进程总数，而CURRENT_TTI=[（SFN*10）+subframenumber。

图12：

下行PDSCH内容

图13：

下行PDCCH中显式分配资源

第6行数据，初传数据，帧号为777，子帧号为9，floor（7779/20）mod=388mod3=1

第7行数据，重传数据，帧号为779，子帧号为3，图13看出通过PDCCH中显式分配资源（注意：

重传数据HRAQ号与初传相同，这里不能用floor（）mod3公式来计算HRAQ号）

第7行数据是对6行数据重传：

✓图13可以看出PDCCH显式为第7行数据分配资源；

✓第7行数据HRAQ号为1，NDI为1，与第6行数据相同；

✓第7行数据Recombining为Yes；

✓第7行数据RV为2，而第6行数据RV为0

✓第6行ACK/NACK为NACK

五、上行SPS（36.321的5.10节）

1、上行SPS

半静态调度激活前，需要对VoIP数据包采用动态调度。

判断VoIP业务为通话期后，尝试激活半静态调度，根据语音包大小和调整后的全带SINR（整个带宽上测量得到的SINR）得到半静态调度激活时MCS和RB。

在半静态调度激活后，UE会在指定的半静态调度资源上周期发送数据，eNodeB在指定的半静态调度资源上周期接收数据。

如果配置并激活了ULSPS，则UE会认为在满足下面公式的子帧里（称为SPS子帧）被分配了SPS上行资源（此时无需收到PDCCH）：

（10*SFN+subframe）=[（10*SFNstarttime+subframestarttime）+N*semiPersistSchedIntervalUL+Subframe_Offset*（Nmodulo2）]modulo10240

SFNstarttime和subframestarttime为UE接收到指示上行SPS激活的PDCCH所指定的将用来发送上行数据的系统帧号和子帧号（对于FDD，是子帧n+4；对于TDD而言，与上下行配置相关。

需要注意的是：

这里的处理与下行略有不同）。

与下行相比，上行SPS增加了偏移量Subframe_Offset*（Nmodulo2），该偏移量只存在于TDD中。

如果SPS-ConfigUL的twoIntervalsConfig字段（只存在于TDD中）配置为true，则Subframe_Offset根据36.321的Table7.4-1来配置；否则Subframe_Offset的值为0。

（具体见上行SPSHARQ）

图10：

SPS激活PDCCH的DCI内容（SPS激活子帧5063下发了PDCCH调度信息）

图11：

上行SPS（SPS子帧5067分配了上行SPS资源）

2、上行SPSHARQ

SPS传输的上行HARQ进程，可以是同步自适应和同步非自适应的。

与下行不同，上行HARQ使用同步的方式，因此并不需要指定HARQprocessID。

并且对上行重传而言，由于可以使用上行同步自适应或同步非自适应HARQ重传，可以使用SPS调度分配的资源，也可以使用SPSC-RNTI加扰的PDCCH重新指定资源。

目前中兴默认先使用同步非自适用重传（10ms后），非自适应重传时刻没有找到资源位置时,立即使用同步自适用重传。

1、非自适应重传：

非自适应的SPS重传使用已分配的上行资源进行重传。

由于是同步的过程，可能存在SPS的重传数据与SPS的配置传输发生冲突的情况。

FDD情形下，如下图所示，在上行传输次数*HARQ进程传输间隔=n*SPS传输周期时，就会发生重传数据和新数据碰撞的情况。

数据1的第5次重传就会和数据包3的初始传输发生碰撞。

这个问题在FDD系统中并不明显，因为FDD上行HARQ的重传间隔为8ms，在进行了5次重传之后才可能发生碰撞，发生冲突的可能性较小。

图12：

FDDLTE上行SPSHARQ示意图

TDD时，由于不同配置下，不同位置子帧上的HARQRTT时间都不相同，重传间隔大多为10ms，数据包0第2次重传时即会和数据包1的初始传输发生碰撞，导致TDD模式下，非自适应重传只能进行一次，因此，发生冲突的可能性相对较大。

图13：

TDD上行SPSHARQ示意图

为此，TDD中可以使用双周期的SPS调度方式，是否启用双周期的调度方式通过RRC信令SPS-ConfigUL：

twoIntervalsConfig来配置。

双周期的SPS启用后，SPS的周期将变为（T1，T2，T1，T2…）的形式。

其中

T1=SPSperiodicity+subframe_offset

T2=SPSperiodicity–subframe_offset

SPSPeriodicity就是在RRC信令中定义的SPS的周期。

Subframe_offset是由TDD的配置以及双周期SPS的起始点来隐式确定的。

Table7.4-1:

Subframe_Offsetvalues

双周期SPS调度的示意图如下所示，数据0的第4次重传才会和数据包2的初始传输发生碰撞：

图13：

TDD上行双周期SPSHARQ示意图

2、自适应重传：

自适应的重传需要通过PDCCH进行上行授权，由于需要重新发送PDCCH，可以通过调度避免第n个包的重传与第n+1个包初传发生冲突。

如果UE在分配的上行SPS资源上，连续implicitReleaseAfter次发送的MACPDU不包含MACSDU，则会自动释放上行SPS并清除配置的ULgrant。

在清除了ULgrant后，需要重传的SPS数据并不受影响。

注意：

无论对于上行SPS还是下行SPS，自适应重传时使用的SPSC-RNTI加扰的PDCCH并不会重新配置SPS资源，也就是说，该PDCCH只在该子帧有效。

3、冲突处理：

半静态调度重传冲突：

对于已经激活的半静态调度的重传，需要判断：

●是否和PRACH、另一个用户的半静态调度初传、TTIBundling的重传冲突

如果发生冲突：

✓当采用上行同步自适应HARQ时，可以自适应调整上行重传的RB资源。

✓当采用上行同步非自适应HARQ时，中兴变更为自适用重传，华为是取消重传。

●是否和PUCCH冲突

如果发生冲突，需要重新激活半静态调度资源。

半静态调度初传冲突:

中兴对于已经激活半静态调度的初传,优先级高，不需要判断是否与PUCCH、PRACH和TTIbundling重传冲突。

而华为初传数据优先级低，需要判断冲突,如果发生冲突,需要重新激活半静态调度资源。

六、SPS调度

1、SPS-C-RNTI使用

SPSC-RNTI不仅用于SPS激活过程中的PDCCH，还用于SPS调度TB的HARQ重传的PDCCH。

为了区分这两种情况，使用了NDI字段：

如果是配置SPS资源（SPS激活），则NDI设置为0，认为NDI翻转（新传数据，都为0）；如果是HARQ重传，则NDI设置为1，认为NDI不会翻转（重传数据，都为1）。

如果在UE收到的PDCCH使用C-RNTI加扰，并且对应的HARQprocess前一次接收到的PDCCH使用SPSC-RNTI加扰（可能是SPS激活，也可能是SPS的重传），则无论NDI域的值是0或1，都认为NDI翻转，即新传。

（见36.321的5.3.1节和5.4.1节）

高通QCAT显示：

如果是配置SPS资源（SPS激活），则NDI翻转（新传数据，01交替）；如果是HARQ重传，则NDI不会翻转（重传数据，与之前新传数据NDI相同）。

WhentheUEhasaC-RNTI,Semi-PersistentSchedulingC-RNTI,orTemporaryC-RNTI,theUEshallforeachTTIduringwhichitmonitorsPDCCH:

-ifadownlinkassignmentforthisTTIhasbeenreceivedonthePDCCHfortheUE’sC-RNTI,orTemporaryCRNTI:

-ifthisisthefirstdownlinkassignmentforthisTemporaryC-RNTI:

-considertheNDItohavebeentoggled.

-ifthedownlinkassignmentisforUE’sC-RNTIandifthepreviousdownlinkassignmentindicatedtotheHARQentityofthesameHARQprocesswaseitheradownlinkassignmentreceivedfortheUE’sSemi-PersistentSchedulingC-RNTIoraconfigureddownlinkassignment:

-considertheNDItohavebeentoggledregardlessofthevalueoftheNDI.

-indicatethepresenceofadownlinkassignmentanddelivertheassociatedHARQinformationtotheHARQentityforthisTTI.

-else,ifadownlinkassignmentforthisTTIhasbeenreceivedonthePDCCHfortheUE’sSemi-PersistentSchedulingC-RNTI:

-iftheNDIinthereceivedHARQinformationis1:

-considertheNDInottohavebeentoggled;

-indicatethepresenceofadownlinkassignmentanddelivertheassociatedHARQinformationtotheHARQentityforthisTTI.

-else,iftheNDIinthereceivedHARQinformationis0:

-ifPDCCHcontentsindicateSPSrelease:

-cleartheconfigureddownlinkassignment（ifany）;

-iftimeAlignmentTimerisrunning:

-indicateapositiveacknowledgementforthedownlinkSPSreleasetothephysicallayer.

-else:

-storethedownlinkassignmentandtheassociatedHARQinformationasconfigureddownlinkassignment;

-initialise（ifnotactive）orre-initialise（ifalreadyactive）theconfigureddownlinkassignmenttostartinthisTTIandtorecuraccordingtorulesinsubclause5.10.1;

-settheHARQProcessIDtotheHARQProcessIDassociatedwiththisTTI;

-considertheNDIbittohavebeentoggled;

-indicatethepresenceofaconfigureddownlinkassignmentanddeliverthestoredHARQinformationtotheHARQentityforthisTTI.

-else,ifadownlinkassignmentforthisTTIhasbeen