CN102413578B - 实现向用户设备发送数据的方法及装置 - Google Patents

Abstract

本发明公开了一种实现向用户设备发送数据的方法，包括，将小区能力集上报到RNC；RNC分析所述小区能力集，如果获知用户设备所属基站及其下属小区支持处于CELL_PCH状态或URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则当所述用户设备进入CELL_PCH或URA_PCH状态，RNC将用户设备所需数据发送给基站；所述基站在高速物理下行共享信道上将所述数据传输给所述用户设备。本发明还公开了一种实现向用户设备发送数据的系统，包括能力上报单元、RNC和基站。本发明还公开了一种无线网络控制器。

Description

实现向用户设备发送数据的方法及装置

技术领域

本发明涉及无线通信技术，特别是实现向用户设备发送数据的方法、系统及设备。 

背景技术

通用移动通信系统(UMTS)是第三代合作项目(3GPP)负责推动并标准化的第三代移动通信系统，包括核心网、无线接入网和用户设备(UE)等子系统。其中，UMTS无线接入网(UTRAN)的结构如图1所示，其中，一个Node B(节点B)包含一个或多个小区，Node B与无线网络控制器(RNC)之间的接口为Iub接口，RNC与RNC之间的接口为Iur接口，RNC与核心网的接口为Iu接口。RNC与其所控制的Node B组成无线网络子系统(RNS)，UE则通过Uu接口，即无线空中接口与UTRAN相连，所述Uu接口在图1中未示出。 

UTRAN的Iub和Iur接口分为控制平面和用户平面两个部分，其中控制平面分别对应节点B应用部分(NBAP)协议和无线网络子系统应用部分(RNSAP)协议；用户平面为数据帧(FP)协议，包括专用信道帧协议和公共信道帧协议，用于传输RNC和Node B之间的用户平面的数据分组。 

在无线空中接口(Uu接口)上，与高速下行分组接入(HSDPA)相关的协议主要涉及物理层、媒体接入控制(MAC)层以及相应的无线资源控制(RRC)层。如图2所示，RRC层包括空闲模式和连接模式两个基本的工作模式，其中连接模式进一步包括小区专用信道状态(CELL_DCH)、小区前向接入信道状态(CELL_FACH)、小区寻呼信道状态(CELL_PCH)和用户注册区寻呼信道状态(URA_PCH)共四种子状态。RNC通过控制 UE在不同的RRC连接子状态之间迁移，来实现无线资源的有效使用。例如，当UE有大量数据需要传输时，该UE可在CELL_DCH状态下使用HSDPA与高速上行分组接入(HSUPA)来实现高速数据传输；当UE只有较少量数据需要传输时，则可进入CELL_FACH状态，通过在上行方向上，承载于物理随机接入信道(PRACH)上的随机接入信道(RACH)，以及下行方向承载在辅公共控制物理信道(S-CCPCH)上的前向接入信道(FACH)来传输数据；而当UE暂时没有数据需要传输时，则进入其它的RRC连接子状态，从而减少对无线资源的占用。 

HSDPA是3GPP中引入的一种下行无线增强技术，其峰值速率高达14.4Mbps，由于采用了基于自适应调制编码的链路自适应技术、基于物理层重传和软合并的混合自动重传请求(HARQ)、快速多用户分组调度、2ms短帧等关键技术，具有频谱效率高、下行传输速率大、传输时延小等明显的优势，从而可以对分组数据业务提供有效地支持。 

在物理层，HSDPA下行包括两个物理信道，一个是用于承载用户数据信息高速物理下行共享信道(HS-PDSCH)，另一个是用于承载解调伴随数据信道HS-PDSCH所需信令的高速共享控制信道(HS-SCCH)。HSDPA在上行方向增加了一个高速专用物理控制信道(HS-DPCCH)，该信道用于承载反馈下行数据帧通过HS-PDSCH是(ACK)否(NACK)被正确接收的信息，或者用于反馈信道质量指示(CQI)。 

在通常状况下，UE通过HS-SCCH获知HS-PDSCH上是否有Node B发送给它的数据，并能够从HS-SCCH上获得解调HS-PDSCH上数据所需的传输格式和资源信息，Node B则通过HS-DPCCH获知数据是否被正确接收，如果不正确，将发起重传，否则发送新数据。 

具体地说，UE在每个传输时间间隔(TTI)上，通过监听HS-SCCH来判断相应TTI的HS-PDSCH信道所承载的数据是否为属于自己的数据。其中，HS-SCCH承载的信息包括16个比特的高速下行共享信道无线网络临时标识(H-RNTI)。UE就是根据H-RNTI来判断相应TTI的HS-PDSCH信道 所承载的是否为属于自己的数据。 

HSDPA在原有协议中只能用于CELL_DCH状态，但在更新的相关协议中，提出对寻呼处于CELL_PCH和URA_PCH状态的UE，也使用HS-PDSCH信道，而不是使用传统的S-CCPCH信道。通过将PCH映射到HS-PDSCH上，在HS-PDSCH寻呼所需的UE，使采用HS-PDSCH信道进行语音或数据通信的UE能够不用在HS-PDSCH信道和S-CCPCH信道上频繁切换来监听寻呼消息和数据，从而减少切换时延和UE耗电。另外，节省下来的S-CCPCH信道使用的码字与功率可用于HSPA传输，可以明显提高系统的容量和吞吐率。 

在这里，对于处于CELL_PCH/URA_PCH状态的UE，对其寻呼仍然通过HS-PDSCH来实现，即PCH是映射到HS-PDSCH上，而不是映射到传统的S-CCPCH上，将这一过程称为HS-PCH。 

