CN1798004A - 用于低速率时分双工系统的上行调度信令的传输方法 - Google Patents
用于低速率时分双工系统的上行调度信令的传输方法 Download PDFInfo
- Publication number
- CN1798004A CN1798004A CNA2004101046494A CN200410104649A CN1798004A CN 1798004 A CN1798004 A CN 1798004A CN A2004101046494 A CNA2004101046494 A CN A2004101046494A CN 200410104649 A CN200410104649 A CN 200410104649A CN 1798004 A CN1798004 A CN 1798004A
- Authority
- CN
- China
- Prior art keywords
- bit
- data
- bits
- rate
- physical channel
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
用于低速率时分双工系统的上行调度信令的传输方法,终端发送包括用户期望的数据速率对应的下标比特和用户当前发送的功率信息的上行调度信息,共n个比特;将所述n个上行调度信息比特流进行编码;将编码后的比特送入速率匹配操作,形成88-m个比特的数据流;将所述生成的88-m个比特的数据流,进行第二次交织;在交织后的比特流中,插入SS和TPC比特,共m个比特,形成数据突发格式,在指定时隙的指定码字上发送给Node B。本发明将UE期望的数据速率上报给Node B,能优化Node B的调度策略。UE上报期望的数据速率能减少上行调度所需的上行信令比特。本发明能更好地适应业务的时延要求,增加调度的灵活性,并增大小区的吞吐率,提高系统的业务覆盖。
Description
技术领域
本发明涉及码分多址(简称CDMA)移动通信系统,具体说来涉及1.28Mcps低速率的时分双工码分多址移动通信系统(简称LCR-TDD)中,用于上行信道增强的上行调度信令的传输方法。
背景技术
第三代伙伴计划(简称3GPP)是实施第三代移动通信系统的技术标准化组织,其中第三代移动通信技术标准包括频分双工(FDD)和时分双工(TDD)模式。3GPP自成立至今,分别于1999年10月公布了主要包括3.84Mcps的频分双工(FDD)以及时分双工(HCR-TDD)的第三代移动通信系统技术标准,简称Release 99;于2000年又公布了主要包括3.84Mcps的频分双工(FDD)、时分双工(HCR-TDD)以及1.28Mcps的时分双工(LCR-TDD)的第三代移动通信系统技术标准,简称Release 4;并且于2001年又公布了添加高速数据分组接入(HSDPA)于3.84Mcps的频分双工(FDD)、时分双工(HCR-TDD)以及1.28Mcps的时分双工(LCR-TDD)的第三代移动通信系统技术标准,简称Release 5。目前,3GPP正在实施3.84Mcps的频分双工(FDD)、时分双工(HCR-TDD)以及1.28Mcps的时分双工(LCR-TDD)的第三代移动通信系统上行链路增强的技术予研,并且预期将于2004年在对上述上行链路增强的技术予研的基础之上正式研究上行链路增强的技术标准化工作,所产生的技术方案将包含于未来的3.84Mcps的频分双工(FDD)、时分双工(HCR-TDD)以及1.28Mcps的时分双工(LCR-TDD)的第三代移动通信系统技术标准,简称Release 6。
无论第三代移动通信系统中3.84Mcps的频分双工(FDD)以及时分双工(HCR-TDD)的上行增强技术,还是1.28Mcps的时分双工(LCR-TDD)的上行链路增强的技术,其目的都是通过对由上述3.84Mcps的频分双工(FDD)、时分双工(HCR-TDD)以及1.28Mcps的时分双工(LCR-TDD)的第三代移动通信系统所构成的无线网络的上行传输资源实施有效管理和规划来提高上述系统的上行链路的容量和上述系统的无线小区的覆盖范围,以便适合于对传输突发性较强的数据业务;此外,通过改善上行专用传输信道的性能,从而提高小区的覆盖率和吞吐量,提高上行传输速率,减少上行链路延迟。
3GPP关于上行信道增强的讨论首先是从3.84Mcps的频分双工(FDD)开始的,2003年6月,RAN 20次会议同意开始研究时分双工(简称TDD)系统的上行信道增强。研究的主要项目包括基站(Node B)控制的调度、混合的请求重传(简称HARQ)等,其中HARQ是将数据包的自动重传和信道编码结合起来进行数据传输的一种方法。上行信道增强需要一些新的上行信令,它们是调度相关的、HARQ相关的或者是将来可能需要的。
关于基站(Node B)控制的调度方法,针对FDD模式,3GPP TR25.896V0.4.2包含了两种主要的方法:一种是基站(Node B)控制的速率调度方法(也即两个阈值方案),另一种是基站(Node B)控制的速率和时间调度方法。
为了支持基站(Node B)控制的速率调度方法,两个新的消息被引入:一个是名为速率申请(简称RR)的上行信令,用于UE向Node B申请升降自己的速率阀值;另一个是名为速率应答(简称RG)的下行信令,用于NodeB告诉终端(UE)是否允许其升降自己的速率阀值。Node B控制的速率调度方法,其主要思想是:每个UE在传输信道的初始化过程中,基站控制器(RNC)分配给UE一个传输格式组合集合(TFCS),并通知UE及控制所述UE的基站(Node B),同时RNC还分别给出两个阈值:一个是UE阈值,另一个是Node B阈值。这个TFCS包含了多种传输速率。在通信过程中,UE可以自由的选择不超过UE阈值的传输速率即TFC,若UE需要采用比UE阈值大的TFC,则UE通过RR上行信令向Node B请求提高所述UE阈值。Node B根据当前的干扰等因素决定是否允许提高所述UE的阈值,如果允许,Node B通过RG下行信令告诉UE。注意在这个过程中UE阈值不可能超过Node B阈值。
第二种基站(Node B)控制的时间和速率调度方案中,UE在进行数据传输之前,需要将一些信息发给Node B以进行数据传输的请求,Node B根据收到的信息,计算出UE的无线信道的好坏,并根据当前的噪音情况以及其他UE的请求的情况,对是否允许该UE进行传输,以多大的速率进行数据传输等进行统一调度和安排。具体的过程如下:
第一步:UE在的上行调度信息控制信道中,发送数据传输的请求。发送的信息包括UE的数据缓存器的状态、UE的功率状态或者UE的最大功率能力。
第二步:Node B监测各个UE报告的数据队列长度和发射功率的信息,在小区(Cell)噪声允许的条件下选出尽量少的UE甚至可以是一个UE在下一个调度周期的时间段内进行传输。Node B通过下行调度指定控制信道对选定的UE进行应答。所传输的信息包括:允许传输时刻及时间段,最大允许发射功率等其它的调度信息。
第三步:收到调度指令信息的UE在指定时刻及时间段内,按所指定的速率传输数据。
速率以及时间调度方法有比速率调度更准确地控制本小区噪声水平的能力,也就是说可以使本小区的容量最大化。它的代价是需要传输的调度信息和指令比单纯的速率调度要复杂一些。
针对FDD模式,图1给出了一种传输上行信令:数据缓冲和发送功率的一种方法,即使用额外的上行物理信道,称作上行调度控制信道来发送上行调度所需的信息。
TDD系统与FDD系统不同,是码字受限的。上述两种方案是否适合TDD,或者是否需要新的调度方案仍然处于研究讨论中。一种可能的方案就是基于时间、速率和物理资源(包括码字和时隙)的调度方案。
关于TDD系统的上行信道增强,又分对HCR-TDD的上行信道增强,和对LCR-TDD的上行信道增强。HCR-TDD和LCR-TDD的物理信道结构是完全不一样的。因此在一个传输时间间隔内传输的数据速率也是不一样的。
参照规范25.221,图2给出LCR-TDD的物理信道结构。由图可知LCR-TDD的物理信道采用四层结构:系统帧号(Frame)、无线帧(RadioFrame)、子帧(Sub Frame)和时隙(Time Slot)。一个无线帧对应10ms的传输间隔,包含两个结构完全相同的子帧,每个子帧长为5ms,它由7个常规时隙(TS0-TS6)和3个特殊时隙(DwPTS,GP,UpPTS)组成,常规时隙用作传输用户数据和控制信息。在这7个常规时隙中,时隙0(TS0)总是固定地用作下行时隙来发送系统广播信息,而时隙1(TS1)总是固定地用作上行时隙,其它的常规时隙可根据需要灵活地配置成上行或下行,以实现不对称业务的传输。
所述7个常规时隙具有完全相同的时隙结构,也即数据突发(burst)结构,包括两个数据域(Data Symbols)、一个训练序列域(Midamble)和一个用作时隙保护的空域(GP)。一个数据突发的数据域用于承载来自传输信道的用户数据和高层控制命令,当然对于专用信道,数据域的部分符号还可能被用于传输物理层的信令。在LCR-TDD中,存在着三种类型的物理层信令:功率控制命令(TPC)、传输格式组合指示(TFCI)和同步偏移控制符号(SS)。一个数据突发的传输持续时间为一个时隙,一个时隙中可以有多个物理信道,通过信道码(OVSF)来区分,因此一个发射机可以在同一时刻、同一频率上发射多个数据突发以对应同一时隙中的不同信道。
两个数据域对称地分布于Midamble码的两端,每域的长度为352码片(chips),Midamble码的长度为144码片(chips)。每个数据域所能承载的数据符号数与所使用的扩频因子(SF)有关,上行方向所使用的扩频因子可以是1,2,4,8,16(信道码长)。表1给出一个数据突发选用不同的扩频因子时所能承载的数据符号数。
表1.在一个数据突发中(burst)选用不同的扩频因子时所能承载的数据符号数
Spreading factor(SF) | Number of symbols(N)data fieldin Burst |
1 | 704 |
2 | 352 |
4 | 176 |
8 | 88 |
16 | 44 |
当选用四相移相健控(QPSK)调制时,一个符号占用2个比特,因此当使用QPSK调制方式,选用不同的扩频因子时所能承载的数据比特数,如表2所示。
表2.选用QPSK调制时一个数据突发所能承载的数据比特数
Spreadingfactor(SF) | Number of bits(N)data field inBurst |
1 | 704*2=1408 |
2 | 352*2=704 |
4 | 176*2=352 |
8 | 88*2=176 |
16 | 44*2=88 |
规范规定,对于多码传输,每个UE在一个时隙内同时最多可使用两个上行物理信道,这两个并行的物理信道使用两个不同的信道码来区分。多时隙传输时,本发明中假设每个时隙所使用的物理资源相同。
根据规范25.221给出的数据突发的格式(时隙格式,参照表8G),TPC和SS是同时传送的,对于每个用户,每个TPC命令在一个子帧中至少传送一次。对于每个分配的时隙,由高层信令来指定是否传送TPC,如果一个时隙中有多个码道,高层又给定一个额外参数NTPC来指示对应的物理信道是否传送TPC。
综上所述,在LCR-TDD系统中,每个物理信道所能承载的比特数与数据突发的格式、选用的扩频因子、调制方式、所承载的物理层信令TPC、TFCI、SS所占用的比特数,以及用于承载高层信令所需的比特数有关。
在FDD的上行增强方案中,上行调度信息主要包括数据缓冲和UE的发送功率。向Node B报告数据缓冲不是好的选择,因为就传输延迟而言,不同的业务需要不同的服务质量QOS。因此发送数据缓冲对于Node B的公平调度不是真正有效的关键因素。Node B需要的更关键的信息是特定UE为满足相应Qos而需要的期望的数据速率。因此如果能向Node B上报UE期望的数据速率,就能更好地适应业务的时延要求,增加调度的灵活性,从而能使Node B做出更优的调度决策,最终达到增大小区吞吐率,提高系统的业务覆盖的目的。
另外到目前为止,数据缓冲的范围到底多大,如何表示,以及如何表示UE的有效发送功率等,还没有看到具体的实现方案。
针对TDD的增强方案,无论是HCR-TDD,还是LCR-TDD,上行调度信息应该包括那些信息,如何实现,还都没有确定。
Node B控制的上行调度是TDD上行信道增强研究的主要内容,由Node B控制的快速上行调度,需要尽快知道有关用户的功率、数据缓冲、期望的数据速率、以及当前的干扰情况,来做出最优或次优的调度。当然调度的结果与调度策略和用户报告的信息的准确性有关。换句话说,UE非常愿意及时的、以较高频率尽可能清楚的报告它的状态信息,但是如果这样,上行信令的开销将会很重,从而导致小区的吞吐率和覆盖减小。
在FDD的上行增强中,提出时间和速率调度方法,Node B需要知道每个UE的数据缓冲。向Node B报告数据缓冲不是好的选择,因为就传输延迟而言,不同的业务需要不同的QOS要求。因此发送数据量或数据缓冲对于Node B的公平调度不是真正有效的关键因素。Node B需要的最关键的信息是特定UE为满足相应Qos而需要的期望的数据速率。发送期望的数据速率还能减少上行调度所需的SI比特。
发明内容
本发明的目的就是针对LCR-TDD,提供一种Node B快速调度所需的上行调度信息的传输方法。
为实现上述目的,一种用于低速率时分双工系统的上行调度信令的传输方法,包括步骤:
a)终端发送包括用户期望的数据速率对应的下标比特和用户当前发送的功率信息的上行调度信息,共n个比特;
b)将所述n个上行调度信息比特流进行编码;
c)将编码后的比特送入速率匹配操作,形成88-m个比特的数据流;
d)将所述生成的88-m个比特的数据流,进行第二次交织;
e)在交织后的比特流中,插入SS和TPC比特,共m个比特,形成数据突发格式,在指定时隙的指定码字上发送给Node B。
本发明将UE期望的数据速率上报给Node B,能优化Node B的调度策略。UE上报期望的数据速率能减少上行调度所需的上行信令比特。综合考虑用户期望的数据速率和它的发送功率,能进一步减少UE需上报的发送功率的范围,进而减少为表示发送功率所需的上行信令比特。本发明能更好地适应业务的时延要求,增加调度的灵活性,并增大小区的吞吐率,提高系统的业务覆盖。
附图说明
图1是上行调度信息控制信道;
图2是LCR-TDD的物理信道结构;
图3是一种用于上行信道增强的上行调度信令的传输方法;
图4是上行调度控制信道包含的主要信息;
图5是一种用于上行信道增强的上行调度信令的传输方法示例。
具体实施方式
本发明提出在LCR-TDD系统中,一种用于上行信道增强的上行调度信令的传输方法,参照图3,其步骤主要包括:
所述图的301步:用户发送的上行调度信息(SI),主要包括用户期望的数据速率对应的下标比特,和用户当前发送功率信息,共n个比特;
所述图的302步:将所述n个SI比特流,采用某种编码方式,例如编码速率为1/3的卷积码或者分组码等进行编码;
所述图的303步:将编码后比特送入速率匹配操作,形成88-m个比特的数据流;
所述图的304步:将所述生成的88-m个比特的数据流,按照规范25.222给出的第二次交织的方式,进行第二次交织;
所述图的305步:在交织后的比特流中,插入SS和TPC比特,共m个比特,形成如图所示的数据突发格式,在上行调度控制信道上发送给NodeB。
所述图的301步中,终端(UE)发送的上行调度信令中包括的用户期望的数据速率的表示方法,下面将详述。
由前述知,在LCR-TDD系统中,用户可能的数据速率与分配的每个物理信道所能承载的比特数相关,而每个物理信道所能承载的比特数又与数据突发的格式、选用的扩频因子、调制方式、所承载的物理层信令TPC、SS、TFCI所占用的比特数,以及用于承载高层信令所需的比特数有关。下面我们首先分析在一个子帧内用户只占用一个时隙时的情况。
第i(i=0,1)个物理信道所能承载的比特数NBi如公式(1)所示:
NBi=(352/SFi)×2-NTPCi-Nssi-NTFCIi-NDCCHi (1)
其中SFi表示第i个物理信道所选用的扩频因子,它的取值可以是1,2,4,8,16。NTPCi表示第i个物理信道传输TPC所需的比特数,它与所选用的上行时隙格式有关,规范TS25.2215.0版给出了可能选用的上行时隙格式,其中NTPCi的取值可以是0、2、4、8、16和32;Nssi表示所述物理信道传输SS所需的比特数,它也与所选用的上行时隙格式有关,它的取值与NTPCi一样,可以是0、2、4、8、16和32;NTFCIi表示所述物理信道所需承载的传输格式指示(TFCI)所需占用的比特数,同理,根据规范给定的上行时隙格式,它的可能取值是0,4,8,16,32。NDCCHi表示该物理信道所需承载的高层信令所占用的比特数,可以为0;NTPCi、Nssi、NTFCIi和NDCCHi的取值由高层信令给定。
进行多码传输时,上行最多可以有两个码字,因此可能承载的总的数据比特如公式(2)所示:
NBits=NB0+NB1 (2)
其中NB0为第0(i=0)个物理信道所能承载的比特数,NB1为第1(i=1)个物理信道所能承载的比特数,它们的值可由公式(1)所得。
用户发送的原始信息比特(也称数据块长)NBlock,经过信道编码和速率匹配等操作后在所分配的物理信道上传输,NBlock如公式(3)所示:
NBlock=NBits×Rc (3)
其中Rc为编码速率,0<Rc≤1。这里编码速率指用户发送的原始信息比特和所占用的物理信道所能承载的物理比特NBits之比。
用户发送的数据块一般在一个传输时间间隔(简称TTI)内传输,对于LCR-TDD,TTI的长度可能是5ms(一个子帧)10ms,20ms等,那么用户每秒可能的上行数据传输速率(kbps)如公式(4)所示:
Rd=(NBlock×1000/TTI)/1000=NBlock/TTI kbps (4)
由公式(1)-(4),我们可以得到用户在单时隙情况下可能的数据传输速率(kbps)Rdi的集合{Rdi}。
如果用户被分配给多个(t个)时隙,假定不同的时隙使用的物理资源,即码字、数据突发格式等均相同(为了减少下行信令开销),则用户在占用多个时隙时,可能传输的数据速率(kbps)Rdt为:
Rdt=Rd×t (5)
假设速率集合{Rdi}包含M个元素,那么可以用
比特指示用户期望的数据速率。
如果用户和Node B端均保留可能的速率集合,那么当UE期望能以某个速率发送时,将自己期望的数据速率所对应的下标index传送给NodeB,Node B接收到index时,就可以获知UE期望的速率。
如果用户和Node B保留的速率集合较大,那么速率下标所对应的二进制比特数将较多,进而导致所需的上行信令比特数较多;另外保留较大的速率集合需要用户端额外的较大的数据缓冲开销。总之考虑上行信令传输的有效性和数据缓冲的开销,应该选择较适中的速率粒度(两个速率之间的差)。
所以应该选择{Rdi}的某一子集作为UE可能期望的数据速率集,选取时考虑的因素如下:
1)不考虑较小的数据速率,例如小于10kbps。因为上行增强主要针对的是数据业务;
2)数据速率的粒度可以不同,即速率由小到大选取时,相邻两速率间的差值可以不同;例如选取的数据速率较小时,相应的速率粒度也可以较小,例如可以是30kbps左右;数据速率较大时,相应的速率粒度可以较大,例如可以是60kbps甚至是100kbps;
3)当两个或多个速率近似时,优先选择占用较少码字的速率;因为多码传输会导致码间干扰而影响数据传输的性能。
用户(UE)需要上报给Node B的另一个信息是当前发送功率。在当前规范中,对于LCR-TDD来说,UE传输功率的动态范围是80db。如果表示的功率粒度是1db,那么UE至少需要7比特来表示它的功率信息。
我们注意到在规范TS25.105关于node B接收的参数的最小要求中,发现甚至是在高斯白噪声的情况下,对于12.2kbps的语音业务,误块率是10-2时,UE的最小传输功率也不能小于-27.5dbm。因此在最糟糕的情况下,UE须向Node B报告的有效功率的动态范围仅为52db(UE的最大传输功率是21/24dBm,24-(-27.5)=51.5dB)。因此相比原来的方法,6比特就已足够表示UE的发送功率信息。
事实上,UE报告的期望速率在一定程度上已包含了发送功率,因为期望速率是根据数据缓冲和当前发送功率计算的,另外,Node B也能根据功率控制过程(持续的TPC命令)推断UE的大致发送功率。因此为了减少上行信令的比特数,功率粒度可以选择的较大些。当然不同的功率粒度可能导致为了上报发送功率信息所占用的信令比特数不同。
例如,若功率粒度为2db,51.5/2=25.75,则5比特就足够用于表示发送的功率信息;若功率粒度为4db,51.5/4=12.875,则4比特就足够用于表示发送的功率信息。
所以如果功率粒度为4-1db,则使用4-6比特就足以表示UE的发送功率信息。
综上所述,参照图4,上行调度控制信道所包含的SI信息主要包括r比特的UE期望的数据速率的下标指示和4-6比特的发送功率信息(共n比特)。
所述图的305步,所述的上行调度控制信道其特点是:选用一个扩频为16的上行码字,调制方式为QPSK,时隙格式为规范25.221中表Table 8F给出的格式5;考虑可能的TPC和SS信息比特(设共占用m比特),那么此信道上将有88-m个比特空间用于表达所述n个SI信息比特。
实施例
本发明主要是关于在LCR-TDD系统中,一种用于上行信道增强的上行调度信令的传输方法,所以在下面的事例中有关Node B的调度方式、下行调度信令内容及传输方式等有所省略。
根据LCR-TDD的上行时隙结构及本发明给出的公式(1)-(4),假设TPC为2比特,SS为2比特,NTFCIi、NDCCH0以及NDCCH1=0,当TTI等于5ms时,一个可能的用于上行信道增强(EUCH)的用户期望的数据发送速率子集的事例如表3所示。
表3一个可能的用于上行增强(EUCH)的期望数据发送速率集事例
(TTI=5ms)
速率编号 | SF | 编码速率 | 物理比特(每时隙) | 传输块的大小 | 数据速率(kbps)(一个时隙) |
1 | 16 | 1/3 | 84 | 28 | 5.6 |
2 | 8 | 1/3 | 172 | 57 | 11.46 |
3 | 4 | 1/3 | 348 | 116 | 23.2 |
4 | 2 | 1/3 | 700 | 233 | 46.6 |
5 | 2+8 | 1/3 | 876 | 292 | 58.4 |
6 | 2+4 | 1/3 | 1052 | 350 | 70.12 |
7 | 2+2 | 1/3 | 1404 | 468 | 93.6 |
8 | 8 | 1/2 | 172 | 86 | 17.2 |
9 | 4 | 1/2 | 348 | 174 | 34.8 |
10 | 2 | 1/2 | 700 | 350 | 70.0 |
11 | 2+8 | 1/2 | 876 | 438 | 87.6 |
12 | 2+4 | 1/2 | 1052 | 526 | 105.2 |
13 | 2+2 | 1/2 | 1404 | 702 | 140.4 |
14 | 8 | 3/4 | 172 | 129 | 25.8 |
15 | 4 | 3/4 | 348 | 261 | 52.2 |
16 | 2 | 3/4 | 700 | 525 | 105 |
17 | 2+8 | 3/4 | 876 | 657 | 131.4 |
18 | 2+4 | 3/4 | 1052 | 789 | 157.8 |
19 | 2+2 | 3/4 | 1404 | 1053 | 210.6 |
20 | 2+2 | 1.0 | 1404 | 1404 | 280.8 |
当TTI等于10ms时,一个可能的用于上行信道增强(EUCH)的用户期望的数据发送速率子集的事例如表4所示。
表4一个可能的用于上行增强(EUCH)的期望数据发送速率集事例
(TTI=10ms)
速率编号 | SF | 编码速率 | 物理比特(每时隙) | 传输块的大小 | 数据速率(kbps)(一个时隙) |
1 | 16 | 1/3 | 84 | 56 | 5.6 |
2 | 8 | 1/3 | 172 | 114 | 11.46 |
3 | 4 | 1/3 | 348 | 232 | 23.2 |
4 | 2 | 1/3 | 700 | 466 | 46.6 |
5 | 2+8 | 1/3 | 876 | 584 | 58.4 |
6 | 2+4 | 1/3 | 1052 | 701 | 70.12 |
7 | 2+2 | 1/3 | 1404 | 936 | 93.6 |
8 | 8 | 1/2 | 172 | 172 | 17.2 |
9 | 4 | 1/2 | 348 | 348 | 34.8 |
10 | 2 | 1/2 | 700 | 700 | 70.0 |
11 | 2+8 | 1/2 | 876 | 876 | 87.6 |
12 | 2+4 | 1/2 | 1052 | 1052 | 105.2 |
13 | 2+2 | 1/2 | 1404 | 1404 | 140.4 |
14 | 8 | 3/4 | 172 | 258 | 25.8 |
15 | 4 | 3/4 | 348 | 522 | 52.2 |
16 | 2 | 3/4 | 700 | 1050 | 105 |
17 | 2+8 | 3/4 | 876 | 1314 | 131.4 |
18 | 2+4 | 3/4 | 1052 | 1578 | 157.8 |
19 | 2+2 | 3/4 | 1404 | 2106 | 210.6 |
20 | 2+2 | 1.0 | 1404 | 2808 | 280.8 |
根据本发明给出的选取数据速率的原则,我们从表3和4中仅选取编号为3,4,10,16,18,19,20(7种)的速率作为UE基本的期望数据发送速率集,如表5。(为了表示简单,在下面的叙述中,我们将5ms TTI和10msTTI对应的期望速率集表合并在一起表示,因为在这两种情形下,除了传输块的大小对应的列不同外,其他各列均相同)。
表5.在单时隙情况下用于调度要求的期望速率集TTI 10ms和5ms
速率编号 | SF | 编码速率 | 物理比特(每时隙) | 传输块大小/5ms TTI | 传输块大小/10msTTI | 数据速率(kbps)/5ms和10ms |
0 | 4 | 1/3 | 348 | 116 | 232 | 23.2 |
1 | 2 | 1/3 | 700 | 233 | 466 | 46.6 |
2 | 2 | 1/2 | 700 | 350 | 700 | 70.0 |
3 | 2 | 3/4 | 700 | 525 | 1050 | 105 |
4 | 2+4 | 3/4 | 1052 | 789 | 1578 | 157.8 |
5 | 2+2 | 3/4 | 1404 | 1053 | 2106 | 210.6 |
6 | 2+2 | 1.0 | 1404 | 1404 | 2808 | 280.8 |
考虑多时隙情形,根据本发明给出的公式(5),能够进一步得到包含多时隙情况的用于调度要求的期望数据速率集,如表6。
表6.包含多时隙情况的用于调度要求的期望速率集TTI 10ms和5ms
速率编号 | SF | 编码速率 | 物理比特(每时隙) | 传输块大小/5ms TTI | 传输块大小/10msTTI | 数据速率(kbps)/5ms和10ms |
0 | 4 | 1/3 | 348 | 116 | 232 | 23.2 |
1 | 2 | 1/3 | 700 | 233 | 466 | 46.6 |
2 | 2 | 1/2 | 700 | 350 | 700 | 70.0 |
3 | 2 | 3/4 | 700 | 525 | 1050 | 105 |
4 | 2+4 | 3/4 | 1052 | 789 | 1578 | 157.8 |
5 | 2+2 | 3/4 | 1404 | 1053 | 2106 | 210.6 |
6 | 2+2 | 1.0 | 1404 | 1404 | 2808 | 280.8 |
7 | 2+4 | 3/4 | 1052*2 | 1578 | 3156 | 315.6 |
8 | 2+4 | 3/4 | 1052*3 | 2366 | 4732 | 473.2 |
9 | 2+4 | 3/4 | 1052*4 | 3155 | 6310 | 631.0 |
10 | 2+4 | 3/4 | 1052*5 | 3945 | 7890 | 789.0 |
11 | 2+4 | 3/4 | 1052*6 | 4734 | 9468 | 946.8 |
12 | 2+2 | 3/4 | 1404*6 | 6318 | 12636 | 1263.6 |
13 | 2+2 | 1.0 | 1404*6 | 8244 | 16488 | 1648.8 |
在表6中,一共有14种可能的数据速率,所以用4比特就可以表示这些数据速率。例如用0000表示编号为0的数据速率,0001表示编号为1的数据速率,......,用1101表示编号为13的数据速率。
如果再考虑速率匹配操作的影响(选用不同的编码速率),我们能够得到TTI 10ms和5ms时,另一个用于调度要求的期望速率集事例,如表7所示。注意表7已包含多时隙情况。
表7.另一个包含多时隙情况的用于调度要求的期望速率集事例(TTI 10ms和5ms)
速率编号 | SF | 编码速率 | 物理比特(每时隙) | 传输块大小/5ms TTI | 传输块大小/10ms TTI | 数据速率(kbps)/5ms和10ms |
0 | 4 | 0.46 | 348 | 160 | 320 | 32 |
1 | 2 | 0.46 | 700 | 320 | 640 | 64 |
2 | 2+4 | 0.46 | 1052 | 480 | 960 | 96 |
3 | 2+4 | 0.61 | 1052 | 640 | 1280 | 128 |
4 | 2+4 | 0.61 | 1052*2 | 1280 | 2560 | 256 |
5 | 2+4 | 0.61 | 1052*3 | 1920 | 3840 | 384 |
6 | 2+4 | 0.61 | 1052*4 | 2560 | 5120 | 512 |
7 | 2+4 | 0.61 | 1052*5 | 3200 | 6400 | 640 |
8 | 2+4 | 0.73 | 1052*5 | 3840 | 7680 | 768 |
9 | 2+4 | 0.71 | 1052*6 | 4480 | 8960 | 896 |
10 | 2+2 | 0.61 | 1404*6 | 5120 | 10240 | 1024 |
在表7中,一共有11种可能的数据速率,所以用4比特足以表示这些数据速率。
假设用4比特表示用户期望的数据速率下标指示,4比特表示用户的发送功率信息,所传输的TPC和SS所占用的比特数各为2(共4比特),则上行调度信息SI的传输方法,参照图5,其步骤主要包括:
所述图的501步:上行调度SI信息,主要包括用户期望的数据速率对应的下标指示(4比特),和用户的当前发送功率比特(4比特),共8个比特;
所述图的502步:将所述8个SI比特流,采用2倍重复编码器,生成8*2=16比特的序列;
所述图的503步:将所述生成的比特流,采用编码速率为1/3的卷积码进行编码,生成(16+8)*3=72比特的编码后序列;
所述图的504步:参照规范25.222给出的速率匹配过程,将所述序列经过速率匹配操作,形成84个比特的序列;事实上这里速率匹配的操作过程就是在指定的位置上插入12比特信息;
所述图的505步:将所述生成的84个比特的数据流,按照规范25.222给出的第二次交织的方式,进行交织;
所述图的506步:在交织后的比特流中,插入2比特的TPC信息和2比特的SS信息,形成如图所示的数据突发格式。所述形成的数据突发将在指定时隙的指定码字上发送给Node B。
Claims (13)
1.一种用于低速率时分双工系统的上行调度信令的传输方法,包括步骤:
a)终端发送包括用户期望的数据速率对应的下标比特和用户当前发送的功率信息的上行调度信息,共n个比特;
b)将所述n个上行调度信息比特流进行编码;
c)将编码后的比特送入速率匹配操作,形成88-m个比特的数据流;
d)将所述生成的88-m个比特的数据流,进行第二次交织;
e)在交织后的比特流中,插入SS和TPC比特,共m个比特,形成数据突发格式,在指定时隙的指定码字上发送给Node B。
2.根据权利要求1所述的方法,其特征在于:步骤a)中所述的用户期望的数据速率可以为UE端保留的期望数据速率表中的任一速率对应的下标指示。
3.根据权利要求1所述的方法,其特征在于:步骤b)中所述的编码方式是编码速率为1/3的卷积码或分组码等。
4.根据权利要求2所述的方法,其特征在于:所述的UE端保留的期望数据速率表中的任一速率与UE分配的物理信道所选用的数据突发的格式、扩频因子、调制方式、所承载的物理层信令功率控制命令、传输格式组合指示和同步偏移控制符号所占用的比特数,以及用于承载高层信令所需的比特数等有关。
5.根据权利要求2所述的方法,其特征在于:所述的UE端保留的期望数据速率表中的每一速率Rd,当占用单时隙时,Rd=NBlock/TTI kbps,NBlock为用户发送的数据块长,传输时间间隔以毫秒为单位,可以是5ms、10ms20ms或其他值。
6.根据权利要求5所述的方法,其特征在于:所述的数据块长NBloct=NBits×Rc,其中Rc为编码速率,0<Rc≤1,指用户发送的原始信息比特和所占用的物理信道所能承载的物理比特NBits之比。
7.根据权利要求6所述的方法,其特征在于:所述的物理比特NBits=NB0+NB1,其中NB0为第0个物理信道所能承载的比特数,NB1为第1个物理信道所能承载的比特数,当UE只分配一个上行增强的物理信道时,NB1为0。
8.根据权利要求7所述的方法,其特征在于:所述的物理信道所能承载的比特数NBi=(352/SFi)×2-NTPCi-Nssi-NTFCIi-NDCCHi,(i=0或1);其中SFi表示所述第i个物理信道所选用的扩频因子,它的取值可以是1,2,4,8,16;NTPCi表示所述第i个物理信道传输TPC所需的比特数,Nssi,表示所述物理信道传输SS所需的比特数,它们的取值均与所选用的上行时隙格式有关,可以是0、2、4、8、16和32;NTFCIi表示所述物理信道所需承载的传输格式指示(TFCI)所需占用的比特数,同理,根据规范给定的上行时隙格式,它的可能取值是0,4,8,16,32;NDCCHi表示该物理信道所需承载的高层信令所占用的比特数,可以为0。
9.根据权利要求8所述的方法,其特征在于:所述的NTPCi、Nssi、NTFCIi和NDCCHi的取值由高层信令给定。
10.根据权利要求2所述的方法,其特征在于:步骤a)中所述的UE端保留的期望数据速率表中的每一速率,当占用多个(t)时隙时,可能传输的数据速率(kbps)Rdt=Rd×t,其中Rd为单个时隙内所能传输的数据速率。
11.根据权利要求2所述的方法,其特征在于:所述的UE端保留的期望数据速率表为UE可能传输的数据速率表的子集,即按照公式(1)-(5)生成的数据速率全集的子集。
13.根据权利要求11所述的方法,其特征在于:从所述数据速率全集构造子集时,包括:
a)不考虑较小的数据速率;
b)速率由小到大选取时,相邻两速率间的差值可以不同;
c)当两个或多个速率近似时,优先选择占用较少码字的速率。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2004101046494A CN1798004A (zh) | 2004-12-29 | 2004-12-29 | 用于低速率时分双工系统的上行调度信令的传输方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2004101046494A CN1798004A (zh) | 2004-12-29 | 2004-12-29 | 用于低速率时分双工系统的上行调度信令的传输方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1798004A true CN1798004A (zh) | 2006-07-05 |
Family
ID=36818815
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2004101046494A Pending CN1798004A (zh) | 2004-12-29 | 2004-12-29 | 用于低速率时分双工系统的上行调度信令的传输方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1798004A (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102036358A (zh) * | 2010-11-29 | 2011-04-27 | 大唐移动通信设备有限公司 | 一种传输和接收命令字的方法、系统及设备 |
CN101702965B (zh) * | 2007-03-10 | 2012-03-14 | 霖那控股私人有限公司 | 在自适应蜂窝网络中利用用户协作和调度优化下行链路吞吐量 |
WO2017024943A1 (zh) * | 2015-08-11 | 2017-02-16 | 中兴通讯股份有限公司 | 一种传输方法和装置 |
CN109474381A (zh) * | 2017-09-08 | 2019-03-15 | 华为技术有限公司 | 一种时隙格式指示方法、设备及系统 |
CN109831830A (zh) * | 2019-04-03 | 2019-05-31 | 成都中科微信息技术研究院有限公司 | 一种电力无线专网快速调度资源请求方法 |
CN110166205A (zh) * | 2018-02-14 | 2019-08-23 | 华为技术有限公司 | 一种确定时隙格式的方法及设备 |
CN111406377A (zh) * | 2017-12-01 | 2020-07-10 | 高通股份有限公司 | 频分双工中的时隙格式指示符 |
-
2004
- 2004-12-29 CN CNA2004101046494A patent/CN1798004A/zh active Pending
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101702965B (zh) * | 2007-03-10 | 2012-03-14 | 霖那控股私人有限公司 | 在自适应蜂窝网络中利用用户协作和调度优化下行链路吞吐量 |
CN102036358A (zh) * | 2010-11-29 | 2011-04-27 | 大唐移动通信设备有限公司 | 一种传输和接收命令字的方法、系统及设备 |
CN102036358B (zh) * | 2010-11-29 | 2013-07-24 | 大唐移动通信设备有限公司 | 一种传输和接收命令字的方法、系统及设备 |
WO2017024943A1 (zh) * | 2015-08-11 | 2017-02-16 | 中兴通讯股份有限公司 | 一种传输方法和装置 |
CN109474381A (zh) * | 2017-09-08 | 2019-03-15 | 华为技术有限公司 | 一种时隙格式指示方法、设备及系统 |
CN109474381B (zh) * | 2017-09-08 | 2020-08-07 | 华为技术有限公司 | 一种时隙格式指示方法、设备及系统 |
CN111406377A (zh) * | 2017-12-01 | 2020-07-10 | 高通股份有限公司 | 频分双工中的时隙格式指示符 |
CN111406377B (zh) * | 2017-12-01 | 2023-02-28 | 高通股份有限公司 | 频分双工中的时隙格式指示符 |
CN110166205A (zh) * | 2018-02-14 | 2019-08-23 | 华为技术有限公司 | 一种确定时隙格式的方法及设备 |
CN110166205B (zh) * | 2018-02-14 | 2024-04-09 | 华为技术有限公司 | 一种确定时隙格式的方法及设备 |
CN109831830A (zh) * | 2019-04-03 | 2019-05-31 | 成都中科微信息技术研究院有限公司 | 一种电力无线专网快速调度资源请求方法 |
CN109831830B (zh) * | 2019-04-03 | 2021-12-07 | 成都中科微信息技术研究院有限公司 | 一种电力无线专网快速调度资源请求方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10313086B2 (en) | Sending full channel quality indication reports on TDM channel in wireless communication | |
AU2005302840B2 (en) | Method and apparatus for transmitting and receiving downlink control information in a mobile communication system supporting uplink packet data service | |
CN101854675B (zh) | 在移动通信系统中调度上行链路数据传输的方法和装置 | |
CN1902975B (zh) | 混合tdm/ofdm/cdm反向链路传输 | |
CN1190095C (zh) | 传送无线电信号的方法,应用该方法的接入网络和无线电通信终端 | |
US20050220042A1 (en) | Method and apparatus for transmitting scheduling grant information using a transport format combination indicator in Node B controlled scheduling of an uplink packet transmission | |
CN1701535A (zh) | 在异步wcdma系统中提供上行链路分组数据业务的方法和装置 | |
CN1505904A (zh) | 扩频通信系统的时间复用传输方案 | |
CN1918822A (zh) | 在移动通信系统中在增强上行链路专用信道上传送调度信息的方法 | |
CN1914835A (zh) | 蜂窝通信网络中分配发送功率的装置和方法 | |
CN1742509A (zh) | 上行链路中的tfc选择 | |
CN1819673A (zh) | 数据传输增强相关的基站控制的时分复用调度方法 | |
CN1627844A (zh) | 移动通信系统中上行专用信道增强的基站控制的调度方法 | |
CN1969482A (zh) | 用于移动通信系统中上行链路分组数据服务的数据传输/调度的方法和装置 | |
CN1798004A (zh) | 用于低速率时分双工系统的上行调度信令的传输方法 | |
EP1717982A2 (en) | Method and apparatus for determining transport parameters for physical layer to provide uplink packet data service in a mobile communication system | |
KR20060016723A (ko) | 향상된 상향링크 전용채널을 지원하는 이동통신시스템에서 하향링크 제어정보의 전송 방법 및 장치 | |
CN1780478A (zh) | 用于高速率时分双工系统的上行调度信令的传输方法 | |
CN1780179A (zh) | 用于高速率时分双工系统的下行调度信息的传输方法 | |
CN1798444A (zh) | 用于低速率时分双工系统的下行调度信息的传输方法 | |
CN1627845A (zh) | 移动通信系统中上行共享信道增强的基站控制的调度方法 | |
CN1747596A (zh) | 组合的信令传输方法 | |
CN1630379A (zh) | 低速率码分多址系统中上行信道增强的上行信令传输方法 | |
CN1691544A (zh) | 低速率码分多址系统中上行信道增强的上行信令传输方法 | |
Sharma et al. | Moving towards HSUPA (high speed uplink packet access): a complete 3.5 G wireless system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20060705 |