C114门户论坛百科APPEN| 举报 切换到宽版

亚星游戏官网

 找回密码
 注册

只需一步,快速开始

短信验证,便捷登录

搜索
查看: 4256|回复: 1

[分享]ovsf基础 [复制链接]

军衔等级:

亚星游戏官网-yaxin222  上等兵

注册:2009-9-7
发表于 2010-9-27 14:25:53 |显示全部楼层
在OVSF码树结构中,每一阶对应一个SF值,如SF=2时,位于同阶的可用码字是2个,SF=4时,可用码字是4个,依此类推,SF=8时,有8个可用码字。码字的标识是 Cch,SF,no
其中,SF为扩频因子,No从上至下按序编号。SF值代表原来的一个比特用SF个码片来表示,如SF=4,一个比特位用4个码片来表示。每个码字的长度与SF值相关,SF=4表示码字长度为4。码字的取值范围,在上行方向,SF=4、8、16、32、64、128、256;在下行方向,SF=4、8、16、32、64、128、256、512。使用位于同一阶的码字,表示原始用户的业务速率是一致的,才会选择到相同的SF值。同一阶码字之间是完全正交的。当位于不同阶的码字间存在父子关系时,码字之间具有相关性,在DL方向也就不能被同时分配使用。当位于不同阶的码字间不存在父子关系时,码字之间仍是正交关系。由于父子关系的码字具有相关性,所以在选择码序列时数量会受限。在DL方向不考虑公共信道和功率受限,假设所有码字都可以被分配用来通信,在最大情况下允许同时使用的用户数应当是512个。在DL方向所能支撑的最大速率,SF越小,速率越高,所以在SF=4时,速率是最大。但在SF=4是,只能用Cch,4,1、Cch,4,2、、Cch,4,3 三个码字,这是因为Cch,4,0 产生的子码字序列要被分配给公共信道使用。所以Cch,4,0 树不能使用,用户的2M速率就是同时占用SF=4的三个码字获得的。SF=4时单信道的Symbol Rate=3.84/4=960ksymbol/s,这只是其中一路(I或Q路)上的速率,两路信号在DL方向是通过串并转换之后获得的,奇偶比特分开,速率减半。所以在恢复到原始比特时,首先要经过串并转换的逆过程,将I路960k信号和Q路960k信号叠加,成为2x960=1920kbps速率的信号,这才是经过信道编码、交织等基带信号处理过程之后的信号速率。在1920kbps中有用信息只占768kbps,这是进行基带信号处理前的有效速率,相当于用户单信道上的原始信息速率只有768kbps,只有同时得到DL方向上三个信道的物理链路,Bit Rate=3 x 768=2.1Mbps,才能满足最大2M的业务。所以2M速率指的是用户的比特速率,在规范中被归为2048业务。
OVSF的分配原则:在DL方向,根据用户的业务请求由RNC动态分配,在同一阶情况下,初始状态时,是按由上到下的原则分配,在使用状态下,对空闲资源,也是从上到下按序分配。从RNC的动态资源管理来说,假设在SF=8层,已有5个用户分别占用5个码字信道(0、2、6码字未用),在不考虑上行链路的干扰受限和下行链路的功率受限时,有第6个用户(业务速配要求SF=4)申请接入时,RNC允许接入,分配码字时可以采用二种方案,第一种称为Auto-Patching(打补丁)方案,所谓补丁现象,是指由于码字资源的按序分配,个别用户在放弃码字时,会出现不相邻码字被分别占用的现象,如3、7码字占用而2、6码字未占用。所以当第6个用户申请接入时,可以将占用码字3的用户重新配置,使占用码字6信道,将2、3码字的父码字(SF=4)分配给用户6,这个过程即为Auto-Patching过程;第二种称为Self-Splitting(自我分裂)方案,将申请SF=4的用户分裂,使分别占用2个SF=8的信道来实现。二种方案优选第二种,因为无线链路重建需要涉及相应的信令过程,同时,二个SF=8的功率和一个SF=4的功率是不等效的。在速率适配时,RNC会优先选择SF值高的物理信道,以降低功率。在UL方向的码字分配,现阶段在专用的信令和业务信道上,只能分配每阶中的一个码字,即Cch,SF,SF/4的码字,如Cch,4,1、Cch,8,2等。该码字是1 1 -1 -1的重复,只是根据速率不同SF值的不同而重复的次数不同。这是针对单业务单信道情况的码字分配方案,将来如果一个移动台支撑多个业务,码字分配就会发生变化,该原则不再发生作用。一般认为在上行链路上所要求的速率不是很高,区分用户是通过扰码来区分的,不同用户之间无需通过扩频码来区分用户,所以可以简化码字的分配方式,现阶段无需通过扩频码来区分物理信道,对相同速率的业务可以分配相同的扩频码字,而只通过扰码来区分用户。RNC的这种分配方式称为半静态分配方式。
根据上述的分配原则,一个小区在DL方向码字最多只能分配一个2M业务的承载,这称为码字缺陷(Shortage)。为了弥补缺陷,规范中规定了付扰码(Secondary SC)的概念,对相同的扩频码,为了达到重复使用的目的,以满足多用户的业务需求,可以通过付扰码加以区分。在同一个扰码下,OVSF码树只能使用一次,对同一个小区来说,最多可以分配1个主扰码和15个付扰码,即OVSF可以重复使用16次,所以码字资源是足够使用,只是现阶段仍暂不使用付扰码。从码字角度考虑容量是不受限的,受限的是下行链路上的功率和上行链路上的干扰,也就是在下行链路上允许提供多少个2M用户取决于小区最大允许功率数。
码字的正交性在同步前提下完全正交,非同步条件下会发生相位偏转。信号在下行链路是所有码字叠加后进行发射的,所有码字同步且正交,到达移动台后,移动台接受来自不同小区的信号,码字会发生偏转,可以通过主扰码加以区分和过虑,从而接受本小区的信号。本小区信号由于多经产生的时延对于移动台来说,无论是有用信号还是干扰信号都是一样的。所以对于信道化码的码字要求只是完成扩频及基本正交就可以。在上行链路,每个移动台各自发射独立的信号,传播时延及发射时间不同,基站侧接受仍是所有信号的叠加,上行链路上的信号相关性较差,不可能同步,所以要选择相关性比扩频码要好的扰码来区分不同用户,对扰码的特性要求较高。
对于扰码来说,系统选择的是伪随机序列(PN序列),PN序列的码字与窄代CDMA不同,窄代CDMA是m序列,WCDMA选择的是Gold序列。序列不同指的是产生的机制不同,从而会有不同的相关特性。PN序列产生的基本原理如图所示:以三个移位寄存器为例,每一位的初始赋值称为状态值,假设为001,最后一位的状态值作为PN序列的输出
产生的PN序列为11101001的周期性重复,循环周期称为PN序列的长度=2n-1,其中n为移位寄存器的个数,例中n=3,所以序列长度为7位,每7位之后会重复一次。由于选择PN序列的长度、寄存器抽头及初始赋值各不一样,将会产生不同的PN序列。PN序列每偏移一个相位,就可以截取2n-1长的PN序列,也就是对于周期为2n-1的PN序列可以有2n-1个。
在UMTS中,上行链路的PN序列采用25位移位寄存器,I路Q路分开各是25位寄存器,可以看成同一个扰码。扰码周期(长度)为225-1。根据扰码产生的机制,首先寄存器的赋值是变化的,对Q路来说,初始赋值为全“1”码,对I路来说,初始赋值的前24位有RNC动态分配,也就是RNC分配给移动台一个24位的识别符,这个识别符将作为PN序列产生的寄存器前24位的初始赋值,再加上第25位的状态值“1”。在上行链路方向上每个移动台由于所得的状态值不同的,所以产生的码序列是不同的,相当于在该方向上实际可以使用的扰码是224个。Gold码产生的码序列的自相关性是非常好的,但由于只是初始赋值的不同,所以不同的PN序列不是完全正交,只是近似正交。但由于码序列长度较长,克服了正交特性的不足,因为码字越长,正交性越好。所以在UMTS中,系统不需完全同步,只要近似同步就可以。在上行链路,还可以选择短扰码,该扰码周期是256,该技术在将来会被引入,当在上行链路上使用短扰码时,为克服码间干扰,对Rake接受机会有较高要求,会采用多用户监测技术(MUD)来代替Rake接受机制,目前使用的还是长扰码。在实际使用中,系统会每10ms截取PN序列中的38400chips,使扰码速率位3.84Mchip/s,所以只使用了PN序列中的一段。在下行方向上的扰码仍然选择的是长扰码,它的初始赋值及周期是固定的。采用18位的移位寄存器,周期是218-1=262143,而实际在下行链路上可以使用的扰码规范只定义了8192个,作为Cell ID,规范只定义了8192个扰码,并分配到512个小区,每个小区可以使用16个扰码,包括1个主扰码和15个付扰码。15个付扰码完成对OVSF的复用。相当于可用码字是16 x 512=8192个。也就是每512个小区会重复使用8192个码字。对于下行链路上的主扰码,规范中同时又将512个主扰码分成了64组,每组由8个主扰码构成,而付扰码与主扰码是绑定的。下行链路扰码采用静态分配。也就是下行链路的扰码是利用同一PN序列的不同偏置(offset)来区分,并完成每10ms 38400chips的截取而获得的。下行链路的扰码具有非常好的自相关性,在同步的前提下,100%相关,在非同步条件下,也能满足近似正交。而不同码字之间也有较好的互相关性,在同步的前提下,100%相关,在非同步条件下,也能满足近似正交。为使相邻小区间码字的相关性最好,所以在网络建设时对512个码字要进行码字规划。

举报本楼

本帖有 1 个回帖,您需要登录后才能浏览 登录 | 注册
您需要登录后才可以回帖 登录 | 注册 |

手机版|C114 ( 沪ICP备12002291号-1 )|联系大家 |网站地图  

GMT+8, 2024-11-19 16:37 , Processed in 0.173983 second(s), 15 queries , Gzip On.

Copyright © 1999-2023 C114 All Rights Reserved

Discuz Licensed

回顶部
XML 地图 | Sitemap 地图