CN1983845B - 一种上行链路速率调整的方法 - Google Patents

Abstract

本发明提出了一种在IuUP支持模式下，上行链路速率调整的方法，在小区负载或Iub口拥塞的时候，以较低的保证速率接入，保证通话的质量，节约资源；当资源恢复以后，源端的速率控制实体会通过发送同向速率改变申请的方式，主动进行上行数据传输速率的调整，将业务传输速率提升到合适的速率，在及时改善通话效果及应用质量的同时，也避免了单通故障或加剧CN或对端RNC可能存在的资源拥塞的状况，解决了源端速率控制实体不能主动进行上行数据传输速率调整的问题。

Description

一种上行链路速率调整的方法

技术领域

本发明属于通信领域，特别涉及一种利用可变速率传输数据的方法。

背景技术

在无线通讯系统中，CDMA系统较GSM系统提供了更为丰富的业务，包含了各种速率的话音、数据流业务、交互式业务、背景业务等。在实际应用中，各种业务的速率可根据网络状况进行自动调节，以充分利用资源缓解拥塞，体现了Qos的应用，成为第三代无线通讯网络的优势所在。

在一般的UMTS系统中，考虑移动到移动的语音呼叫情况，原始信号首先在发起侧UE中编码，经过无线接口的传送，在本地代码转换机中转换成A律或者μ律PCM编码(符合ITU-TG.711制式标准)后，在核心网中向远端传输；在远端代码转换机中再次进行代码转换，将PCM语音格式转换成为一种适合在无线接口上传送的编码格式，以便在远端无线接口上发送，最后在终结的UE中解码，这种呼叫连接在核心网内进行两次代码转换，通常称为级联配置模式。这种配置中存在一个致命的缺点，编解码器的级联引入的两次代码转换降低了语音质量，当语音编解码器低速率工作时，这种影响尤为明显。

在GSM网络发展的后期，出现了TFO机制，它是一种呼叫配置，在信号链路上物理地存在代码转换设备，但代码转换功能被绕过，这种做法被第三代移动通信系统UMTS网络继承。

TFO技术是为了解决无线压缩语音在时分复用(TDM，Time DivisionMultiplex)通信系统上传输时，由于编解码转换造成语音质量损伤的问题。TFO技术指通过带内信令协商，在TDM承载的每个采样的高位传输纯脉冲编码调制(PCM，Pulse Code Modulation)码流，低位传输TFO信令和压缩语音帧，以达到如下优点：

(1)提高语音质量：因为可减少两次语音编解码转换。

(2)提高数字信号处理器(DSP)处理能力：因为不需要做真正的编解码转换。

(3)节省传输链路：多个压缩语音话路可以复用在一个TDM时隙上。

(4)减少传输时延：由于减少了编解码转换，省去了编解码转换的延时

图1为在利用TDM的数字蜂窝移动通信系统(GSM)中实现TFO的原理图。参见图1，MS为移动用户，TRAU是语音编解码单元，负责压缩语音帧和PCM码流之间的转换，可以位于基站控制器(BSC，Base Station Controller)或者移动交换中心(MSC，Mobile Switch Center)上。MS和TRAU之间传输压缩语音帧，如GSM-HR编解码；在两个TRAU之间通过TDM承载传输PCM码流。(IPE，In Path Equiptment)指在TFO路径上，能够自动识别TFO业务，并能透传TFO业务的功能实体，如EC。

当非TFO时，两个MS之间的压缩语音帧需要经过两个TRAU的编解码转换，对从左到右的压缩语音帧，在第一个TRAU上先把左边MS发出的压缩语音帧转换成PCM码流，在第二个TRAU上再把PCM码流转换为压缩语音帧，传送到目的MS。这个呼叫要经过两次编解码转换，因此会严重影响语音质量。

当TFO时，先在两个TRAU之间的TDM承载上用带内信令协商是否可以直接传压缩语音帧，协商的内容包括两端的TRAU的能力是否支持传输压缩语音帧以及两端所使用的压缩语音编解码是否相同，如果都是，则协商成功，若协商成功则直接在TDM承载上传输压缩语音帧，接收和发送端都不做编解码转换，语音质量提高；如果协商不成功，则继续经过两次编解码转换。另外，如果某一端的编解码发生变化则重新进行协商。

