TD-SCDMA应用共享信道承载PoC业务的研究

最新推荐文章于 2024-04-26 13:35:49 发布

zthsss

最新推荐文章于 2024-04-26 13:35:49 发布

阅读量157

点赞数

分类专栏：通信技术文章标签： allocation 网络集群 tdd 算法 testing

本文链接：https://blog.csdn.net/zthsss/article/details/6419773

版权

通信技术专栏收录该内容

10 篇文章 0 订阅

订阅专栏

TD-SCDMA应用共享信道承载PoC业务的研究

张堂辉普天信息技术研究院

摘要：本文对PoC业务在共享信道上的承载进行了研究，给出了承载的几种推荐方案，并对各种方案的优劣进行了分析。

关键字 PoC，TD-SCDMA，共享信道

1. 前言

PoC是一种在公众移动通信网中实现集群业务的技术，在公众移动通信网的业务中是一种新兴的业务，PoC业务的本质是一种在分组域上实现的半双工VoIP业务。该业务最初是在2.5G网络上首先实现的，但是由于网络带宽有限，因此业务开展的效果并不理想。随着3G对分组业务支持能力的提高，这项业务获得了各方面的广泛关注，被认为很有可能是3G时代的杀手级业务。TD-SCDMA技术作为我国提出的第一个拥有自主知识产权的国际通信标准，具有频谱利用率高，容量大和高速数据通讯能力，非常适合PoC业务的开展。

PoC技术允许手机象对讲机那样按下一个专用键就可以进行通话，它的优点如下表：

表 1 PoC技术的优点

用户	运营商
不需要拨号实现语音通信	可以与专用集群网竞争
按下一个键就建立多个对话连接	为用户提供创新的服务
漫游区域较大	增加数据通信量
	提高用户忠诚度，降低客户流失率

但是PoC在公众网络上的运行主要存在两个难点：一个是时延问题，PoC的首次呼叫时延一般来说在3～5秒左右，相对于专用集群设备的不大于1秒的时延是太长了[1]。另外一个问题是无线资源的使用问题。当PoC用户集中在一个小区内的时候，这时候会产生大量的无线资源需求。如果PoC业务全部使用专用信道来实现，即使PoC是半双工业务，也需要建立上行和下行专用信道，那么在通话期间占用的无线资源都只能由PoC业务使用，这样产生的资源浪费是非常严重的。

上面所说的问题会直接影响到PoC在公众移动通信网络中的应用范围和前景。在TD-SCDMA中，可以使用共享上行信道（USCH）和共享下行信道（DSCH），这样可以比较充分的利用无线资源，同时并不改动TD-SCDMA现有的协议。我们的工作就是围绕这个问题展开的。

2. TD-SCDMA共享信道配置

共享信道本质上是共享物理信道，即，不同用户分时使用相同的预先分配的物理信道资源，共享的时间单位是无线帧，共享的最长时长是255个无线帧[1][2]。传输信道与逻辑信道不共享。共享信道主要是为分组业务服务的，这由其目的所决定。根据TD-SCDMA功率控制的要求，共享信道的可能的配置如下表2：

表2 共享信道配置表

	编号	上行	下行
CELL_FACH	1	RACH	FACH + DSCH
CELL_FACH	2	USCH + RACH	FACH + DSCH
CELL_DCH	3	DCH	DCH + DSCH
	4	DCH + USCH	DCH
	5	DCH + USCH	DCH + DSCH

PoC是一种半双工的VoIP业务，但是通话中呼叫权控制是采用IP层之上的信令来传送的（常见的一种是使用RTCP协议），那么在不改变3GPP标准的情况下，无线接入层是无法获得这个信息的，所以我们必须在无线承载建立的时候就同时建立好上行和下行通道。

在分析之前，在这里我们有个前提假定，假设实际的PoC业务承载只能在共享信道上或专用信道上实现，而不能将业务承载同时建立在共享信道和专用信道上。这时因为如果允许PoC业务承载同时配置在两种信道上，系统实现将会非常复杂。

编号1的配置上行使用的RACH，RACH是公共信道，能够承载的数据量是比较小的。根据PoC业务特点，语音数据需要的带宽较大，所以这种配置是不适合在PoC业务上使用的。

由于在无线接入承载RAB建立的时候就需要建立上行和下行通道，所以如果采用了专用信道来传输语音，那么由于PoC是半双工业务，对于说话者来说，那么此时下行通道的无限资源是被浪费掉了，对于接听者来说则是相反，上行通道无线资源被浪费掉了。根据节省无线资源的原则，应该选取编号2和编号5的配置方案。

考虑到PoC的呼叫特性，如果PoC进行集群呼叫的时候，用户都在一个小区内，并且都使用专用信道来建立承载。假设这个呼叫用户有N个人，由于PoC业务任何一个时刻只有一个人能够说话，那么对于下行通道来说，有一个用户的浪费掉了，对于上行通道来说，有N-1的用户浪费掉了。也就是说此时上行通道的浪费程度要大得多，而下行相对较小。因此在这种呼叫模型下我们认为配置4也是可以考虑的。

经过简单分析后，我们认为配置2，4，5是可以列入考虑的。

