CN101198092A - 实现向用户设备发送数据的方法、***及设备 - Google Patents
实现向用户设备发送数据的方法、***及设备 Download PDFInfo
- Publication number
- CN101198092A CN101198092A CNA2007100792693A CN200710079269A CN101198092A CN 101198092 A CN101198092 A CN 101198092A CN A2007100792693 A CNA2007100792693 A CN A2007100792693A CN 200710079269 A CN200710079269 A CN 200710079269A CN 101198092 A CN101198092 A CN 101198092A
- Authority
- CN
- China
- Prior art keywords
- cell
- pch
- channel
- base station
- user equipment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
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所示：
| 信息元素/信息元素级名称(IE/GroupName) | 存在性(Presence) | 范围(Range) | 信息元素类型和参考(IEType andReference) | 语义描述(SemanticsDescription) | 紧急程度(Criticality) | 应急处理方式(AssignedCriticality) |
| 消息描述(MessageDiscriminator) | 必选(M) | 9.2.1.45 | - | |||
| 无关IE | 忽略 | |||||
| HS-PCH能力集(HS-PCHCapability) | 可选(O) | 9.2.1.* | 是 | 忽略 | ||
| ＞HSDPA64QAM能力集 | O | 9.2.1.* | 在HSDPA中是否支持64QAM的指示 | YES | ignore | |
| ＞HSUPA16QAM能力集 | O | 9.2.1.* | 在HSUPA中是否支持16QAM的指示 | YES | ignore | |
| 小区信息(CellInformation) | NodeB最大小区个数＞0 | 每一个 | 忽略 | |||
| ＞小区ID(C-ID) | M | 9.2.1.9 | - | |||
| 无关IE | ||||||
| ＞HS-PCH能力集(HS-PCHCapability) | 可选(O) | 9.2.1.* | 是 | 忽略 | ||
| ＞HSDPA64QAM能力集 | O | 9.2.1.* | 在HSDPA中是否支持64QAM的指示 | YES | ignore | |
| ＞HSUPA16QAM能力集 | O | 9.2.1.* | 在HSUPA中是否支持16QAM的指示 | YES | ignore | |
| 本地小区信息(Local CellInformation) | NodeB最大小区个数＞0 | 每一个 | 忽略 | |||
| ＞本地小区ID(Local CellID) | M(必选) | 9.2.1.38 | ||||
| 无关IE | ||||||
| ＞HS-PCH能力集(HS-PCHCapability) | O | 9.2.1.* | 是 | 忽略 | ||
| ＞HSDPA64QAM能力集 | O | 9.2.1.* | 在HSDPA中是否支持64QAM的指示 | YES | ignore |
| ＞HSUPA16QAM能力集 | O | 9.2.1.* | 在HSUPA中是否支持16QAM的指示 | YES | ignore | |
| 本地小区组信息(Local CellGroupInformation) | NodeB最大小区个数＞0 | 每一个 | 忽略 | |||
| ＞本地小区组ID(Local CellGroup ID) | M(必选) | 9.2.1.37A | - | |||
| 无关IE | ||||||
| ＞HS-PCH能力集(HS-PCHCapability) | O | 9.2.1.* | 是 | 忽略 | ||
| ＞HSDPA64QAM能力集 | O | 9.2.1.* | 在HSDPA中是否支持64QAM的指示 | YES | ignore | |
| ＞HSUPA16QAM能力集 | O | 9.2.1.* | 在HSUPA中是否支持16QAM的指示 | YES | ignore |
表1
在该消息格式中，HS-PCH能力集、小区信息、本地小区信息及本地小区组信息为扩展内容，分别表示基站、小区、本地小区及本地小区组是否支持HS-PCH功能。在本发明的实施例一中，这四项扩展IE并非必须同时存在，可以在消息中只包含其中的一或多项。此外，在这四项扩展IE中，还增加了对于基站及其下属的小区、本地小区和本地小区组是否支持HSDPA上的64QAM和HSUPA上的16QAM的描述，当然，该描述在本发明的实施例中也为可选项，在Audit Response消息中可以包含也可不包含，或只包含关于HSUPA16QAM或HSDPA64QAM的描述。在表1中，信息元素类型和参考是指标准中的索引和章节。其中，对于HS-PCH能力集的表示方式有两种，分别如表2和表3所示：
| 信息元素/组名字 | 存在性) | 范围 | 信息元素类型和参考 | 语义描述 |
| HS-PCH能力集 | 枚举(支持) | 表明是否支持UE在CELL_PCH/URR_PCH状态下下行寻呼数据映射到HS-PDSCH上传输。 |
表2
| 信息元素/组名字 | 存在性 | 范围 | 信息元素类型和参考 | 语义描述 |
| HS-PCH能力集 | 枚举(支持、不支持) | 表明是否支持UE在CELL_PCH/URR_PCH状态下下行寻呼数据映射到HS-PDSCH上传输。 |
表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时，将发送资源状态指示(ResourceStatus Indication)消息给RNC。同样需要对现有的Resource Status Indication消息进行扩展，在消息中增加IE指示基站和/或该基站下属各个小区和/或本地小区和/或本地小区组是否支持HS-PCH功能。具体扩展如表4所示：
| 信息元素/信息元素级名称 | 存在性 | 信息元素类型和参考 | 紧急程度 | 应急处理方式 |
| 消息描述 | M | 9.2.1.45 | - | |
| 无关IE | ||||
| CHOICE指示类型 | M | 是(YES) | 忽略(ignore) | |
| ＞No Failure | - | |||
| ＞＞HS-PCH能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞＞HSDPA 64QAM能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞＞HSUPA 16QAM能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞小区信息 | 每一个(EACH) | Ignore | ||
| ＞＞＞小区ID | M | 9.2.1.38 | - | |
| 无关IE | ||||
| ＞＞＞HS-PCH能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞＞HSDPA 64QAM能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞＞HSUPA 16QAM能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞本地小区组信息 | EACH | ignore | ||
| ＞＞＞本地小区组ID | M | 9.2.1.37A | - | |
| ＞＞＞无关IE | ignore | |||
| ＞＞＞HS-PCH能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞＞HSDPA 64QAM能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞＞HSUPA 16QAM能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞本地小区组信息 | EACH | ignore | ||
| ＞＞＞本地小区组ID | M | 9.2.1.37A | - | |
| ＞＞＞无关IE | ||||
| ＞＞＞HS-PCH能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞＞HSDPA 64QAM能力集 | O | 9.2.1.* | YES | ignore |
| ＞＞＞HSUPA 16QAM能力集 | O | 9.2.1.* | YES | ignore |
| ＞Service Impacting | - |
表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 TransportChannel Setup Request)消息通知NodeB，消息中指出了建立用于传输CELL_PCH或URA_PCH状态UE的数据的HS-PDSCH信道的个数，每个信道相关的公共传输信道ID，采用的特定HS-PCH H-RNTI，用于建立传输承载的绑定ID，传输承载地址，传输网络层的QoS等参数。其中HS-PCHH-RNTI可以是由***中分配的公共H-RNTI，也可以是原来UE本身分配的RNTI。所述公共H-RNTI是指在一组HS-PDSCH上接收寻呼消息的HS-PCH状态UE分配的一个公共标识。
其中，需要对Common Transport Channel Setup Request消息进行扩展，扩展后的消息格式如表5所示：
| 信息元素/组名称 | 存在性 | 范围 | 信息元素类型和参考 | 语义描述 | 重要程度 | 应急处理方式 |
| 消息描述 | M | 9.2.1.45 | - | |||
| 消息类型 | M | 9.2.1.46 | YES | 拒绝(Reject) | ||
| 传输ID | M | 9.2.1.62 | - | |||
| 小区ID | M | 9.2.1.9 | YES | Reject | ||
| 配置构造ID | M | 9.2.1.16 | YES | reject | ||
| 公共物理信道配置 | M | YES | Ignore | |||
| ＞无关IE | ||||||
| ＞HS-PCH信息 | 0..<最大公共HS-PCH数目> | GLOBAL | Reject | |||
| ＞＞公共传输信道ID | M | 9.2.1.14 | - | |||
| ＞＞HS-PCH H-RNTI | M | 9.2.1.31J | 该RNTI可以是***分配公共的H-RNTI，也可以是UE特定的RNTI。 | |||
| ＞＞绑定ID | O | 9.2.1.4 | 如果使用接入连接控制应用协议(ALCAP)建立传输承载，该IE可被忽略 | YES | ignore | |
| ＞＞传输层地址 | O | 9.2.1.63 | 如果使用ALCAP建立传输承载，该IE可被忽略 | YES | ignore | |
| ＞＞传输网络层承载QoS | O | 9.2.1.58A | 如果使用ALCAP建立传输承载，该IE可被忽略 | YES | ignore |
表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所示：
| 信息元素/组名称 | 存在性 | 范围 | 信息元素类型和参考 | 语义描述 | 重要程度 | 应急处理方式 |
| 消息描述 | M | 9.2.1.45 | - | |||
| 消息类型 | M | 9.2.1.46 | YES | Reject | ||
| 传输ID | M | 9.2.1.62 | - | |||
| HS-PCH信息 | 0..<最大公共HS-PCH数目> | 指出各条HS-PCH相关传输承载的信息 | GLOBAL | ignore | ||
| ＞HS-PCH参数 | M | 公共传输信道信息响应 | - |
表6
其中，HS_PCH信息中的HS_PCH参数可以包括但不仅限于：
| 信息元素/组名称 | 存在性 | 范围 | 信息元素类型和参考 | 语义描述 |
| 公共传输信道ID | M | 9.2.1.14 | ||
| 绑定ID | O | 9.2.1.4 | ||
| 传输层地址 | O | 9.2.1.63 |
表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 DeletionRequest)消息中指明所需要删除的HS-PCH对应的公共传输信道ID，该ID是在信道建立过程中分配的，并将该消息通知NodeB；
2、NodeB做好删除准备后用公共传输信道删除响应(Common TransportChannel Deletion Response)消息响应RNC的要求；
3、RNC在接收到响应消息后，则释放该传输承载。
当有必要对建立的HS-PDSCH传输承载进行重配置时，例如要重新配置传输承载的QoS，则可以发起公共传输信道的重配置过程。该过程如图9所示，包括以下步骤：
1、RNC在公共传输信道重配置请求(Common Transport ChannelReconfiguration Request)消息中指明所需要重配置的HS-PCH对应的公共传输信道ID及相应的传输网络层服务质量(TNL QoS)，和可能重新分配的HS-PCH H-RNTI，并将该消息通知NodeB。
在该步骤中，需要修改现有协议中的Common Transport ChannelReconfiguration Request消息，在其中增加重配置的HS-PDSCH传输承载的QoS要求，修改后的消息格式如表8所示：
| 信息元素/组名称 | 存在性 | 范围 | 信息元素类型和参考 | 语义描述 | 重要程度 | 应急处理方式 |
| 消息描述 | M | 9.2.1.45 | - | |||
| 消息类型 | M | 9.2.1.46 | YES | Reject | ||
| 传输ID | M | 9.2.1.62 | - | |||
| 小区ID | M | 9.2.1.9 | YES | Reject | ||
| 配置构造ID | M | 9.2.1.16 | YES | reject | ||
| 公共物理信道配置 | M | YES | Ignore | |||
| ＞HS-DSCH信息 | 0..<最大公共HS-PCH> | GLOBAL | Reject | |||
| ＞＞公共传输信道ID | M | 9.2.1.14 | - | |||
| ＞＞HS-PCH H-RNTI | M | 9.2.1.31J | 该RNTI可以是***分配公共的H-RNTI，也可以是UE特定的RNTI。 | |||
| ＞＞传输网络层承载QoS | O | 9.2.1.58A | 如果使用ALCAP建立传输承载，该IE可被忽略 | YES | ignore | |
| 其它IE |
表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的对应关系。
| 信息元素/组名称 | 存在性 | 范围 | 信息元素类型和参考 | 语义描述 | 重要程度 | 应急处理方式 |
| 消息描述 | M | 9.2.1.45 | - | |||
| 消息类型 | M | 9.2.1.46 | YES | Reject | ||
| 传输ID | M | 9.2.1.62 | - | |||
| 小区ID | M | 9.2.1.9 | YES | Reject | ||
| 配置构造ID | M | 9.2.1.16 | YES | reject | ||
| 公共物理信道配置 | M | YES | Ignore | |||
| ＞无关IE | ||||||
| ＞HS-PCH信息 | 0..<最大公共HS-PCH> | GLOBAL | Reject | |||
| ＞＞公共传输信道ID | M | 9.2.1.14 | - | |||
| ＞＞绑定ID | O | 9.2.1.4 | 如果使用ALCAP建立传输承载，该IE可被忽略 | YES | ignore | |
| ＞＞传输层地址 | O | 9.2.1.63 | 如果使用ALCAP建立传输承载，该IE可被忽略 | YES | ignore | |
| ＞＞传输网络层承载QoS | O | 9.2.1.58A | 如果使用ALCAP建立传输承载，该IE可被忽略 | YES | ignore | |
| ＞＞HS-PCHH-RNTI组 | 0..<每组中最大H-RNTI的个数> | |||||
| ＞＞＞H-RNTI | M | 9.2.1.31J | 该RNTI可以是***分配公共的H-RNTI，也可以是UE特定的RNTI。 | |||
| ＞＞＞H-RNTI索引 | M | Integer(0.255) |
表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之间通过物理信道重配置(PhysicalChannel Reconfiguration)释放Uu口的FACH相关资源，并指示UE进入HS-PCH状态，及分配UE在该状态下的H-RNTI。
步骤505-步骤507、RNC和NodeB之间通过无线连接删除(Radio LinkDeletion)过程，释放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功能的情况，采用图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将相应的响应消息小区更新确认(CellUpdate 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 SignallingTransfer Indication)消息，在该消息中的小区能力容量(Cell CapabilityContainer FDD)IE中指示该DRNC中的小区是支持HS-PCH功能的，其中的L3信息IE中包含了接收到的Uu口消息。
本实施例需要对Uplink Signalling Transfer Indication消息进行扩展，在消息中增加UE所隶属的DRNC小区是否支持HS-PCH功能的指示，通过在Cell Capability Container FDD IE增加对DRNC中小区能力集的描述来实现该功能。扩展后的该消息如表10所示：
| 信息元素/信息元素组名称 | 存在性 | 范围 | 信息元素类型及参考 | 语义描述 | 重要程度 | 指定的出错处理方式 |
| 消息类型 | M | 9.2.1.40 | YES | Ignore | ||
| 无关IE | ||||||
| 小区能力容量(Cell Capability ContainerFDD) | O | 9.2.2.D | YES | Ignore | ||
| 无关IE |
表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所示：
| 信息元素/信息元素组名称 | 存在性 | 范围 | 信息元素类型及参考 | 语义描述 |
| Cell Capability ContainerFDD | BIT串(32) | 每个bit是否支持特定功能，该比特为1时表示支持，为0表示不支持。每bit含义如下：第1bit保留；第2bit表示是否支持时延激活；第3bit表示是否支持HS-DSCH；第4bit保留；第5bit表示是否支持F-DPCH；第6bit表示是否支持E-DCH；第7bit表示是否支持E-DCH TTI2ms；第8bit表示是否支持E-DCH2sf2and2sf4及其以下能力；第9bit表示是否支持E-DCH 2sf2及其以下能力；第10bit表示是否支持E-DCH 2sf4及其以下能力；第11bit表示是否支持E-DCH sf4及其以下能力；第12bit表示是否支持E-DCH sf8及其以下能力；第13bit表示是否支持E-DCH HARQ冗余合并；第14bit表示是否支持E-DCH HARQChase合并；第15bit指明是否支持PCH映射到HS-PDSCH上的CELL_PCH或URA_PCH状态，即前面所述的HS-FACH；第19bit指明是否支持HSDPA64QAM；第20bit指明是否支持HSUPA16QAM。 |
表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所示：
| 信息元素/信息元素组名称 | 存在性 | 范围 | 信息元素类型及参考 | 语义描述 | 重要程度 | 指定的出错处理方式 |
| 消息类型 | M | 9.2.1.40 | YES | Ignore | ||
| 无关IE | ||||||
| 寻呼信道映射类型(Paging Channel MappedType) | O | 9.2.1.* | YES | Ignore |
表12
在消息中增加了寻呼信道映射类型的IE，表示该寻呼是通过HS-PDSCH下发还是通过S-CCPCH下发，或者是同时通过HS-PDSCH和S-CCPCH下发，具体的指示方法如表13所示：
| 信息元素/信息元素组名称 | 存在性 | 范围 | 信息元素类型及参考 | 语义描述 |
| Paging Channel MappedType | 枚举(HS-PDSCH，S-CCPCH，HS-PDSCH与S-CCPCH) |
表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 ContainerFDD IE中指示该RNC中的小区是不支持HS-PCH功能的，其中的L3Information IE中包含了接收到的Uu口消息。对于Uplink Signalling TransferIndication的扩展与前述方法相同。
步骤1504、SRNC接收到Uplink Signalling Transfer Indication消息，从中解析出L3消息并进行相应处理，以Cell Update为例，SRNC判断该UE属于HS-PCH状态，且目前所在的小区不支持HS-PCH功能，因此构造响应消息Cell Update Confirm，并将其包含在RNSAP消息Downlink SignallingTransfer 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消息UplinkSignalling Transfer Indication；
步骤1704、SRNC接收到Uplink Signalling Transfer Indication消息，从中解析出L3消息并进行相应处理，以Cell Update为例，将构造响应消息Cell Update Confirm，并将该响应消息包含在RNSAP消息DownlinkSignalling 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 ChannelMapped 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 (29)
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.根据权利要求1或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.一种实现向用户设备发送数据的***，包括用户设备，其特征在于，该***还包括：
能力上报单元，用于将用户设备所属基站及其下属小区的小区能力集上报到所述RNC；
RNC，用于接收并分析所述小区能力集，如果用户设备所属基站及其下属小区支持处于CELL_PCH状态或URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则与基站建立公共传输信道；当所述用户设备进入CELL_PCH或URA_PCH状态时，通过所述公共传输信道，将数据发送给基站；
基站，用于将所述数据通过高速物理下行共享信道传输给所述用户设备。
27.根据权利要求26所述的实现向用户设备发送数据的***，其特征在于，所述能力上报单元设置在所述基站。
28.根据权利要求26或27所述的实现向用户设备发送数据的***，其特征在于，所述能力上报单元进一步用于：将基站对正交幅度调制的支持信息上报给RNC，则RNC采用基站支持的正交幅度调制方式向基站发送数据。
29.一种无线网络控制器，其特征在于，包括：
能力处理单元，用于接收并分析用户设备所属基站及其下属小区的小区能力集，如果所述基站及其下属小区支持处于CELL_PCH状态或URA_PCH状态时，在高速物理下行共享信道上传输数据的功能，则发起公共传输信道的建立请求；
信道创建模块，用于根据所述建立请求，为RNC与基站间的数据传输创建公共传输信道；
数据传输单元，用于通过所述公共传输信道，将数据发送给所述基站。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2007100792693A CN101198092B (zh) | 2007-02-13 | 2007-02-13 | 实现向用户设备发送数据的方法、***及设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2007100792693A CN101198092B (zh) | 2007-02-13 | 2007-02-13 | 实现向用户设备发送数据的方法、***及设备 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201110300234.4A Division CN102413578B (zh) | 2007-02-13 | 2007-02-13 | 实现向用户设备发送数据的方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101198092A true CN101198092A (zh) | 2008-06-11 |
| CN101198092B CN101198092B (zh) | 2011-11-16 |
Family
ID=39548179
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2007100792693A Active CN101198092B (zh) | 2007-02-13 | 2007-02-13 | 实现向用户设备发送数据的方法、***及设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101198092B (zh) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010028605A1 (zh) * | 2008-09-11 | 2010-03-18 | 大唐移动通信设备有限公司 | 寻呼状态下数据传输的方法、***及装置 |
| CN101801061A (zh) * | 2010-02-11 | 2010-08-11 | 华为技术有限公司 | 一种信用度消耗法则上报方法、准入控制方法及装置 |
| CN102143592A (zh) * | 2011-03-09 | 2011-08-03 | 中兴通讯股份有限公司 | 一种缩短fach数据发送时延的方法、rnc及*** |
| CN102448025A (zh) * | 2010-09-30 | 2012-05-09 | 华为技术有限公司 | 寻呼Cell_PCH状态的用户终端的方法及装置 |
| CN106464448A (zh) * | 2014-07-01 | 2017-02-22 | 华为技术有限公司 | 一种通信方法、装置、用户设备及通信*** |
| WO2017147779A1 (zh) * | 2016-03-01 | 2017-09-08 | 华为技术有限公司 | 一种数据传输方法、设备及*** |
| CN107889216A (zh) * | 2016-09-30 | 2018-04-06 | 中兴通讯股份有限公司 | 数据发送、接收方法及装置、基站、终端 |
| CN108124245A (zh) * | 2016-11-25 | 2018-06-05 | 北京小米移动软件有限公司 | 寻呼信令消息的处理方法、生成方法及装置 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2382273B (en) * | 2001-11-20 | 2003-11-26 | Ericsson Telefon Ab L M | Abnormal release recovery in a UTRAN of a UMTS network |
| CN100499914C (zh) * | 2005-03-24 | 2009-06-10 | 华为技术有限公司 | 一种获知用户终端设备是否能支持异频硬切换的方法 |
| CN100566438C (zh) * | 2006-07-31 | 2009-12-02 | 华为技术有限公司 | 一种小区能力衡量方法、***及无线网络控制器 |
-
2007
- 2007-02-13 CN CN2007100792693A patent/CN101198092B/zh active Active
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010028605A1 (zh) * | 2008-09-11 | 2010-03-18 | 大唐移动通信设备有限公司 | 寻呼状态下数据传输的方法、***及装置 |
| KR101233304B1 (ko) | 2008-09-11 | 2013-02-14 | 다 탕 모바일 커뮤니케이션즈 이큅먼트 코포레이션 리미티드 | 호출 상태하의 데이터 전송 방법, 시스템 및 장치 |
| CN101801061A (zh) * | 2010-02-11 | 2010-08-11 | 华为技术有限公司 | 一种信用度消耗法则上报方法、准入控制方法及装置 |
| CN104955100A (zh) * | 2010-09-30 | 2015-09-30 | 华为技术有限公司 | 寻呼Cell_PCH状态的用户终端的方法及装置 |
| CN102448025A (zh) * | 2010-09-30 | 2012-05-09 | 华为技术有限公司 | 寻呼Cell_PCH状态的用户终端的方法及装置 |
| CN102143592B (zh) * | 2011-03-09 | 2015-12-16 | 中兴通讯股份有限公司 | 一种缩短fach数据发送时延的方法、rnc及*** |
| CN102143592A (zh) * | 2011-03-09 | 2011-08-03 | 中兴通讯股份有限公司 | 一种缩短fach数据发送时延的方法、rnc及*** |
| CN106464448A (zh) * | 2014-07-01 | 2017-02-22 | 华为技术有限公司 | 一种通信方法、装置、用户设备及通信*** |
| US10349390B2 (en) | 2014-07-01 | 2019-07-09 | Huawei Technologies Co., Ltd. | Communication method, communications apparatus, user equipment, and communications system |
| CN106464448B (zh) * | 2014-07-01 | 2019-11-19 | 华为技术有限公司 | 一种通信方法、装置、用户设备及通信*** |
| WO2017147779A1 (zh) * | 2016-03-01 | 2017-09-08 | 华为技术有限公司 | 一种数据传输方法、设备及*** |
| CN107889216A (zh) * | 2016-09-30 | 2018-04-06 | 中兴通讯股份有限公司 | 数据发送、接收方法及装置、基站、终端 |
| CN107889216B (zh) * | 2016-09-30 | 2022-04-29 | 中兴通讯股份有限公司 | 数据发送、接收方法及装置、基站、终端 |
| CN108124245A (zh) * | 2016-11-25 | 2018-06-05 | 北京小米移动软件有限公司 | 寻呼信令消息的处理方法、生成方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101198092B (zh) | 2011-11-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2456273B1 (en) | Method, system and device for distributing resources of base station node | |
| KR100438029B1 (ko) | 식별자 할당 방법 | |
| RU2392774C2 (ru) | Улучшенная обработка ошибок управления радиоканалом | |
| EP1969737B1 (en) | Method for reading dynamic system information blocks | |
| RU2414097C2 (ru) | Индивидуальные и групповые идентификаторы для абонентского оборудования в беспроводных системах с совместно используемым транспортным каналом | |
| JP4753995B2 (ja) | １対多サービスに対する制御情報メッセージ処理方法 | |
| CN112995958B (zh) | 一种数据调度方法、基站及*** | |
| RU2414065C1 (ru) | Способ создания формата данных в мобильной связи и терминал для его осуществления | |
| CN101198092A (zh) | 实现向用户设备发送数据的方法、***及设备 | |
| EP2109998A2 (en) | Fast state transition for a ue with reconfiguration over paging | |
| US8442565B2 (en) | Method, device and system for indicating discontinuous data scheduling | |
| MX2007001769A (es) | Configuraciones por defecto con codificacion diferencial en un sistema de comunicaciones inalambricas. | |
| MX2008001465A (es) | Metodo para transmitir y recibir servicio de difusion/ multidifusion de multimedia en un sistema de comunicacion movil. | |
| KR20080097150A (ko) | 이동 통신 시스템에서의 데이터 블록 생성 방법 | |
| CN100547951C (zh) | Td-scdma***中的物理信道配置和信令传输方法 | |
| CN101242218A (zh) | 实现向用户设备发送数据的方法及*** | |
| CN101601218B (zh) | 用于在高速传输中使用的帧协议和信令 | |
| CN101394607A (zh) | 一种通知用户设备的上下文信息的方法 | |
| CN101742658B (zh) | 多载波***中增强小区前向接入信道的资源配置方法 | |
| US20110128932A1 (en) | Radio resource scheduling method, apparatus, and system | |
| CN100426697C (zh) | 多载频小区中下行链路功率控制方法 | |
| CN101860924B (zh) | 一种确定能力等级的方法和终端 | |
| CN101489287A (zh) | Cell_pch状态下具有专用h-rnti的hs-scch选择方法及*** | |
| CN104620656A (zh) | 便于在移动通信网络中使用多个发送时间间隔的方法和装置 | |
| US20020191591A1 (en) | Transmission of connection setup parameters in packet data network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20080611 Assignee: Apple Computer, Inc. Assignor: Huawei Technologies Co., Ltd. Contract record no.: 2015990000755 Denomination of invention: Method, system and device for transmitting data to user's set Granted publication date: 20111116 License type: Common License Record date: 20150827 |
|
| LICC | Enforcement, change and cancellation of record of contracts on the licence for exploitation of a patent or utility model |