上述的TFO是一种带内的免编解码操作的通信协议，现有技术中还有一种带外的免编解码操作的通信协议(TrFO，Transcoder Free Operation)。TrFO中，网络可以在呼叫建立前就利用带外信令对编解码的类型和模式进行协商，使通讯两端使用相同的编解码。当网关的编解码修改时，可以通知控制面通过信令修改对端网关的编解码，以使两端的编解码一致。TrFO编解码器的协商发生在呼叫建立阶段，也可能发生在呼叫中(由于其他某种原因，如切换等)，下面简述TrFO的建立过程，如图2所示。

首先在呼叫发起时，进行编解码器的协商，以试图建立TrFO操作。发起侧的UE在IAM消息中携带其所支持的编解码器类型列表，通过无线接口、Iu接口(RNC和MSC之间)到达发起MSCServer，发起MSCServer从列表中剔除不支持的编解码类型后再将其发给传输网络；同样地，传输网络也从中剔除他不支持的类型后继续发向终结的MSCServer，终结MSCServer也执行同样的操作后将该列表发向终结UE，由终结UE结合此列表和自身的编解码情况选择一个最优公共的编解码类型，并依次向前返回给终结MSCServer、传输网络、发起MSCServer和UE，通知他们当前所选用的编解码类型，这样在此编解码器基础上，开始分配建立承载。

如果终结UE在选择最优公共编解码器时失败，即没有公共的编解码器可供使用，那么就选择缺省的PCM编码格式，发起侧MSC应在来自发起侧UE的路径上插入一个代码转换机。此时，对终结UE的编解码器选择在终结MSC中选择，他独立于发起侧MSC，这就是TrFO建立失败时的情况。

若成功的建立承载，在Iu接口用户平面上开始初始化过程，以确定传输压缩语音的帧格式，初始化信息从发起的RNC向后传向终结的RNC，在此链路上确定统一的帧格式，包括Nb接口(2个媒体网关之间的接口)，初始化完成后，压缩语音就可以在用户平面内传送，至此，移动到移动的TrFO的连接就完全建立起来了。

目前WCDMA系统在CS域提供三种业务：AMR语音业务、可控流业务和多媒体视讯业务。AMR全称为自适应多速率编码，可分为窄带AMR(NB-AMR)编码和宽带AMR(WB-AMR)编码两种类型，分别由8种(窄带)和9种(宽带)语音速率以及无数据(对于没有数据的情况)和SID(对于舒适噪声)组成；RCS可控流业务支持三种速率，以上两种业务的IuUP均为支持模式，由于在WCDMA系统中，提供了IuUP面的速率控制功能，因此下行速率的调节可通过IuUP速率控制过程来实现，而上行可通过配置UE的传输格式集来达到速率变化的目的。

当小区资源初级拥塞(如LDR拥塞或者Iub口拥塞)时，为了尽可能多的接入用户，新建业务被要求以较低的速率(如保证速率)作为初始速率接入；而当拥塞解除时，用户又希望能尽快恢复到较高速率(如最大速率)以获得最佳通话效果或应用质量.对于IuUP为支持模式的业务，协议25.415明确规定了在收到速率控制请求消息前，业务后续的速率都不能超过初始速率.因此，如果业务在建立时是以低速率接入的，则在资源恢复正常后，下行速率可通过RNC的IuUP向CN或者对端RNC(通话处于TFO/TrFO状态)发送速率控制请求消息要求提高下行速率；而上行速率则只能被动地等待TFO/TrFO状态下收到对端RNC发来的速率请求才能进行上行速率升速操作，当业务连接为非TFO/TrFO状态或者对端RNC不触发下行速率调整时，本端UE的上行速率就不再有机会恢复到较高速率.

为了解决上述问题，在现有技术中，有三种解决方案。

方案一、由于Iu的初始速率是不区分上下行的，为了防止业务以低速率接入后，没有机会恢复到较高速率而持续影响通话质量，无论小区负载或Iub口是否存在拥塞，都以CN分配的最大速率接入。该方案在小区负载拥塞或Iub口拥塞情况下无法以较低速率接入，不但加剧了资源的拥塞状况，而且也影响了用户通话质量(AMR语音在无线资源拥塞时以低速率通话质量较佳)。