在现有的协议中，实现对处于CELL_PCH/URA_PCH状态的UE的寻呼包括两种流程，一种是UE所归属的基站始终处于服务RNC(SRNC)管辖范围内，没有相邻RNC为其提供服务；另一种是UE第一次漫游到相邻RNC下属小区。 

第一种实现方式的流程如图3所示，当处于CELL_DCH状态的UE持续数据量偏小时，将会转入到CELL_FACH状态，如果数据量又进一步减小，则会从CELL_FACH状态转入CELL_PCH或者URA_PCH状态，此时UE会从S-CCPCH上接收寻呼数据，当SRNC决定在下属的小区对处于CELL_PCH或者URA_PCH状态的UE进行寻呼时，首先通过在SRNC和各个小区中建立的PCH传输承载将包含寻呼相关信息的PCH数据帧传输给NodeB；NodeB根据接收到的信息将PCH映射到S-CCPCH上进行广播。 

在这种实现方式中，并不能准确实现HS-PCH，一方面因为SRNC目前不知道下属小区是否支持基于HS-PDSCH上的寻呼，如果该NodeB或小区不支持该功能，则会寻呼失败；另一方面，PCH数据帧是通过SRNC与NodeB间的公共传输信道建立过程中建立的传输承载传输的，虽然SRNC 希望采用映射到HS-PDSCH上的方式进行寻呼，但NodeB无法识别该传输承载上的PCH数据帧该映射到哪种物理信道上。 

另一种实现方式的流程如图4所示，处于HS-PCH状态的UE进入相邻RNC，即漂移RNC(DRNC)下属的小区，并通过小区更新(Cell Update)过程通知SRNC自己目前所在的小区位置；SRNC决定在相邻RNC的小区中对UE进行寻呼，通过基于RNSAP协议的寻呼请求(Paging Request)消息将寻呼所需的参数通知给DRNC；DRNC根据SRNC的命令，构造Paging消息并映射到S-CCPCH上进行广播，从而实现对UE的寻呼。 

在该实现方式中，同样不能准确实现HS-PCH，因为处CELL_PCH/URA_PCH状态，且下行的传输信道映射到HS-PDSCH上传输的UE漫游到相邻RNC时，DRNC中没有UE的状态信息，即不知道对于该UE的寻呼消息是映射到HS-PDSCH信道上还是传统的S-CCPCH信道上。如果这时DRNC将从S-CCPCH上下发消息，而UE却是在HS-PDSCH上监听自己所需要的信息，则会导致信息丢失。 

通过以上描述可见，无论UE处于SRNC范围，还是进入了DRNC范围，目前的技术方案都无法准确实现HS-PCH，也就是进入CELL_PCH/URA_PCH状态的UE，PCH数据帧不是映射到传统的S-CCPCH信道，而是映射到HS-PDSCH信道，即通过HS-PDSCH信道来接收数据的目的。 

此外，另外，在更新的协议中，引入了许多新的技术，例如在下行的HSDPA中引入了64正交幅度调制(QAM)，在上行的HSUPA信道上引入了16QAM等，通过这些技术来提高UE空口数据的吞吐率。但是，目前当UE漫游到相邻RNC中时，SRNC不知道DRNC小区是否支持这些新功能，这时如果SRNC要求DRNC提供其力所不能及的服务时，将会导致在DRNC中建立链路失败。 

发明内容

有鉴于此，本发明的目的在于提供实现向用户设备发送数据的方法、系统及设备，用于实现处于CELL_PCH或URA_PCH状态的UE，通过HS-PDSCH信道来接收数据。 

本发明的实施例提供了一种实现向用户设备发送数据的方法，包括： 

将小区能力集上报到无线网络控制器RNC； 

RNC分析所述小区能力集，如果获知用户设备所属基站及其下属小区支持处于小区寻呼信道CELL_PCH状态或用户注册区寻呼信道URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则当所述用户设备进入CELL_PCH或URA_PCH状态，RNC将用户设备所需数据发送给基站； 

所述基站在高速物理下行共享信道上将所述数据传输给所述用户设备。 

本发明的实施例提供了一种实现向用户设备发送数据的系统，包括用户设备，该系统还包括： 

能力上报单元，用于将用户设备所属基站及其下属小区的小区能力集上报到所述RNC； 

RNC，用于接收并分析所述小区能力集，如果用户设备所属基站及其下属小区支持处于CELL_PCH状态或URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则与基站建立公共传输信道；当所述用户设备进入CELL_PCH或URA_PCH状态时，通过所述公共传输信道，将数据发送给基站； 

基站，用于将所述数据通过高速物理下行共享信道传输给所述用户设备。 

本发明的实施例提供了一种无线网络控制器，包括： 

能力处理单元，用于接收并分析用户设备所属基站及其下属小区的小区能力集，如果所述基站及其下属小区支持处于CELL_PCH状态或URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则发起公共传输信道 的建立请求； 

信道创建模块，用于根据所述建立请求，为RNC与基站间的数据传输创建公共传输信道； 

数据传输单元，用于通过所述公共传输信道，将数据发送给所述基站。 