3. PoC业务在共享信道的承载研究

3.1. 编号2的配置方案

对于前面编号2的配置方案，上行的数据应该配置在USCH上，下行数据应该配置到DSCH上。因此我们建议采用下面的承载配置方案，注意SHCCH映射到两条传输信道，主要考虑是节省RACH的开销。这种配置方案的优点是不需要专用信道，在RRC建立的时候使用公用信道RACH和FACH，实现比较简单。缺点是由于需要使用公用信道来承载信令，因此不太适合大容量的用户呼叫，适合在业务开展初期使用。

3.1.1. 上行SRB1～4（RACH）＋SRB5（RACH＋1条USCH）＋业务RB（1条USCH）

图1 编号2方案的上行信道配置

3.1.2. 下行SRB1～4（FACH）＋SRB5（FACH＋1条DSCH）＋业务 RB（1条DSCH）

图2 编号2方案的下行信道配置

3.2. 编号4的配置方案

对于编号4的配置方案，上行的数据应该配置在USCH上，下行数据应该配置到DCH上。这时我们建议采用下面描述的配置方案。这种配置的优点是下行数据采用了专用信道，上行虽然采用共享信道，但是数据业务上行一般较少，此时语音的QoS比较容易保证。缺点是下行采用专用信道，在用户处于说话状态的时候，无线资源浪费比较严重。

3.2.1. 上行SRB1～4（1条DCH）＋业务RB（2条DSCH）

图3 编号4方案的上行信道配置

3.2.2. 下行

图4 编号4方案的下行信道配置

3.3. 编号5的配置方案

对于编号5的配置方案，上行的数据应该配置在USCH上，下行数据应该配置到DSCH上。这种配置方案的优点是无线资源能够比较充分的利用，缺点是实现起来比较复杂。

3.3.1. 上行

配置采用的方案和配置4相同

3.3.2. 下行SRB1～4（1条DCH）＋业务RB（2条DSCH）

图5 编号5方案的下行信道配置

4. 共享信道的分配

共享信道相对于专用信道来说实现起来比较复杂。从前面编号4配置方案和编号5的配置方案的对比就可以看出，使用共享信道时，需要增加一条SHCCH信道，增加一条到CCTrCH的映射。此外由于共享信道是使用分时间片来实现共享的[3]，时间片的分配是通过RRC的“Physical Shared Channel Allocation”信令过程来实现的（如下图6，图7所示）。这个过程是在SHCCH或DCCH上传输的，额外增加了系统的无线资源开销。

图6 下行共享信道资源分配过程

图7 上行共享信道资源分配过程

共享信道使用的时候的效果很大程度上依赖于RNC中的RRM算法，我们举例如下：

假设用户都是PoC用户，某个共享信道总带宽正好够5个用户使用。那么每个用户占用的时间占空比是1/5，注意到时间片的划分是以帧为单位的，最小是1，最大是255。那么如果时间片是每隔1帧分配给某个用户的话，那么显而易见，Physical Shared Channel Allocation过程将变得极为频繁。如果时间片是每隔255帧分配给用户的话，那么每个用户为此可能引入的语音延迟将达到2.5秒钟，这已经是完全不可接受的。Physical Shared Channel Allocation过程的发送频率会对RNC系统负荷带来很大的影响。频率太高，就意味者SHCCH或DCCH的带宽需要增加，带宽需要增加很多的话，可能导致共享信道带来的资源节省变得毫无意义。我们最终需要在语音延迟和信令负载之间做出折衷。还需要注意到，由于共享信道的分时使用，因此当PoC的一组用户同时在一个小区内的时候（这是一种比较常见的情况），组的大小对语音的时延有比较大的影响。经过研究后，我们估计在这种情况下，PoC用户组最好不要超过10个，否则业务性能可能急剧恶化。

5. 后续的研究工作

如果我们需要使用共享信道来实现PoC业务，那么需要看RRM算法是否能够提供足够的QoS，在大量呼叫的情况下，这个调度可能是很复杂的。对于PoC特定业务，我们认为可以在QoS参数中增加描述字段，这样RRM算法可以根据这个QoS参数来确定共享信道的资源分配模式。使用共享信道的核心问题是要在语音延迟和信令负载之间做出均衡，后面还要对这个问题做更深入的研究，进行实际业务的仿真。PoC业务在TD-SCDMA共享信道上的承载，是PoC进行业务优化的一个关键点。

此外PoC在使用共享信道的时候，共享信道是否能够实现智能天线等问题都还有待进一步的研究。

6. 结论

在本文中，我们对PoC业务在TD-SCDMA共享信道上的承载问题进行了初步的研究。我们认为在少量用户呼叫的情况下，建议使用配置编号2方案。如果存在大量用户呼叫的情况，使用共享信道带来的信令开销会严重影响RACH/FACH等公共信道的使用。这个时候应该使用编号5的方案。如果我们假定PoC业务模型是经常多用户处于同一个小区内，那么编号4的配置方案也是可行的。

从实现的难度来看，我们建议实际使用的时候，按照方案2，方案4，方案5的顺序来进行业务的优化。