方案二、当小区负载拥塞或Iub口拥塞时，AMR语音或可控流业务以保证速率接入，等到拥塞解除后下行速率通过速率控制请求帧要求CN(级联配置状态下)或者对端RNC(TFO/TrFO状态下)进行速率升速，而上行不进行主动升速，只能等待对端RNC的速率控制请求。如图3所示，CN侧首先向SRNC发送上行速率控制消息(Rate Control(CN)for uplink)，其中携带CN侧支持的RFCI集；SRNC接收到该消息后，和自身支持的RFCI集进行协商，只有双方都支持的速率，才被用来传输数据；SRNC将双方都接收的数据通过消息Rate Control(CNRNC)for uplink发送给UE，配置UE的传输格式集；UE以速率CNRNC发送用户数据。

该方案虽然体现了资源拥塞情况下的Qos服务，但当资源恢复正常时，上行业务速率无法主动提速，当业务连接为非TFO/TrFO状态或者对端RNC不触发下行速率调整时，上行速率就始终处于低速率状态，影响了后续通话效果或业务质量。

方案三、当小区负载拥塞或Iub口拥塞时，AMR语音或可控流业务以保证速率接入，等到拥塞解除后下行速率通过速率控制请求帧要求CN(级联配置状态下)或者对端RNC(TFO/TrFO状态下)进行速率升速，而上行速率进行主动升速，通过配置UE的传输格式集将上行速率升到最大速率。如图4所示，SRNC直接向UE发送Rate Control for uplink消息，为UE配置RFCI集，UE根据配置的RFCI集传输数据。

该方案虽然根据资源状况进行了业务速率的改变，但RNC在提升上行速率前并不与CN或对端RNC(TFO/TrFO状态下)进行协商，这不但违反了协议25.415规定的初始速率作为收到速率控制帧前的最大速率的规定，易造成单通故障，而且在TFO/TrFO状况下当对端UE所在的小区存在拥塞时，将进一步加剧对端小区的拥塞状况。

发明内容

针对上述问题，本发明提出了一种无线通信系统中，在IuUP支持模式下，上行链路进行主动速率控制的方法。

本发明提出的一种IuUP支持模式下，上行链路速率调整的方法包括：

源端速率控制实向对端速率控制实体发送同向速率改变请求信息；

对端速率控制实体如果允许进行上行速率的调整，则向源端速率控制实体返回同向速率改变请求响应信息；

源端速率控制实体根据接收的同向速率改变请求响应信息，向用户终端配置上行速率传输格式.

上述方案中，所述步骤之前进一步包括，当无线资源发生拥塞时，用户终端以保证速率接入网络，源端速率控制实体对无线资源进行检测。

上述方案中，所述速率改变请求信息中携带源端速率控制实体的支持RFCI集。

上述方案中，进一步包括：

对端速率控制实体根据接收到的源端速率控制实体支持的RFCI集和自身支持的RFCI集进行协商，得到双方都支持的RFCI集。

上述方案中，所述速率改变请求响应信息中携带对端速率控制实体和源端速率控制实体都支持的RFCI集，或，携带对端速率控制实体和源端速率控制实体都支持的最大速率对应的RFCI。

上述方案中，进一步包括：

源端速率控制实体根据双方都接受的RFCI集配置用户终端的传输格式集，或，根据双方都接受的最大速率对应的RFCI配置用户终端的传输格式集。

上述方案中，所述同向速率改变请求响应信息中携带对端速率控制实体支持的RFCI集。

上述方案中，进一步包括：

源端速率控制实体根据接收到的对端速率控制实体支持的RFCI集，和自身支持的RFCI集进行协商，得到双方都支持的RFCI集。

上述方案中，进一步包括：

源端速率控制实体根据双方都接受的RFCI集配置用户终端的传输格式集，或，根据双方都接受的最大速率对应的RFCI配置用户终端的传输格式集。

上述方案中，所述源端速率控制实体为无线网络控制器；所述对端速率控制实体在普通模式下为无线核心网设备，在TFO或TrFO模式下为无线网络控制器。