本发明的实施例通过基站将小区能力集和/或对正交幅度调制的支持上报到RNC，使得RNC能够获知基站及其下属小区是否支持处于CELL_PCH或URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，从而在支持的情况下，通过高速物理下行共享信道将数据传输给用户设备。从而实现了处于SRNC范围内的UE，进入CELL_PCH或URA_PCH状态后，PCH不是映射到传统的S-CCPCH信道，而是映射到HS-PDSCH信道，在HS-PDSCH信道上接收下行数据。而且，通过上报是否支持正交幅度调制，使得RNC可以采用UE支持的正交幅度调制方式，向UE发送数据。 

本发明的实施例还通过在基站中设置能力上报单元，用于将用户设备所属小区的小区能力集和/或对正交幅度调制的支持上报到RNC，并与RNC建立公共传输信道，从而实现了处于SRNC范围内的UE，进入CELL_PCH或URA_PCH状态后，PCH不是映射到传统的S-CCPCH信道，而是映射到HS-PDSCH信道，在HS-PDSCH信道上接收下行数据。 

附图说明

图1为现有技术中UMTS无线接入网的结构图； 

图2为现有技术中RRC层的结构图； 

图3为现有技术中UE所归属的基站始终处于服务RNC范围内实现寻呼的方法流程图； 

图4为现有技术中UE第一次漫游到相邻RNC下属小区实现寻呼的方法流程图； 

图5为本发明的实施例一中处于CELL_FACH状态的UE转入HS-PCH状态的方法流程图； 

图6为本发明的实施例一中通过审计过程使RNC获知NodeB中各小区是否支持HS-PCH功能的方法流程图； 

图7为本发明的实施例一中为每一个用于HS_PCH下的HS-PDSCH传输都建立专门的传输承载的方法流程图； 

图8为本发明的实施例一中删除公共传输信道的方法流程图； 

图9为本发明的实施例一中公共传输信道的重配置方法流程图； 

图10为本发明的实施例一中FP帧的结构图； 

图11为本发明的实施例一中实现处于HS-PCH状态的UE漫游到SRNC下的支持HS-PCH功能的新的小区的数据传输方法流程图； 

图12为本发明的实施例一中实现处于HS-PCH状态的UE漫游到SRNC下的不支持HS-PCH功能的新的小区的数据传输方法流程图； 

图13为本发明的实施例一中实现处于HS-PCH状态的UE漫游到SRNC下的新小区的可选数据传输方法流程图； 

图14为本发明的实施例二中实现处于HS-PCH状态UE在DRNC中支持HS-PCH功能的小区内接收数据的方法流程图； 

图15为本发明的实施例二中实现处于HS-PCH状态UE在DRNC中不支持HS-PCH功能的小区内接收数据的方法流程图； 

图16为本发明的实施例二中实现处于HS-PCH状态UE在DRNC中不知是否支持HS-PCH功能的小区内接收数据的方法流程图； 

图17为本发明的实施例二中实现HS-PCH状态的UE漫游到DRNC的下属小区接收数据的可选方法的流程图； 

图18为本发明实施例三实现向用户设备发送数据的系统结构图。 

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。 

本发明的实施例通过基站将小区能力集和/或对正交幅度调制的支持上 报到RNC，使得RNC能够获知基站及其下属小区是否支持处于CELL_PCH或URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，从而在支持的情况下，通过高速物理下行共享信道将数据传输给用户设备。从而实现了处于SRNC范围内的UE，进入CELL_PCH或URA_PCH状态后，PCH不是映射到传统的S-CCPCH信道，而是映射到HS-PDSCH信道，在HS-PDSCH信道上接收下行数据。而且，通过上报是否支持正交幅度调制，使得RNC可以采用UE支持的正交幅度调制方式，向UE发送数据。 

本发明的实施例一为处于CELL_PCH或URA_PCH状态的UE，一直处于SRNC范围内时，实现HS-PCH状态的方法；实施例二是处于CELL_PCH或URA_PCH状态的UE，漫游到了DRNC范围内时，实现HS-PCH状态的方法。实施例一和实施例二还进一步分为UE是否发生漫游的处理方法。 

实施例一： 

图5为本发明的实施例一中处于CELL_FACH状态的UE转入HS-PCH状态的方法流程图，该方法应用于UE处于SRNC中时，且UE未发生小区间的位置切换，具体包括以下步骤： 

步骤501、NodeB在重启或者RNC需要获知NodeB资源状态时，将小区能力集上报，并建立公共传输信道。 

NodeB重启时，需要重新将自身的资源状态，如是否支持HS-PCH状态等信息上报给SRNC，从而发起本流程，或者SRNC不知道NodeB的资源状态，要想实现HS-PCH，也必须发起此流程。该步骤的目的是让SRNC获知NodeB是否支持HS-PCH，若支持，则建立公共传输信道，以在该信道上传输数据，该公共传输信道就是用于传输通过HS-PDSCH信道发送给UE的数据。其中，UE上报小区能力集有两种方法，第一种方法是采用由NodeB或SRNC发起的审计(Audit)过程，RNC得知NodeB中各个小区是否支持HS-PCH功能并将其保存；另一种是资源状态上报的过程，RNC得知NodeB中各个小区是否支持HS-PCH功能并将其保存。第一种方法的流程如图6所示，包括以下步骤： 

1、NodeB向RNC发送基于NBAP的审计要求(Audit Required)消息，要求发起Audit过程。该步骤并非必须执行，如果RNC主动发起审计流程，则不必执行此步骤。 

2、RNC向NodeB发送审计请求(Audit Request)消息，要求NodeB上报基站的资源状态。 

3、NodeB通过审计响应(Audit Response)消息，将基站下属各个小区的资源状态通知RNC。 

