实现向用户设备发送数据的方法、系统及设备的制作方法

专利名称：：实现向用户设备发送数据的方法、系统及设备的制作方法
技术领域：
：本发明涉及无线通信技术，特别是实现向用户设备发送数据的方法、系统及设备。
背景技术：
：通用移动通信系统(UMTS)是第三代合作项目(3GPP)负责推动并标准化的第三代移动通信系统，包括核心网、无线接入网和用户设备(UE)等子系统。其中，UMTS无线接入网(UTRAN)的结构如图1所示，其中，一个NodeB(节点B)包含一个或多个小区，NodeB与无线网络控制器(RNC)之间的接口为Iub接口，RNC与RNC之间的接口为Iur接口，RNC与核心网的接口为Iu接口。RNC与其所控制的NodeB组成无线网络子系统(RNS)，UE则通过Uu接口，即无线空中接口与UTRAN相连，所述Uu接口在图1中未示出。UTRAN的Iub和Iur接口分为控制平面和用户平面两个部分，其中控制平面分别对应节点B应用部分(NBAP)协议和无线网络子系统应用部分(RNSAP)协议；用户平面为数据帧(FP)协议，包括专用信道帧协议和公共信道帧协议，用于传输RNC和NodeB之间的用户平面的数据分组。在无线空中接口(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上是否有NodeB发送给它的数据，并能够从HS-SCCH上获得解调HS-PDSCH上数据所需的传输格式和资源信息，NodeB则通过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传输，可以明显提高系统的容量和吞吐率。在这里，对于处于CELI^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)下属的小区，并通过小区更新(CellUpdate)过程通知SRNC自己目前所在的小区位置；SRNC决定在相邻RNC的小区中对UE进行寻呼，通过基于RNSAP协议的寻呼请求(PagingRequest)消息将寻呼所需的参数通知给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为本发明的实施例一中公共传输信道的重配置方法流程图IO为本发明的实施例一中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的审计要求(AuditRequired)消息，要求发起Audit过程。该步骤并非必须执行，如果RNC主动发起审计流程，则不必执行此步骤。2、RNC向NodeB发送审计请求(AuditRequest)消息，要求NodeB上报基站的资源状态。3、NodeB通过审计响应(AuditResponse)消息，将基站下属各个小区的资源状态通知RNC。在本发明的实施例一中，扩展了现有的AuditResponse消息，在消息中增加了信息元素(IE)，用于指示该基站及其下属的各个本地小区、本地小区组、小区是否支持HS-PCH功能，即能否支持CELL—PCH或URA—PCH状态下，下行寻呼数据在HS-PDSCH上承载。扩展后，AuditResponse消息的消息格式如表1所示<table>tableseeoriginaldocumentpage19</column></row><table><table>tableseeoriginaldocumentpage20</column></row><table>在该消息格式中，HS-PCH能力集、小区信息、本地小区信息及本地小区组信息为扩展内容，分别表示基站、小区、本地小区及本地小区组是否支持HS-PCH功能。在本发明的实施例一中，这四项扩展IE并非必须同时存在，可以在消息中只包含其中的一或多项。此外，在这四项扩展IE中，还增加了对于基站及其下属的小区、本地小区和本地小区组是否支持HSDPA上的64QAM和HSUPA上的16QAM的描述，当然，该描述在本发明的实施例中也为可选项，在AuditResponse消息中可以包含也可不包含，或只包含关于HSUPA16QAM或HSDPA64QAM的描述。在表1中，信息元素类型和参考是指标准中的索引和章节。其中，对于HS-PCH能力集的表示方式有两种，分别如表2和表3所示<table>tableseeoriginaldocumentpage21</column></row><table>表2<table>tableseeoriginaldocumentpage21</column></row><table>表3这两种表示方式的差别在于，表2所示方式是只需该项IE存在，表明支持UE在CELL_PCH或URA—PCH状态下，下行数据映射到HS-PDSCH上传输，不存在则表明不支持；而表3所示方式是用不同的值分别表示是否支持UE在CELL—PCH或URA—PCH状态下，下行数据映射到HS-PDSCH上传输。而对于HSUPA16QAM和HSDPA64QAM的支持情况，同样可以采用这两种方式来表示，在此不再赘述。RNC在接收到所述AuditResponse消息后，还要进行如下的处理4、RNC接收到AuditResponse消息后解析该基站和/或该基站下属的各个本地小区、和/或本地小区组、和/或小区是否支持HS-PCH功能，以及对于HSUPA16QAM和HSDPA64QAM的支持。5、如果上述相关IE都表示支持该功能，则将该基站和/或该基站下属的小区和/或本地小区和/或本地小区组的能力集置为可用并保存该信息；如果不支持或者该AuditResponse消息中不包含相关的指示IE，则认为该基站和/或该基站下属小区和/或本地小区和/或本地小区组不支持HS-PCH功能，同样保存该信息。通过此过程，RNC就获知了NodeB和/或其下属的小区和/或本地小区和/或本地小区组的能力集，及其对于HSUPA16QAM和HSDPA64QAM的支持情况。而第二种获得基站和/或其下属的小区和/或本地小区和/或本地小区组是否支持HS-PCH功能的方法包括以下步骤1、当基站需要上报资源状态给RNC时，将发送资源状态指示(ResourceStatusIndication)消息给RNC。同样需要对现有的ResourceStatusIndication消息进行扩展，在消息中增加IE指示基站和/或该基站下属各个小区和/或本地小区和/或本地小区组是否支持HS-PCH功能。具体扩展如表4所示:<table>tableseeoriginaldocumentpage22</column></row><table>表4从表2中可以看出，对于ResourceStatusIndication消息的扩展方式与AuditResponse消息相同，也是扩展基站、小区信息、本地小区信息及本地小区组信息，分别表示基站、小区、本地小区及本地小区组是否支持HS-PCH功能，并进一步扩展对于HSUPA16QAM和HSDPA64QAM的支持情况。同必须同时存在，可以在消息中只包含其中的一或多项。2、RNC接收到ResourceStatusIndication消息后解析该基站和/或该基站下属各个小区和/或本地小区和/或本地小区组是否支持HS-PCH功能，以及对于HSUPA16QAM和HSDPA64QAM的支持情况。3、如果相关的IE表示支持该功能，则将该基站和/或该基站下属各个小区和/或本地小区和/或本地小区组的能力集置为可用并保存该信息；如果不支持或者该ResourceStatusIndication消息中不包含相关的指示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消息公共传输信道建立请求(CommonTransportChannelSetupRequest)消息通知NodeB,消息中指出了建立用于传输CELL—PCH或URA_PCH状态UE的数据的HS-PDSCH信道的个数，每个信道相关的公共传输信道ID,采用的特定HS-PCHH-RNTI，用于建立传输承载的绑定ID,传输承载地址，传输网络层的QoS等参数。其中HS-PCHH-RNTI可以是由系统中分配的公共H-RNTI，也可以是原来UE本身分配的RNTI。所述公共H-RNTI是指在一组HS-PDSCH上接收寻呼消息的HS-PCH状态UE分配的一个公共标识。其中，需要对CommonTransportChannelSetupRequest消息进行扩展，扩展后的消息格式如表5所示:<table>tableseeoriginaldocumentpage24</column></row><table>表5在表中增加了HS-PCH信息这一IE,表示要建立的HS-PDSCH信道的公共传输信道ID，采用的特定HS-PCHH-RNTI,用于建立传输承载的绑定ID，传输承载地址，传输网络层的QoS等信息。2、NodeB做好建立公共传输信道的准备后，通过NBAP消息公共传输信道建立响应(CommonTransportChannelSetupResponse)消息响应，消息中给出发建立该传输承栽所需的NodeB侧的信息。同样，对CommonTransportChannelSetupResponse消息也需要进行扩展，扩展后的消息格式如表6所示:<table>tableseeoriginaldocumentpage25</column></row><table>表7扩展后的CommonTransportChannelSetupResponse消息中增加了HS一PCH信息的IE，其中包括建立的公共传输信道的ID、绑定ID及传输层地址等信息。3、在RNC和NodeB之间建立起各个HS-PCH相关的传输承载。通过以上流程，建立了用于为每一个HS-PCH传输所需的承载，但建立的公共传输信道并不是永久维持，当RNC检测到本小区中已经不存在采用HS-PDSCH传输下行数据的HS—PCH状态的UE，或采用某一特定H-RNTI标识的一组UE,则需要删除相对应的公共传输信道。该删除过程采用现有的协议，通过图8所示流程实现，包括以下步骤1、RNC在公共传输信道删除请求(CommonTransportChannelDeletionRequest)消息中指明所需要删除的HS-PCH对应的公共传输信道ID,该ID是在信道建立过程中分配的，并将该消息通知NodeB;2、NodeB做好删除准备后用公共传输信道删除响应(CommonTransportChannelDeletionResponse)消息响应RNC的要求；3、RNC在接收到响应消息后，则释放该传输承载。当有必要对建立的HS-PDSCH传输承载进行重配置时，例如要重新配置传输承载的QoS，则可以发起公共传输信道的重配置过程。该过程如图9所示，包括以下步骤1、RNC在Z/^共传输信道重配置请求(CommonTransportChannelReconfigurationR叫uest)消息中指明所需要重配置的HS-PCH对应的公共传输信道ID及相应的传输网络层服务质量(TNLQoS),和可能重新分配的HS-PCHH-RNTI,并将该消息通知NodeB。在该步骤中，需要修改现有协议中的CommonTransportChannelReconfigurationRequest消息，在其中增加重配置的HS-PDSCH传输承载的QoS要求，修改后的消息格式如表8所示<table>tableseeoriginaldocumentpage27</column></row><table>表8在该消息中的扩展项同样为HS_PCH信息IE,表示需要重配置的HS-PCHH-RNTI和传输网络层承栽QoS。2、NodeB接收到CommonTransportChannelReconfigurationRequest消息后，重配传输承栽的QoS，并用NBAP消息公共传输信道重配置响应(CommonTransportChannelReconfigurationResponse)消息响应RNC的要求。第二种方式该方式是建立为多个H-RNTI对应的HS-PDSCH共用的一条传输承载，其与第一种方式的差别在于第一种方式是为每一个HS-PDSCH传输都建立专门的传输承栽来实现，而第二种方式是为多个H-RNTI对应的HS-PDSCH建立共用的一条传输承载。在第二种方式中，只需修改方式一中经过扩展的CommonTransportChannelSetupRequest消息，将该消息中的H-RNTI更换成H-RNTI组，修改后，用一个H-RNTI标识该H-RNTI组，用H-RNTI索引表示该组与UE的对应关系。<table>tableseeoriginaldocumentpage28</column></row><table>表9在第二种方式中，由于多个UE在HS-PDSCH上数据的传输承载使用同一个H-RNTI，因此，还要对数据FP帧的结构进行修改，以标识该数据帧属于哪个UE,其中，现有的FP帧的结构如图IO所示，具体的修改方法是在帧的共享保留(SpareExtension)位中增加对应的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之间通过物理信道重配置(PhysicalChannelReconfiguration)释放Uu口的FACH相关资源，并指示UE进入HS-PCH状态，及分配UE在该状态下的H-RNTI。步骤505-步骤507、RNC和NodeB之间通过无线连接删除(RadioLinkDeletion)过程，释放CELL—FACH相关的资源，释放后，这些资源对应的码字和功率可以收回。此时，如果RNC发现在该小区内，还没有为该UE分配的HS-PCHH-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功能的情况，采用图ll所示方法实现处于HS-PCH状态的UE漫游到SRNC下的支持HS-PCH功能的新的小区的数据传输，包括以下步骤步骤1101、处于HS-PCH状态的UE漫游到SRNC下属的一个新小区，通过广播信道(BCH)上广播的系统信息，得知该小区支持HS-PCH功能；步骤1102、UE通过RACH信道向SRNC发送小区更新(CellUpdate)消息，要求小区重定向，并在HS-PDSCH上接收响应消息；如果该小区中还没有为HS-PCH建立相应的传输承载，则通过步骤501中的公共传输信道建立过程，建立相应的SRNC与NodeB间的传输承载；步骤1103、SRNC通过HS-PDSCH将相应的响应消息小区更新确认(CellUpdateConfirm)消息发送给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发送CellUpdate消息，要求小区重定向，并在S-CCPCH上接收响应消息；步骤1203、RNC接收到UE上传的CellUpdate消息后,根据已知的小区能力集得知该HS-PCH状态的UE新接入的小区不支持HS-PCH功能，则将该UE转入传统的CELL—PCH或URA—PCH状态，并通过S-CCPCH将相应的响应消息CellUpdateConfirm发送给UE。除了以上这两种方法，还有一种可选的方法来实现处于HS-PCH状态的UE漫游到SRNC下属的小区时的处理，如图13所示，包括以下步骤步骤1301、处于HS-PCH状态的UE漫游到SRNC下属的一个新小区，通过BCH上广播的系统信息得知该小区的小区能力集；步骤1302、无论该小区是否支持HS-PCH功能，UE都通过RACH信道向RNC发送CellUpdate消息，要求小区重定向，并在S-CCPCH上接收响应消息；步骤1303、RNC接收到UE上传的CellUpdate消息后，根据已知的小区能力集得知该HS-PCH状态的UE新接入的小区是否支持HS-PCH功能，不论是否支持，都将该UE转入传统的CELL—PCH或URA—PCH状态，并通过S-CCPCH将相应的响应消息CellUpdateConfirm发送给UE。UE接收到CellUpdateConfirm消息后转入传统的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发送CellUpdate消息，要求小区重定向，并在HS-PDSCH上接收响应消息，该消息也可以是其它层3(L3)消息，并不仅限于CellUpdate消息。步骤1403、DRNC接收到CellUpdate消息后，通过该消息携带的用户登记区域无线网络临时标识符(U-RNTI)标志判断出该UE属于其它RNC，因此DRNC将构造RNSAP消息上行信号传输指示(UplinkSignallingTransferIndication)消息，在该消息中的小区能力容量(CellCapabilityContainerFDD)IE中指示该DRNC中的小区是支持HS-PCH功能的，其中的L3信息IE中包含了接收到的Uu口消息。本实施例需要对UplinkSignallingTransferIndication消息进行扩展，在消息中增加UE所隶属的DRNC小区是否支持HS-PCH功能的指示，通过在CellCapabilityContainerFDDIE增加对DRNC中小区能力集的描述来实现该功能。扩展后的该消息如表IO所示<table>tableseeoriginaldocumentpage32</column></row><table>表10其中，对于现有的CellC叩abilityContainerFDDIE的扩展主要是将其第15个比特设置为对是否支持HS-PCH功能的指示。在本实施例中，设置当SRNC检测到上报的该IE中第15比特位为1，则认为所指示的小区支持HS-PCH功能。当然，在具体的应用中，并不仅限于设置为第15比特位，采用其它比特位表示，其实质是一样的。此外，本实施例还在该IE中增加了对于HSUPA16QAM和HSDPA64QAM的支持情况，分别用第19比特和第20比特表示是否支持HSDPA64QAM和HSUPA16QAM。扩展后具体该IE的含义如表11所示<table>tableseeoriginaldocumentpage33</column></row><table>表11在现有协议中，第15、19和20比特为保留位，本发明的实施例对其扩展，当相应比特为1时，表示支持相应功能，否则为不支持。反之亦为同理。步骤1404、SRNC接收到UplinkSignallingTransferIndication消息后，从中解析出L3消息并进行相应处理。以CellUpdate为例，SRNC判断该UE属于HS-PCH状态，且目前所在的小区支持HS-PCH功能，因此构造响应消息CellUpdateConfirm,并将其包含在RNSAP消息下行信号传输请求(DownlinkSignallingTransferR叫uest)消息中传给DRNC。步骤1405、由于本实施例中新的小区支持HS-FACH功能，DRNC解析出DownlinkSignallingTransferRequest消息中的L3消息后，通过映射到HS-PDSCH上的FACH信道传送给UE。步骤1406、当SRNC决定在DRNC下属的小区中寻呼该UE时，将在RNSAPPagingRequest消息中指出将PCH映射到HS-PDSCH上进行寻呼。本实施例需要对PagingRequest消息进行扩展，指出该寻呼请求是通过HS-PDSCH下发还是通过S-CCPCH下发，扩展后的PagingRequest消息格式如表12所示<table>tableseeoriginaldocumentpage34</column></row><table>表12在消息中增加了寻呼信道映射类型的IE,表示该寻呼是通过HS-PDSCH下发还是通过S-CCPCH下发，或者是同时通过HS-PDSCH和S-CCPCH下发，具体的指示方法如表13所示<table>tableseeoriginaldocumentpage34</column></row><table>表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发送CellUpdate消息，要求小区重定向，并在S-CCPCH上接收响应消息。步骤1503、DRNC接收到L3消息CellUpdate后，由消息中携带的U-RNTI标志判断出该UE属于其它RNC,因此DRNC将构造RNSAP消息UplinkSignallingTransferIndication,在该消息中的CellCapabilityContainerFDDIE中指示该RNC中的小区是不支持HS-PCH功能的，其中的L3InformationIE中包含了接收到的Uu口消息。对于UplinkSignallingTransferIndication的扩展与前述方法相同。步骤1504、SRNC接收到UplinkSignallingTransferIndication消息，从中解析出L3消息并进行相应处理，以CellUpdate为例，SRNC判断该UE属于HS-PCH状态，且目前所在的小区不支持HS-PCH功能，因此构造响应消息CellUpdateConfirm,并将其包含在RNSAP消息DownlinkSignallingTransferRequest消息中传给DRNC,指示UE转入普通的CELL—PCH或URA—PCH状态。步骤1505、DRNC解析出DownlinkSignallingTransferRequest消息中的L3消息，并通过映射到S-CCPCH上的FACH信道传送给UE。UE接收到响应消息后，转入普通的CELL—PCH或URA—PCH状态。步骤1506、当SRNC决定在DRNC下属的小区中寻呼该UE时，将在RNSAPPagingRequest消息中指出将PCH映射到S-CCPCH上进行寻呼。对于PagingRequest消息的扩展，也与前述方法相同。步骤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时，将在RNSAPPagingR叫uest消息中指出将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发送CellUpdate消息，要求小区重定向，并在S-CCPCH上接收响应消息；步骤1703、DRNC接收到L3消息CellUpdate后，由其携带的U-RNTI标志判断出该UE属于其它RNC，因此，DRNC将构造RNSAP消息UplinkSignallingTransferIndication;步骤1704、SRNC接收到UplinkSignallingTransferIndication消息，从中解析出L3消息并进行相应处理，以CellUpdate为例，将构造响应消息CellUpdateConfirm,并将该响应消息包含在RNSAP消息DownlinkSignallingTransferR叫uest消息中传给DRNC，并指示UE转入普通的CELL_PCH或URA—PCH状态；步骤1705、DRNC解析出DownlinkSignallingTransferRequest消息中的L3消息，并通过映射到S-CCPCH上的FACH信道传送给UE。UE接收到响应消息后，转入普通的CELL—PCH或URA—PCH状态；步骤1706、当SRNC决定在相邻RNC中的小区寻呼UE时，通过RNSAP消息PagingRequest消息通知DRNC进行寻呼，并指示DRNC将PCH映射到S-CCPCH上实现。具体的实现可以不携带新增加的PagingChannelMappedTypeIE,即保持原有默认在S-CCPCH上寻呼的方式；也可以在PagingChannelMappedTypeIE中指明将PCH映射到S-CCPCH上实现。步骤1707、DRNC根据SRNC的指示，将PCH映射到S-CCPCH上实现寻呼。实施例三图18为实现向用户设备发送数据的系统，包括用户设备，还包括能力上报单元，用于将用户设备所属基站及其下属小区的小区能力集上报到所述RNC;RNC，用于接收并分析所述小区能力集，如果用户设备所属基站及其下属小区支持处于CELL_PCH状态或URA—PCH状态时，在高速物理下行共享信道上传输数据的功能，则与基站建立公共传输信道；当所述用户设备进入CELL—PCH或URA一PCH状态时，通过所述公共传输信道，将数据发送给基站；基站，用于将所述数据通过高速物理下行共享信道传输给所述用户设备。所述能力上报单元设置在所述基站。所述RNC具体包括信道创建模块，用于为RNC与基站间的数据传输创建公共传输信道；数据传输单元，用于通过所述公共传输信道，将数据发送给所述基站。所述能力上报单元进一步用于将基站对正交幅度调制的支持信息上报给RNC,则RNC采用基站支持的正交幅度调制方式向基站发送数据。总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。权利要求1、一种实现向用户设备发送数据的方法，其特征在于，包括将小区能力集上报到无线网络控制器RNC；所述RNC分析所述小区能力集，如果获知用户设备所属基站及其下属小区支持处于小区寻呼信道CELL_PCH状态或用户注册区寻呼信道URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则当所述用户设备进入CELL_PCH或URA_PCH状态，RNC将用户设备所需数据发送给基站；所述基站在高速物理下行共享信道上将所述数据传输给所述用户设备。2、根据权利要求1所述的实现向用户设备发送数据的方法，其特征在于，所述RNC分析所述小区能力集进一步包括RNC分析所述小区能力集，如果获知用户设备所属基站及其下属小区支持处于小区寻呼信道CELL—PCH状态或用户注册区寻呼信道URA—PCH状态时，在高速物理下行共享信道上传输数据的功能，则与基站建立公共传输信道；并通过所述公共传输信道将用户设备所需数据发送给基站。3、根据权利要求1所述的实现向用户设备发送数据的方法，其特征在于，在上报小区能力集的过程中，还进一步包括将基站在高速下行分組接入HSDPA中是否支持采用64正交幅度调制和/或在高速上行分组接入HSUPA中是否支持采用16正交幅度调制的信息上报给RNC,则所述RNC向基站发送数据时，采用基站支持的正交幅度调制方式。4、根据权利要求3所述的实现向用户设备发送数据的方法，其特征在于，所述将小区能力集和对正交幅度调制的支持上报到RNC具体包括在基站在重启或者RNC请求获得所述基站的资源状态时，该基站通过审计过程将所述小区能力集和对正交幅度调制的支持上报给RNC。5、根据权利要求4所述的实现向用户设备发送数据的方法，其特征在于，所述审计过程具体包括所述RNC向基站发送审计请求消息，要求上报基站的小区能力集；基站通过审计响应消息，将基站和/或其下属各个小区，和/或本地小区，和/或本地小区组的小区能力集，和对正交幅度调制的支持上报RNC。6、根据权利要求5所述的实现向用户设备发送数据的方法，其特征在于，在所述发送审计请求消息之前进一步包括基站向RNC发送基站审计要求消息，要求发起所述审计过程。7、根据权利要求5或6所述的实现向用户设备发送数据的方法，其特征在于，该方法进一步包括在所述审计响应消息中增加信息元素；则所述发送审计响应消息具体包括，将指示该基站和/或其下属的各个小区，和/或本地小区，和/或本地小区组是否支持处于CELL_PCH或URA_PCH状态的用户设备在高速物理下行共享信道上接收数据的信息，以及对正交幅度调制的支持信息，携带在审计响应消息中增加的信息元素上发送给RNC。8、根据权利要求7所述的实现向用户设备发送数据的方法，其特征在于，RNC接收到所述审计响应消息后进一步包括解析基站和/或其每个小区，和/或本地小区，和/或本地小区组是否支持处于CELL_PCH或URA_PCH状态的用户设备在高速物理下行共享信道上接收数据，如果是，则将该基站和/或其小区，和/或本地小区，和/或本地小区组的能力集设置为可用；否则，将该基站和/或其小区，和/或本地小区，和/或本地小区组的能力集设置为不可用。9、根据权利要求3所述的实现向用户设备发送数据的方法，其特征在于，所述将小区能力集和/或对正交幅度调制的支持上报到RNC具体包括基站通过向RNC发送资源状态指示消息，将所述基站和/或其下属小区，和/或本地小区，和/或本地小区组的能力集，以及对正交幅度调制的支持，上报给RNC。10、根据权利要求9所述的实现向用户设备发送数据的方法，其特征在于，该方法进一步包括在所述资源状态指示消息中增加信息元素；则所述发送资源状态指示消息具体包括将基站和/或其下属的各个小区，和/或本地小区,和/或本地小区组是否支持处于CELL一PCH或URA—PCH状态的用户设备在高速物理下行共享信道上接收数据的信息，以及对正交幅度调制的支持信息，携带在所述资源状态指示消息增加的信息元素中，发送给RNC。11、根据权利要求10所述的实现向用户设备发送数据的方法，其特征在于，RNC接收到所述资源状态指示消息后进一步包括解析该基站和/或该基站下属的每个小区，和/或本地小区，和/或本地小区组是否支持处于CELL—PCH或URA一PCH状态的用户设备在高速物理下行共享信道上接收数据，如果是，则将该基站和/或其下属小区，和/或本地小区，和/或本地小区组的能力集设置为可用；否则，将该基站和/或其下属小区，和/或本地小区，和/或本地小区组能力集设置为不可用。12、根据权利要求2、3或4所述的实现向用户设备发送数据的方法，其特征在于，所述建立公共传输信道的方法包括当RNC获知下属小区中有处于CELL—PCH或URA一PCH状态的用户设备，需要在高速物理下行共享信道上接收数据时，则为每一个所述用户设备建立所述公共传输信道的传输承栽。13、根据权利要求12所述的实现向用户设备发送数据的方法，其特征在于,所述建立传输承栽具体包括RNC向基站发送公共传输信道建立请求消息；基站做好传输承栽的建立准备后，通过公共传输信道建立响应消息向所迷RNC返回响应；RNC在自身与基站之间为每个所述用户设备建立高速物理下行共享信道的传输承载。14、根据权利要求12所述的实现向用户设备发送数据的方法，其特征在于，该方法进一步包括在所述公共传输信道建立请求消息中增加信息元素；则所迷向基站发送公共传输信道建立请求消息具体包括将公共传输信道标识、传输承栽的绑定标识、传输承载地址及传输网络层的服务质量字段，及用户设备或该用户设备组对应的高速下行共享信道无线网络临时标识，通过所述公共传输信道建立请求消息发送给基站。15、根据权利要求14所述的实现向用户设备发送数据的方法，其特征在于，该方法进一步包括在所迷公共传输信道重配置请求消息中增加高速物理下行共享信道信息字段；则所述发送公共传输信道重配置请求消息具体包括将所述要重配置的公共传输信道的标识，和/或传输网络层服务质量，和/或需重新分配的高速下行共享信道无线网络临时标识，通过所述公共传输信道重配置请求消息发送给基站。16、根据权利要求14所述的实现向用户设备发送数据的方法，其特征在于，所述建立的传输承栽为每一个映射到高速物理下行共享信道的寻呼对应的传输承载，或多个映射到高速物理下行共享信道的寻呼公用的传输承载。17、根据权利要求1或2所述的实现向用户设备发送数据的方法，其特征在于，当所述用户设备漫游到服务无线网络控制器SRNC下属的其它小区时，该方法进一步包括当处于CELL—PCH或URA_PCH状态，在高速物理下行共享信道上接收数据的用户设备漫游到SRNC下属的一个新小区，通过广播信道上广播的系统信息得知该新小区支持在CELL_PCH或URA_PCH状态下，在高速物理下行共享信道上传输数据的功能；用户设备通过小区前向接入信道向SRNC发送小区更新消息，要求小区重定向，并在高速物理下行共享信道上接收响应消息；如果该新小区中还没有为所述映射到高速物理下行共享信道的寻呼数据传输建立相应的传输承栽，则通过公共传输信道建立过程，建立相应的传输承载；SRNC通过所述高速物理下行共享信道将小区更新确认消息发送给用户设备。18、根据权利要求1或2所述的实现向用户设备发送数据的方法，其特征在于，当所述用户设备漫游到SRNC下属的其它小区时，该方法进一步包括当处于CELL—PCH或URA-PCH状态，在高速物理下行共享信道上接收数据的用户设备，漫游到SRNC下属的一个新小区，通过广播信道上广播的系统信息得知该新小区不支持在CELL—PCH或URA—PCH状态下，在高速物理下行共享信道上传输数据的功能；用户设备通过小区前向接入信道向SRNC发送小区更新消息，要求小区重定向，并在辅公共控制物理信道上接收响应消息。19、根据权利要求1或2所述的实现向用户设备发送数据的方法，其特征在于，当所述用户设备漫游到SRNC下属的其它小区时，该方法进一步包括当处于CELL—PCH或URA—PCH状态，在高速物理下行共享信道上接收数椐的用户设备漫游到SRNC下属的一个新小区，通过广播信道上广播的系统信息得知该小区是否支持在CELL—PCH或URA_PCH状态下，在高速物理下行共享信道上传输数据的功能；用户设备通过小区前向接入信道向SRNC发送小区更新消息，要求小区重定向，并在辅公共控制物理信道上接收响应消息。20、根据权利要求2所述的实现向用户设备发送数据的方法，其特征在于，当所述用户设备漫游到漂移无线网络控制器DRNC下属的小区时，该方法进一步包括当处于CELL—PCH或URA_PCH状态，在高速物理下行共享信道上接收数据的用户设备漫游到DRNC下属的小区，通过广播信道上广播的系统信息得知该小区支持在CELL—PCH或URA—PCH状态下，在高速物理下行共享信道上传输数据的功能；用户设备通过小区前向接入信道向所述DRNC发送小区更新消息，要求小区重定向，并在高速物理下行共享信道上接收响应消息及寻呼数据。21、根据权利要求l或20所述的实现向用户设备发送数据的方法，其特征在于，当SRNC需要在DRNC下属的小区中寻呼处于CELL—PCH或URA一PCH状态，且在高速物理下行共享信道上接收寻呼消息的用户设备时，还进一步包括向所述DRNC发送寻呼请求消息，并在消息中设置通过高速物理下行共享信道进行寻呼；DRNC通过高速物理下行共享信道寻呼所述用户设备。22、根据权利要求2所述的实现向用户设备发送数据的方法，其特征在于，当所迷用户设备漫游到DRNC下属的小区时，该方法进一步包括当处于CELL_PCH或URA_PCH状态，在高速物理下行共享信道上接收数据的用户设备漫游到DRNC下属的小区，通过广播信道上广播的系统信息得知该小区不支持在CELL_PCH或URA_PCH状态下，在高速物理下行共享信道上传输数据的功能；用户设备通过小区前向接入信道向所述DRNC发送小区更新消息，要求小区重定向，并在辅公共控制物理信道上接收响应消息及寻呼数据。23、根据权利要求1或22所述的实现向用户设备发送数据的方法，其特征在于，当SRNC需要在DRNC下属的小区中寻呼处于CELL—PCH或URA一PCH状态的用户设备时，还进一步包括向所述DRNC发送寻呼请求消息，并在消息中设置通过辅公共控制物理信道进行寻呼；DRNC通过辅公共控制物理信道寻呼所述用户设备。24、根据权利要求1或2所述的实现向用户设备发送数据的方法，其特征在于，当所述用户设备漫游到DRNC下属的小区时，该方法进一步包括当处于CELL—PCH或URA—PCH状态，在高速物理下行共享信道上接收数据的用户设备漫游到DRNC下属的小区，通过广播信道上广播的系统信息得知该小区是否支持在CELL—PCH或URA一PCH状态下，在高速物理下行共享信道上传输数据的功能；用户设备通过小区前向接入信道向所述DRNC发送小区更新消息，要求小区重定向，并在辅公共控制物理信道上接收响应消息及寻呼数据。25、根据权利要求1或2所述的实现向用户设备发送数据的方法，其特征在于，当所述用户设备漫游到DRNC下属的小区时，该方法进一步包括当SRNC不知道所述DRNC下属的小区是否支持处于CELL—PCH或URA_PCH状态，在高速物理下行共享信道上接收数据的功能时，在所述DRNC下属的小区中寻呼处于CELL—PCH或URA_PCH用户设备，则向所述DRNC发送寻呼请求消息，并在消息中设置通过高速物理下行共享信道和/或辅公共控制物理信道同时进行寻呼；所述DRNC通过高速物理下行共享信道和/或辅公共控制物理信道寻呼所述用户设备。26、一种实现向用户设备发送数据的系统，包括用户设备，其特征在于，该系统还包4舌能力上报单元，用于将用户设备所属基站及其下属小区的小区能力集上报到所述RNC;RNC,用于接收并分析所述小区能力集，如果用户设备所属基站及其下属小区支持处于CELL-PCH状态或URA一PCH状态时，在高速物理下行共享信道上传输数据的功能，则与基站建立公共传输信道；当所述用户设备进入CELL一PCH或URA_PCH状态时，通过所述公共传输信道，将数据发送给基站；基站，用于将所述数据通过高速物理下行共享信道传输给所述用户设27、根据权利要求26所述的实现向用户设备发送数据的系统，其特征在于，所述能力上报单元设置在所述基站。28、根据权利要求26或27所述的实现向用户设备发送数据的系统，其特征在于，所述能力上报单元进一步用于将基站对正交幅度调制的支持信息上报给RNC，则RNC采用基站支持的正交幅度调制方式向基站发送数据。29、一种无线网络控制器，其特征在于，包括能力处理单元，用于接收并分析用户设备所属基站及其下属小区的小区能力集，如果所述基站及其下属小区支持处于CELL—PCH状态或URA—PCH状态时，在高速物理下行共享信道上传输数据的功能，则发起公共传输信道的建立请求；信道创建模块，用于根据所述建立请求，为RNC与基站间的数据传输创建公共传输信道；数据传输单元，用于通过所述公共传输信道，将数据发送给所述基站。全文摘要本发明公开了一种实现向用户设备发送数据的方法，包括，将小区能力集上报到RNC；RNC分析所述小区能力集，如果获知用户设备所属基站及其下属小区支持处于CELL_PCH状态或URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则当所述用户设备进入CELL_PCH或URA_PCH状态，RNC将用户设备所需数据发送给基站；所述基站在高速物理下行共享信道上将所述数据传输给所述用户设备。本发明还公开了一种实现向用户设备发送数据的系统，包括能力上报单元、RNC和基站。本发明还公开了一种无线网络控制器。文档编号H04Q7/22GK101198092SQ200710079269公开日2008年6月11日申请日期2007年2月13日优先权日2007年2月13日发明者涛吴申请人:华为技术有限公司