通过本方法，充分的体现了Qos服务的原则，当资源恢复以后，源端的速率控制实体会通过发送同向速率改变申请的方式，主动进行上行数据传输速率的调整，将业务传输速率提升到合适的速率，在及时改善通话效果及应用质量的同时，也避免了单通故障或加剧CN或对端RNC(TFO/TrFO模式下)可能存在的资源拥塞的状况，解决了源端速率控制实体不能主动进行上行数据传输速率调整的问题。

附图说明

图1、无线通信网络中实现TFO的原理图；

图2、无线通信网络中实现TrFO模式的原理图；

图3、无线通信网络中，源端速率控制实体根据对端速率控制实体的请求进行速率调整的原理图；

图4、无线通信网络中，源端速率控制实体不与对端速率控制实体进行协商，主动进行上行速率控制的原理图；

图5、本发明提出的在级联配置模式下，源端速率控制实体主动进行上行速率控制，在对端速率控制实体进行速率协商的原理图；

图6、本发明提出的在TFO/TrFO模式下，源端速率控制实体主动进行上行速率控制，在对端速率控制实体进行速率协商的原理图；

图7、本发明提出的在级联配置模式下，源端速率控制实体主动进行上行速率控制，在源端速率控制实体进行速率协商的原理图；

图8、本发明提出的在TFO/TrFO模式下，源端速率控制实体主动进行上行速率控制，在源端速率控制实体进行速率协商的原理图。

具体实施方式

为了更好的描述本发明的技术方案，下面结合附图来详细的描述本发明的具体实现过程。

本发明首先提出了一种IuUP支持模式下，主动进行上行速率控制的方法。在IuUP支持模式下，业务建立时，如果源端速率控制实体检测到当前的无线资源拥塞，如小区负载或Iub口负载等，源端速率控制实体的初始速率以保证速率接入，这样可以缓解资源拥塞压力；当源端速率控制实体检测到无线资源恢复正常后，对端速率控制实体根据源端速率控制实体的请求调整下行传输速率，而上行数据传输速率的调整，则通过源端速率控制实体向对端速率控制实体发送同向速率改变请求，如果允许进行上行传输速率的调整，则源端速率控制实体和对端速率控制实体进行上行数据传输速率的协商，得到双方都支持的RFCI集，源端速率控制实体根据协商后的RFCI集对用户终端进行传输格式集的配置。

图5示出了WCDMA系统中的AMR业务，在级联配置模式的IuUP支持模式下，主动进行上行速率控制的流程图，在本实施例中，源端速率控制实体为服务无线网络控制器SRNC，对端速率控制实体为核心网侧设备，如媒体网关MGW等，在这里我们用CN表示。该方法包括以下步骤：

步骤501，CN向SRNC发送无线接入承载RAB分配请求RAB Assigment Req；

CN建立AMR业务，该消息中携带了可用速率集，其中包括了最大速率、保证速率以及若干的中间速率。

步骤502，SRNC根据无线资源的状况，发送IuUP支持模式下的初始化消息IuUP Initialisation Control；

在AMR业务建立过程中，SRNC检测到源端无线资源拥塞，如小区负载拥塞或Iub口拥塞等，SRNC以保证速率作为初始速率接入AMR业务。其后的步骤为无线链路的建立过程，这些步骤在现有技术中已经得到体现，在图中以省略号代替，不再重复。

步骤503，SRNC通过IuUP向CN发送同向速率改变请求信息IuUP RateChange Require；

在业务传递的过程中，SRNC一直检测无线资源的状态，当SRNC检测到无线资源恢复正常时，SRNC这时主动向CN侧发送同向速率改变请求信息，其中携带了SRNC支持的RFCI集，请求CN进行速率协商，得到双方都支持的速率集。

在本实施例中，我们定义同向速率改变请求信息的结构如下表1所示：

表1

用IuUP Type 14 PDU作为速率改变申请帧，Procedure Indicatior＝4标识该Type 14 PDU用于同向速率改变请求过程，其中携带的取值为0的RFCI 0 Ind、RFCI 1 Ind......RFCI P-1 Ind对应的速率表示SRNC支持的目标速率。

步骤504，CN接收同向速率改变请求信息，判断是否可以进行上行速率的调整，并向SRNC发送同向速率改变请求响应消息；