在本发明的实施例一中，扩展了现有的Audit Response消息，在消息中增加了信息元素(IE)，用于指示该基站及其下属的各个本地小区、本地小区组、小区是否支持HS-PCH功能，即能否支持CELL_PCH或URA_PCH状态下，下行寻呼数据在HS-PDSCH上承载。扩展后，Audit Response消息的消息格式如表1所示： 

表1 

在该消息格式中，HS-PCH能力集、小区信息、本地小区信息及本地小区组信息为扩展内容，分别表示基站、小区、本地小区及本地小区组是否支持HS-PCH功能。在本发明的实施例一中，这四项扩展IE并非必须同时存在，可以在消息中只包含其中的一或多项。此外，在这四项扩展IE中，还增加了对于基站及其下属的小区、本地小区和本地小区组是否支持HSDPA上的64QAM和HSUPA上的16QAM的描述，当然，该描述在本发明的实施例中也为可选项，在Audit Response消息中可以包含也可不包含，或只包含关于HSUPA16QAM或HSDPA64QAM的描述。在表1中，信息元素类型和参考是指标准中的索引和章节。其中，对于HS-PCH能力集的表示方式有两种，分别如表2和表3所示： 

表2 

表3 

这两种表示方式的差别在于，表2所示方式是只需该项IE存在，表明支持UE在CELL_PCH或URA_PCH状态下，下行数据映射到HS-PDSCH上传输，不存在则表明不支持；而表3所示方式是用不同的值分别表示是否支持UE在CELL_PCH或URA_PCH状态下，下行数据映射到HS-PDSCH上传输。而对于HSUPA16QAM和HSDPA64QAM的支持情况，同样可以采用这两种方式来表示，在此不再赘述。 

RNC在接收到所述Audit Response消息后，还要进行如下的处理： 

4、RNC接收到Audit Response消息后解析该基站和/或该基站下属的各个本地小区、和/或本地小区组、和/或小区是否支持HS-PCH功能，以及对于HSUPA16QAM和HSDPA64QAM的支持。 

5、如果上述相关IE都表示支持该功能，则将该基站和/或该基站下属的小区和/或本地小区和/或本地小区组的能力集置为可用并保存该信息；如果不支持或者该Audit Response消息中不包含相关的指示IE，则认为该基站和/或该基站下属小区和/或本地小区和/或本地小区组不支持HS-PCH功能，同样保存该信息。 

通过此过程，RNC就获知了NodeB和/或其下属的小区和/或本地小区和/或本地小区组的能力集，及其对于HSUPA16QAM和HSDPA64QAM的支持情况。而第二种获得基站和/或其下属的小区和/或本地小区和/或本地小区组是否支持HS-PCH功能的方法包括以下步骤： 

1、当基站需要上报资源状态给RNC时，将发送资源状态指示(Resource Status Indication)消息给RNC。同样需要对现有的Resource Status Indication消息进行扩展，在消息中增加IE指示基站和/或该基站下属各个小区和/或本地小区和/或本地小区组是否支持HS-PCH功能。具体扩展如表4所示： 

表4 

从表2中可以看出，对于Resource Status Indication消息的扩展方式与Audit Response消息相同，也是扩展基站、小区信息、本地小区信息及本地小区组信息，分别表示基站、小区、本地小区及本地小区组是否支持HS-PCH 功能，并进一步扩展对于HSUPA16QAM和HSDPA64QAM的支持情况。同样，这四项扩展IE以及对于HSUPA16QAM和HSDPA64QAM的支持并非必须同时存在，可以在消息中只包含其中的一或多项。 

2、RNC接收到Resource Status Indication消息后解析该基站和/或该基站下属各个小区和/或本地小区和/或本地小区组是否支持HS-PCH功能，以及对于HSUPA16QAM和HSDPA64QAM的支持情况。 

3、如果相关的IE表示支持该功能，则将该基站和/或该基站下属各个小区和/或本地小区和/或本地小区组的能力集置为可用并保存该信息；如果不支持或者该Resource Status Indication消息中不包含相关的指示IE，则认为该基站和/或该基站下属各个小区和/或本地小区和/或本地小区组不支持HS-PCH功能，并保存该信息。 

以上所述审计过程和资源状态上报过程都能够实现RNC获取NodeB的小区能力集，获知是否支持HS-PCH功能，以及对于HSUPA16QAM和HSDPA64QAM的支持情况。这两种方法可以都执行，也可以只执行其中一个。 

然后，还要在RNC和NodeB之间建立公共传输信道，用于传输RNC给HS-PCH状态UE的下行数据。因为当RNC获知其下属NodeB中的某个小区中有UE进入HS-PCH状态时，而在RNC和NodeB之间并没有为UE传输数据的HS-PDSCH建立传输承载时，必须在RNC和NodeB之间建立相关的传输承载。具体的实现也有两种不同的方式，第一种方式是为每一个用于CELL_PCH或URA_PCH下的HS-PDSCH传输都建立专门的传输承载来实现， 

第一种方式： 

其流程如图7所示，包括以下步骤： 

1、RNC通过NBAP消息公共传输信道建立请求(Common Transport Channel Setup Request)消息通知NodeB，消息中指出了建立用于传输CELL_PCH或URA_PCH状态UE的数据的HS-PDSCH信道的个数，每个 信道相关的公共传输信道ID，采用的特定HS-PCH H-RNTI，用于建立传输承载的绑定ID，传输承载地址，传输网络层的QoS等参数。其中HS-PCH H-RNTI可以是由系统中分配的公共H-RNTI，也可以是原来UE本身分配的RNTI。所述公共H-RNTI是指在一组HS-PDSCH上接收寻呼消息的HS-PCH状态UE分配的一个公共标识。 