CN接收到同向速率改变请求消息后，首先判断本端的无线资源是否处于拥塞状态或其他需要限制速率改变的状况，如果是则拒绝上行速率的改变；如果CN端允许速率的改变，则向SRNC发送同向速率改变请求响应消息，在该消息中携带CN端根据SRNC支持的RFCI集确定的两端都支持的RFC集，其可以通过双方RFCI集进行交集的方式得到。需要指出的是，在该消息中也可以只携带双方可接受最大目标速率对应的RFCI，该RFCI可以从双方都支持的RFCI集中获取，将最大目标速率的RFCI标识发送给SRNC。

在本实施例中，我们定义同向速率改变请求响应消息的帧结构如表2所示：

表2

Procedure Indicatior＝4表示该Type 14 PDU用于同向速率改变申请的应答，其中Ack/Nack＝1表示允许速率改变，取值为0的RFCI 0 Ind、RFCI 1 Ind...RFCIP-1Ind对应的速率表示CN端可接受的目标速率；如果Ack/Nack＝2则表示CN端拒绝进行上行速率的调整，，这两种情况都可以通过同向速率改变请求响应信息来标识。

步骤505，SRNC接收到CN发送的同向速率改变请求响应消息后，向UE发送TFC Subset Control消息，进行传输格式集配置；

SRNC接收到同向速率改变请求响应消息后，判断CN侧是否允许进行上行传输速率的调整，如果允许，则从双方都支持的RFCI集中提取最大目标速率，作为上行速率调整的目标速率，并将双方都支持的RFCI集发送给UE，配置UE的传输格式集，UE以新配置的传输格式集中的速率进行数据的传送，从而实现了上行数据传输速率的调整。

当同向速率改变请求响应消息中，只携带双方都接受的最大目标速率对应的TFCI时，SRNC直接将其作为上行速率调整的目标速率，并将该目标速率发送给UE，配置UE的传输格式集。

通过上述的方法，SRNC可以通过发送同向速率调整请求信息，主动进行上行传输速率的调整，解决了上行传输速率无法主动进行调整的问题。

上述描述的实施方式，是本发明在级联配置模式下的应用情况，同样在TFO/TrFO模式下，本发明也同样适用，与级联配置模式下不同的是，在TFO/TrFO模式下，对端速率控制设备为对端RNC，我们标记为RNC’。具体的应用如图6所示，包括以下步骤：

步骤601～步骤602，为IuUP支持模式下，AMR业务建立过程，与步骤501～步骤502相同。

步骤603，当SRNC检测到无线资源恢复正常时，则向CN发送同向速率改变请求信息，CN将该信息转发给RNC’，请求RNC’进行速率协商，得到双方都支持的速率集；

具体的消息格式和工作原理与步骤503相同。

步骤604，RNC’判断是否允许进行上行数据传输速率的调整，并向CN发送同向速率改变请求响应信息；

RNC’判断是否允许上行传输速率的改变，如果不允许，则拒绝上行速率的改变；否则，RNC’根据接收到的同向速率改变请求信息中的SRNC的支持RFCI集，和自身支持的RFCI集进行协商，得到双方都支持的目标RFCI集；同时，向CN发送同向速率改变请求响应信息，CN接收到该消息后，将该消息转发给SRNC。同样，在该消息中也可以只携带双方可接受最大目标速率对应的RFCI，将最大目标速率对应的RFCI标识发送给SRNC。具体的同向速率改变请求响应消息的帧结构如表2所示，这里不再重复。

步骤605，SRNC接收到CN发送的同向速率改变请求响应消息后，向UE发送TFC Subset Control消息，进行传输格式集配置，具体的实施方式同步骤505一样。

上述描述了在TFO/TrFO模式下，SRNC对上行数据传输速率主动进行调整的流程。

上述两个实施例分别介绍了在级联配置模式和TFO/TrFO模式下，SRNC主动进行速率调整的实施例，由SRNC向对端速率控制实体发送同向速率改变请求，其中携带了SRNC支持的RFCI集，对端速率控制实体根据自身支持的RFCI集和SRNC支持的RFCI集进行协商，协商出双方都支持的RFCI集为目标RFCI集，然后对端速率控制实体将目标RFCI集或最大速率对应的RFCI标识发送给SRNC，由SRNC进行UE传输格式的配置。上述两个实施例中的双方支持的RFCI速率集的协商过程是在对端速率控制实体即CN或RNC’中进行的。