其中，需要对Common Transport Channel Setup Request消息进行扩展，扩展后的消息格式如表5所示： 

表5 

在表中增加了HS-PCH信息这一IE，表示要建立的HS-PDSCH信道的公共传输信道ID，采用的特定HS-PCH H-RNTI，用于建立传输承载的绑定ID，传输承载地址，传输网络层的QoS等信息。 

2、NodeB做好建立公共传输信道的准备后，通过NBAP消息公共传输信道建立响应(Common Transport Channel Setup Response)消息响应，消息中给出发建立该传输承载所需的NodeB侧的信息。 

同样，对Common Transport Channel Setup Response消息也需要进行扩展，扩展后的消息格式如表6所示： 

表6 

其中，HS_PCH信息中的HS_PCH参数可以包括但不仅限于： 

表7 

扩展后的Common Transport Channel Setup Response消息中增加了HS_PCH信息的IE，其中包括建立的公共传输信道的ID、绑定ID及传输层地址等信息。 

3、在RNC和NodeB之间建立起各个HS-PCH相关的传输承载。 

通过以上流程，建立了用于为每一个HS-PCH传输所需的承载，但建立 的公共传输信道并不是永久维持，当RNC检测到本小区中已经不存在采用HS-PDSCH传输下行数据的HS_PCH状态的UE，或采用某一特定H-RNTI标识的一组UE，则需要删除相对应的公共传输信道。该删除过程采用现有的协议，通过图8所示流程实现，包括以下步骤： 

1、RNC在公共传输信道删除请求(Common Transport Channel Deletion Request)消息中指明所需要删除的HS-PCH对应的公共传输信道ID，该ID是在信道建立过程中分配的，并将该消息通知NodeB； 

2、NodeB做好删除准备后用公共传输信道删除响应(Common Transport Channel Deletion Response)消息响应RNC的要求； 

3、RNC在接收到响应消息后，则释放该传输承载。 

当有必要对建立的HS-PDSCH传输承载进行重配置时，例如要重新配置传输承载的QoS，则可以发起公共传输信道的重配置过程。该过程如图9所示，包括以下步骤： 

1、RNC在公共传输信道重配置请求(Common Transport Channel Reconfiguration Request)消息中指明所需要重配置的HS-PCH对应的公共传输信道ID及相应的传输网络层服务质量(TNL QoS)，和可能重新分配的HS-PCH H-RNTI，并将该消息通知NodeB。 

在该步骤中，需要修改现有协议中的Common Transport Channel Reconfiguration Request消息，在其中增加重配置的HS-PDSCH传输承载的QoS要求，修改后的消息格式如表8所示： 

表8 

在该消息中的扩展项同样为HS_PCH信息IE，表示需要重配置的HS-PCH H-RNTI和传输网络层承载QoS。 

2、NodeB接收到Common Transport Channel Reconfiguration Request消息后，重配传输承载的QoS，并用NBAP消息公共传输信道重配置响应(Common Transport Channel Reconfiguration Response)消息响应RNC的要求。 

第二种方式： 

该方式是建立为多个H-RNTI对应的HS-PDSCH共用的一条传输承载，其与第一种方式的差别在于：第一种方式是为每一个HS-PDSCH传输都建立专门的传输承载来实现，而第二种方式是为多个H-RNTI对应的HS-PDSCH建立共用的一条传输承载。在第二种方式中，只需修改方式一中经过扩展的Common Transport Channel Setup Request消息，将该消息中的H-RNTI更换成H-RNTI组，修改后，用一个H-RNTI标识该H-RNTI组，用H-RNTI索引表示该组与UE的对应关系。 

表9 

在第二种方式中，由于多个UE在HS-PDSCH上数据的传输承载使用同一个H-RNTI，因此，还要对数据FP帧的结构进行修改，以标识该数据帧属于哪个UE，其中，现有的FP帧的结构如图10所示，具体的修改方法是在帧的共享保留(Spare Extension)位中增加对应的H-RNTI索引，表明该FP帧所传输的数据对应的H-RNTI，即该H-RNTI对于哪些UE。或者在帧中专门增加一个字段用于表示该FP帧所传输的数据对应的H-RNTI。 

该公共传输信道被建立后，对其进行删除和重配置的过程与第一种方式相同，在此不赘述。 

步骤502、处于CELL_FACH状态的UE由于下行数据量较少，从而转入CELL_PCH状态。RNC根据步骤501中获取的小区能力集和已保存的UE能力集，确定该RNC，也就是SRNC进入HS-PCH状态。 

步骤503-步骤504、SRNC和UE之间通过物理信道重配置(Physical Channel Reconfiguration)释放Uu口的FACH相关资源，并指示UE进入HS-PCH状态，及分配UE在该状态下的H-RNTI。 

步骤505-步骤507、RNC和NodeB之间通过无线连接删除(Radio Link Deletion)过程，释放CELL_FACH相关的资源，释放后，这些资源对应的码字和功率可以收回。 

此时，如果RNC发现在该小区内，还没有为该UE分配的HS-PCH H-RNTI建立相应的传输承载，或以前的建立失败，将发起步骤501中的公共传输信道建立过程，为其建立相应的传输承载。 

步骤508、当RNC中有下发给处于HS-PCH状态UE的数据时，通过事先建立的传输承载将数据帧下发给NodeB。 