本发明还提出了另外一种在IuUP支持模式下，源端速率控制实体主动进行上行速率调整的方法。在该方法中，源端速率控制实体向对端速率控制实体发送同向速率改变请求，来通知对端速率控制实体进行上行传输速率的调整，源端速率控制实体根据接收到的对端速率控制实体的支持RFCI集，和自身支持的RFCI集进行协商，得出双方都支持的目标RFCI集，对UE进行配置，使UE以目标RFCI集中的速率进行上行数据的传输。该方法中，目标速率的协商过程在源端速率控制实体即SRNC中进行，具体实施例如下。

图7示出了在级联配置模式下，本方法的具体实施过程，包括以下步骤：

步骤701～步骤702，为IuUP支持模式下，AMR业务建立过程，与步骤501～步骤502相同。

步骤703，SRNC通过IuUP向CN发送同向速率改变请求信息IuUP RateChange Require；

在业务传递的过程中，SRNC一直检测无线资源的状态，当SRNC检测到无线资源恢复正常时，SRNC主动向CN发送同向速率改变请求信息。需要注意的是，在该消息中，可以携带SRNC支持的RFCI集，也可以不用携带SRNC支持的RFCI集，在这里为可选项。同时，当同向速率改变请求信息IuUP Rate ChangeRequire中携带SRNC支持的RFCI集时，我们定义该同向速率改变请求信息的结构和表1的结构一样，用Procedure Indicatior＝4标识该Type 14PDU用于同向速率改变申请过程；当同向速率改变请求信息IuUP Rate Change Require中不携带SRNC支持的RFCI集时，该消息的结构可以将标识RFCI的部分去掉，也可以在其中填充其他的信息。这个消息在这里只是用来通知CN侧来进行上行速率的改变，请求CN侧发送其支持的RFCI集。

步骤704，CN侧接收同向速率改变请求信息，判断是否可以进行上行速率的调整，并向SRNC发送同向速率改变请求响应消息；

CN侧接收到同向速率改变请求消息后，判断本端的无线资源是否处于拥塞状态或其他需要限制速率改变的状况，如果是则拒绝进行上行速率的改变；如果允许上行速率的改变，则向SRNC发送同向速率改变请求响应消息，在该消息中，携带有CN侧自身支持的RFCI集。

具体的消息格式和表2中所示的格式一样，Procedure Indicatior＝4表示该Type 14PDU用于同向速率改变申请的响应，其中Ack/Nack＝1表示允许速率改变，取值为0的RFCI 0 Ind、RFCI 1 Ind...RFCI P-1 Ind对应的速率表示CN端支持的RFCI集；如果Ack/Nack＝2则表示CN端不允许进行速率的改变。CN端对上行传输速率改变的接收和拒绝都是通过同向速率改变请求响应消息来标识的。

步骤705，SRNC接收到CN发送的同向速率改变请求响应信息后，进行上行传输速率的协商，并向UE发送TFC Subset Control消息，进行传输格式集的配置；

SRNC接收到同向速率改变请求响应信息后，根据其中携带的CN侧支持的RFCI集，和自身支持的RFCI集进行协商，得出双方都支持的RFCI集，作为上行速率调整的目标RFCI集，并将该目标RFCI集发送给UE，配置UE的上行传输格式。

需要指出的是，这时，SRNC也可以将目标速率集中最大的目标速率对应的RFCI发送给UE，配置UE的上行传输格式，这并不影响本发明的实施。

上述描述了在级联配置模式下，本方法的工作流程。同样在TFO/TrFO模式下，本发明也同样适用，与级联配置模式下不同的是，在TFO/TrFO模式下，对端速率控制设备为对端RNC，我们标记为RNC’。其工作流程如图8所示，包括以下步骤：

步骤801～步骤802，为IuUP支持模式下，AMR业务建立过程，与步骤501～步骤502相同。