步骤509、NodeB将从HS-PCH传输承载上接收下发数据，将数据映射到HS-PDSCH上传输给UE。 

通过步骤501到步骤509的方法，实现了处于CELL_FACH状态的UE转入HS-PCH状态，但该方法执行的前提是UE没有发生小区漫游，始终处于同一个小区范围内。但是UE不可能总是处于同一小区中，注定会漫游到其它小区范围内，此时，就要采用以下所述的方法，实现UE的HS-PCH状态。 

首先，当处于已经处于HS-PCH状态的UE漫游到一个新的小区，且该小区与前一小区是归属于同一SRNC的，则该UE的处理面临两种不同的情况：一种是该新的小区支持HS-PCH功能，另一种是该新的小区不支持HS-PCH功能。 

对于新的小区支持HS-PCH功能的情况，采用图11所示方法实现处于HS-PCH状态的UE漫游到SRNC下的支持HS-PCH功能的新的小区的数据 传输，包括以下步骤： 

步骤1101、处于HS-PCH状态的UE漫游到SRNC下属的一个新小区，通过广播信道(BCH)上广播的系统信息，得知该小区支持HS-PCH功能； 

步骤1102、UE通过RACH信道向SRNC发送小区更新(Cell Update)消息，要求小区重定向，并在HS-PDSCH上接收响应消息； 

如果该小区中还没有为HS-PCH建立相应的传输承载，则通过步骤501中的公共传输信道建立过程，建立相应的SRNC与NodeB间的传输承载； 

步骤1103、SRNC通过HS-PDSCH将相应的响应消息小区更新确认(Cell Update Confirm)消息发送给UE。 

在本发明实施例一中，由于各个NodeB在启动时，都会通过步骤501中的方法将小区能力集上报给RNC并保存，因此SRNC已经获知了该新小区是否支持HS-PCH，所以就避免了现有技术中，RNC不知道新小区是否支持HS-PCH，导致在新小区不支持的信道上下发数据。执行了步骤1101至1103，SRNC就可以通知NodeB通过HS-PDSCH向UE发送下行数据了。 

对于新的小区不支持HS-PCH功能的情况，采用图12所示方法实现处于HS-FACH状态的UE漫游到SRNC下的不支持HS-FACH功能的新的小区的数据传输，包括以下步骤： 

步骤1201、处于HS-PCH状态的UE漫游到SRNC下属的一个新小区，通过BCH上广播的系统信息得知该小区不支持HS-PCH功能； 

步骤1202、UE通过RACH信道向RNC发送Cell Update消息，要求小区重定向，并在S-CCPCH上接收响应消息； 

步骤1203、RNC接收到UE上传的Cell Update消息后，根据已知的小区能力集得知该HS-PCH状态的UE新接入的小区不支持HS-PCH功能，则将该UE转入传统的CELL_PCH或URA_PCH状态，并通过S-CCPCH将相应的响应消息Cell Update Confirm发送给UE。 

除了以上这两种方法，还有一种可选的方法来实现处于HS-PCH状态的UE漫游到SRNC下属的小区时的处理，如图13所示，包括以下步骤： 

步骤1301、处于HS-PCH状态的UE漫游到SRNC下属的一个新小区，通过BCH上广播的系统信息得知该小区的小区能力集； 

步骤1302、无论该小区是否支持HS-PCH功能，UE都通过RACH信道向RNC发送Cell Update消息，要求小区重定向，并在S-CCPCH上接收响应消息； 

步骤1303、RNC接收到UE上传的Cell Update消息后，根据已知的小区能力集得知该HS-PCH状态的UE新接入的小区是否支持HS-PCH功能，不论是否支持，都将该UE转入传统的CELL_PCH或URA_PCH状态，并通过S-CCPCH将相应的响应消息Cell Update Confirm发送给UE。 

UE接收到Cell Update Confirm消息后转入传统的CELL_PCH或URA_PCH状态。 

实施例二： 

本实施例是处于HS-PCH状态UE在相邻RNC中小区的接收数据实现过程。当已经处于HS-PCH状态的UE漫游到一个新的小区，且该小区是归属于相邻RNC，即DRNC，则该UE的处理也要面临两种不同的情况：一种是该小区支持HS-PCH功能，另一种是该小区不支持HS-PCH功能。 

对于第一种情况，其处理方法如图14所示，具体包括： 

步骤1401、处于HS-PCH状态的UE漫游到DRNC下属的一个新小区，通过BCH上广播的系统信息得知该小区支持HS-PCH功能。 

步骤1402、UE通过RACH信道向DRNC发送Cell Update消息，要求小区重定向，并在HS-PDSCH上接收响应消息，该消息也可以是其它层3(L3)消息，并不仅限于Cell Update消息。 

步骤1403、DRNC接收到Cell Update消息后，通过该消息携带的用户登记区域无线网络临时标识符(U-RNTI)标志判断出该UE属于其它RNC，因此DRNC将构造RNSAP消息上行信号传输指示(Uplink Signalling Transfer Indication)消息，在该消息中的小区能力容量(Cell Capability Container FDD)IE中指示该DRNC中的小区是支持HS-PCH功能的，其中 的L3信息IE中包含了接收到的Uu口消息。 

本实施例需要对Uplink Signalling Transfer Indication消息进行扩展，在消息中增加UE所隶属的DRNC小区是否支持HS-PCH功能的指示，通过在Cell Capability Container FDD IE增加对DRNC中小区能力集的描述来实现该功能。扩展后的该消息如表10所示： 

表10 