步骤803，当SRNC检测到无线资源恢复正常时，则向CN发送同向速率改变请求信息，CN将该消息转发给RNC’；

在本步骤中，同向速率改变请求信息的格式和内容同步骤703所描述的相同，可以在该消息中携带SRNC支持的RFCI集，也可以不用携带，该消息只是用来通知RNC’，进行上行传输速率的调整，并请求CN侧发送其支持的RFCI集。与步骤703不同的只是同向速率改变请求信息的处理由RNC’来处理。

步骤804，RNC’判断是否允许进行上行数据传输速率的调整，并向SRNC发送同向速率改变请求响应信息；

RNC’接收到同向速率改变请求消息后，判断本端的无线资源是否处于拥塞状态或其他需要限制速率改变的状况，如果是则拒绝进行上行传输速率的调整；如果允许上行速率的改变，则向CN发送同向速率改变请求响应消息，在该消息中，携带由RNC’侧自身支持的RFCI集。CN将接收到的响应消息，转发给SRNC。具体的消息格式如步骤704所述，这里不再重复。

步骤805，SRNC接收到CN发送的同向速率改变请求响应消息后，进行上行传输速率的协商，并向UE发送TFC Subset Control消息，进行传输格式集的配置；具体的工作过程同步骤705一样，在这里不再重复。

上述描述了速率协商在源端速率控制实体中进行的主动调整上行传输速率的具体实施方式。

上面的几个实施方式只是描述了在AMR业务中，源端速率控制实体主动进行上行数据传输速率调整的方法，同样该方法也使用与可控流、多媒体视讯等业务中，其原理和本方法一样，在这里不再一一描述。

需要指出的是，以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种上行链路速率调整的方法，其特征在于，包括以下步骤：

源端速率控制实体向对端速率控制实体发送同向速率改变请求信息；

对端速率控制实体如果允许进行上行速率的调整，则向源端速率控制实体返回同向速率改变请求响应信息；

源端速率控制实体根据接收的同向速率改变请求响应信息，向用户终端配置上行速率传输格式；

所述源端速率控制实体为服务无线网络控制器，所述对端速率控制实体在级联配置模式下为媒体网关，在带内的免编解码操作TFO或带外的免编解码操作TrFO模式下为无线网络控制器。

2.如权利要求1所述的方法，其特征在于，所述步骤前，进一步包括，当无线资源发生拥塞时，用户终端以保证速率接入网络，源端速率控制实体对无线资源进行检测。

3.如权利要求1或2所述的方法，其特征在于，所述同向速率改变请求信息中携带源端速率控制实体支持的无线接入承载子流格式RFCI集。

4.如权利要求3所述的方法，其特征在于，进一步包括：

对端速率控制实体根据接收到的源端速率控制实体支持的无线接入承载子流格式RFCI集和自身支持的无线接入承载子流格式RFCI集进行协商，得到双方都支持的无线接入承载子流格式RFCI集。

5.如权利要求4所述的方法，其特征在于，所述同向速率改变请求响应信息中携带所述双方都支持的无线接入承载子流格式RFCI集，或，携带对端速率控制实体和源端速率控制实体都支持的最大速率对应的无线接入承载子流格式RFCI集。

6.如权利要求5所述的方法，其特征在于，进一步包括：

源端速率控制实体根据双方都接受的无线接入承载子流格式RFCI集配置用户终端的传输格式集，或，根据双方都接受的最大速率对应的无线接入承载子流格式RFCI配置用户终端的传输格式集。

7.如权利要求1或2所述的方法，其特征在于，所述同向速率改变请求响应信息中携带对端速率控制实体支持的无线接入承载子流格式RFCI集。

8.如权利要求7所述的方法，其特征在于，进一步包括：

源端速率控制实体根据接收到的对端速率控制实体支持的无线接入承载子流格式RFCI集，和自身支持的无线接入承载子流格式RFCI集进行协商，得到双方都支持的无线接入承载子流格式RFCI集。

9.如权利要求8所述的方法，其特征在于，进一步包括：

源端速率控制实体根据双方都接受的无线接入承载子流格式RFCI集配置用户终端的传输格式集，或，根据双方都接受的最大速率对应的无线接入承载子流格式RFCI集配置用户终端的传输格式集。

Images