其中，对于现有的Cell Capability Container FDD IE的扩展主要是将其第15个比特设置为对是否支持HS-PCH功能的指示。在本实施例中，设置当SRNC检测到上报的该IE中第15比特位为1，则认为所指示的小区支持HS-PCH功能。当然，在具体的应用中，并不仅限于设置为第15比特位，采用其它比特位表示，其实质是一样的。此外，本实施例还在该IE中增加了对于HSUPA16QAM和HSDPA64QAM的支持情况，分别用第19比特和第20比特表示是否支持HSDPA64QAM和HSUPA16QAM。扩展后具体该IE的含义如表11所示： 

表11 

在现有协议中，第15、19和20比特为保留位，本发明的实施例对其扩展，当相应比特为1时，表示支持相应功能，否则为不支持。反之亦为同理。 

步骤1404、SRNC接收到Uplink Signalling Transfer Indication消息后，从中解析出L3消息并进行相应处理。以Cell Update为例，SRNC判断该UE属于HS-PCH状态，且目前所在的小区支持HS-PCH功能，因此构造响应消息Cell Update Confirm，并将其包含在RNSAP消息下行信号传输请求(Downlink Signalling Transfer Request)消息中传给DRNC。 

步骤1405、由于本实施例中新的小区支持HS-FACH功能，DRNC解析 出Downlink Signalling Transfer Request消息中的L3消息后，通过映射到HS-PDSCH上的FACH信道传送给UE。 

步骤1406、当SRNC决定在DRNC下属的小区中寻呼该UE时，将在RNSAP Paging Request消息中指出将PCH映射到HS-PDSCH上进行寻呼。 

本实施例需要对Paging Request消息进行扩展，指出该寻呼请求是通过HS-PDSCH下发还是通过S-CCPCH下发，扩展后的Paging Request消息格式如表12所示： 

表12 

在消息中增加了寻呼信道映射类型的IE，表示该寻呼是通过HS-PDSCH下发还是通过S-CCPCH下发，或者是同时通过HS-PDSCH和S-CCPCH下发，具体的指示方法如表13所示： 

表13 

步骤1407、DRNC根据SRNC的指示，将在HS-PDSCH上寻呼UE。 

在以上流程中，UE也可以不执行小区重定向的过程，直接由SRNC对该UE发起寻呼，即只执行步骤1406和1407。 

对于第二种情况，即新的小区不支持HS-PCH功能，解决方案如图15所示，包括以下步骤： 

步骤1501、处于HS-PCH状态的UE漫游到DRNC下属的一个新小区，通过BCH上广播的系统信息得知该小区不支持HS-PCH功能。 

步骤1502、UE通过RACH信道向DRNC发送Cell Update消息，要求小区重定向，并在S-CCPCH上接收响应消息。 

步骤1503、DRNC接收到L3消息Cell Update后，由消息中携带的U-RNTI标志判断出该UE属于其它RNC，因此DRNC将构造RNSAP消息Uplink Signalling Transfer Indication，在该消息中的Cell Capability Container FDD IE中指示该RNC中的小区是不支持HS-PCH功能的，其中的L3 Information IE中包含了接收到的Uu口消息。对于Uplink Signalling Transfer Indication的扩展与前述方法相同。 

步骤1504、SRNC接收到Uplink Signalling Transfer Indication消息，从中解析出L3消息并进行相应处理，以Cell Update为例，SRNC判断该UE属于HS-PCH状态，且目前所在的小区不支持HS-PCH功能，因此构造响应消息Cell Update Confirm，并将其包含在RNSAP消息Downlink Signalling Transfer Request消息中传给DRNC，指示UE转入普通的CELL_PCH或URA_PCH状态。 

步骤1505、DRNC解析出Downlink Signalling Transfer Request消息中的L3消息，并通过映射到S-CCPCH上的FACH信道传送给UE。UE接收到响应消息后，转入普通的CELL_PCH或URA_PCH状态。 

步骤1506、当SRNC决定在DRNC下属的小区中寻呼该UE时，将在RNSAP Paging Request消息中指出将PCH映射到S-CCPCH上进行寻呼。对于Paging Request消息的扩展，也与前述方法相同。 

步骤1507、DRNC根据SRNC的指示，将PCH映射到S-CCPCH上，通过S-CCPCH对UE进行寻呼。 

与新小区支持HS-PCH功能的流程相同，本流程中，UE同样可以不执行小区重定向的过程，直接由SRNC对该UE发起寻呼，即只执行步骤1506和1507。 

除了前述新的小区支持HS-PCH功能或不支持HS-PCH功能这两种情况，还有一种特殊的情况，那就是SRNC在相邻RNC的小区内，对处于URA_PCH或者CELL_PCH状态的UE进行寻呼时，不知这些小区是否支持HS-PCH功能，这时的处理方法如图16所示，包括： 

步骤1601、当SRNC决定在DRNC下属的小区中寻呼该UE时，将在RNSAP Paging Request消息中指出将PCH映射到S-CCPCH和HS-PDSCH上同时进行寻呼； 

步骤1602、DRNC根据SRNC的指示，将PCH信道同时映射到HS-PDSCH和S-CCPCH上，同时通过HS-PDSCH和S-CCPCH进行寻呼。 

另外，还有一种替代方法实现HS-PCH状态的UE漫游到相邻RNC的下属小区接收数据，该方法核心是无论新的小区是否支持HS-PCH功能，UE都直接转换到传统的CELL_PCH或URA_PCH状态。该方法流程如图17所示，包括： 

步骤1701、处于HS-PCH状态的UE漫游到DRNC下属的一个新小区，通过BCH上广播的系统信息得知该小区的能力集； 

步骤1702、无论该小区是否支持HS-PCH功能，UE通过RACH信道向RNC发送Cell Update消息，要求小区重定向，并在S-CCPCH上接收响应消息； 

步骤1703、DRNC接收到L3消息Cell Update后，由其携带的U-RNTI标志判断出该UE属于其它RNC，因此，DRNC将构造RNSAP消息Uplink Signalling Transfer Indication； 

步骤1704、SRNC接收到Uplink Signalling Transfer Indication消息，从中解析出L3消息并进行相应处理，以Cell Update为例，将构造响应消息Cell Update Confirm，并将该响应消息包含在RNSAP消息Downlink Signalling Transfer Request消息中传给DRNC，并指示UE转入普通的CELL_PCH或URA_PCH状态； 

步骤1705、DRNC解析出Downlink Signalling Transfer Request消息中的L3消息，并通过映射到S-CCPCH上的FACH信道传送给UE。UE接收到响应消息后，转入普通的CELL_PCH或URA_PCH状态； 

步骤1706、当SRNC决定在相邻RNC中的小区寻呼UE时，通过RNSAP消息Paging Request消息通知DRNC进行寻呼，并指示DRNC将PCH映射 到S-CCPCH上实现。具体的实现可以不携带新增加的Paging Channel Mapped Type IE，即保持原有默认在S-CCPCH上寻呼的方式；也可以在Paging Channel Mapped Type IE中指明将PCH映射到S-CCPCH上实现。 

步骤1707、DRNC根据SRNC的指示，将PCH映射到S-CCPCH上实现寻呼。 

实施例三： 

图18为实现向用户设备发送数据的系统，包括用户设备，还包括： 

能力上报单元，用于将用户设备所属基站及其下属小区的小区能力集上报到所述RNC； 

RNC，用于接收并分析所述小区能力集，如果用户设备所属基站及其下属小区支持处于CELL_PCH状态或URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则与基站建立公共传输信道；当所述用户设备进入CELL_PCH或URA_PCH状态时，通过所述公共传输信道，将数据发送给基站； 

基站，用于将所述数据通过高速物理下行共享信道传输给所述用户设备。 

所述能力上报单元设置在所述基站。 

所述RNC具体包括： 

信道创建模块，用于为RNC与基站间的数据传输创建公共传输信道； 

数据传输单元，用于通过所述公共传输信道，将数据发送给所述基站。 

所述能力上报单元进一步用于：将基站对正交幅度调制的支持信息上报给RNC，则RNC采用基站支持的正交幅度调制方式向基站发送数据。 

总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。 

Claims (5)

1.一种实现向用户设备发送数据的方法，其特征在于，包括：

基站将小区能力集上报到无线网络控制器RNC,以便于所述RNC分析所述小区能力集，如果获知所述基站及其下属小区支持处于小区寻呼信道CELL_PCH状态或用户注册区寻呼信道URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则当用户设备进入CELL_PCH或URA_PCH状态，所述RNC将所述用户设备所需数据发送给所述基站，并且当RNC需要在漂移无线网络控制器DRNC下属的小区中寻呼处于CELL_PCH或URA_PCH状态，且在高速物理下行共享信道上接收寻呼消息的用户设备时，进一步以便于RNC向所述DRNC发送寻呼请求消息，并在消息中设置通过高速物理下行共享信道进行寻呼；使得DRNC通过高速物理下行共享信道寻呼所述用户设备；

所述基站在高速物理下行共享信道上将所述数据传输给所述用户设备。

2.根据权利要求1所述的实现向用户设备发送数据的方法，其特征在于，还进一步包括：

所述基站将其在高速下行分组接入HSDPA中是否支持采用64正交幅度调制和/或在高速上行分组接入HSUPA中是否支持采用16正交幅度调制的信息上报给RNC，以便所述RNC向基站发送所述数据时，采用所述基站支持的正交幅度调制方式。

3.根据权利要求2所述的实现向用户设备发送数据的方法，其特征在于，所述将小区能力集和对正交幅度调制的支持上报到RNC具体包括：

在基站在重启或者RNC请求获得所述基站的资源状态时，所述基站通过审计过程将所述小区能力集和对正交幅度调制的支持上报给所述RNC。

4.一种基站，其特征在于，所述基站用于在高速物理下行共享信道上将数据传输给用户设备,其中所述基站还包括能力上报单元，用于将所述用户设备所属基站及其下属小区的小区能力集上报到无线网络控制器RNC；以便于所述RNC分析所述小区能力集，如果所述用户设备所属基站及其下属小区支持处于小区寻呼信道CELL_PCH状态或用户注册区寻呼信道URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则当用户设备进入CELL_PCH或URA_PCH状态，所述RNC将所述用户设备所需数据发送给所述基站，并且当RNC需要在漂移无线网络控制器DRNC下属的小区中寻呼处于CELL_PCH或URA_PCH状态，且在高速物理下行共享信道上接收寻呼消息的用户设备时，进一步以便于RNC向所述DRNC发送寻呼请求消息，并在消息中设置通过高速物理下行共享信道进行寻呼；使得DRNC通过高速物理下行共享信道寻呼所述用户设备。

5.根据权利要求4所述的装置，其特征在于，所述能力上报单元进一步用于将所述基站对正交幅度调制的支持信息上报给所述RNC，以便于所述RNC采用所述基站支持的正交幅度调制方式向基站发送数据。