一种连接管理的方法及装置 |
|||||||
| 申请号 | CN201110394778.1 | 申请日 | 2007-11-07 | 公开(公告)号 | CN102421160B | 公开(公告)日 | 2014-08-20 |
| 申请人 | 华为技术有限公司; | 发明人 | 陈燕燕; | ||||
| 摘要 | 本 发明 公开了一种确定寻呼传输信道的方法，包括以下步骤：控制无线网络 控制器 RNC获取移动台的能 力 信息；所述控制RNC根据所述移动台的能力信息以及寻呼域的能力信息确定发送寻呼消息的信道。本发明 实施例 还提供了一种触发服务无线网络子系统重 定位 的方法。本发明实施例中控制RNC可以通过获知移动台是否支持增强寻呼的能力，以确定移动台收到寻呼指示后会去SCCPCH还是HS-PDSCH信道上监听寻呼消息，避免寻呼损失。 | ||||||
| 权利要求 | 1.一种连接管理的方法，其特征在于，包括： |
||||||
| 说明书全文 | 一种连接管理的方法及装置技术领域[0001] 本发明涉及通信技术领域，尤其涉及一种确定寻呼传输信道的方法及系统。 背景技术[0002] 现有技术中，处于URA_PCH(UTRAN Registration Area Paging Channel，UTRAN注册区寻呼信道)状态下的移动台不能直接的进行数据发送和接收。当网络侧有数据或者呼叫要下发给URA_PCH状态的移动台时，需要在网络侧的PCH(Paging Channel，寻呼信道)发送寻呼消息来通知移动台，移动台收到寻呼消息后，状态迁移进入到其他状态进行数据发送和接收。出于节电目的，处于URA_PCH状态下的移动台执行不连续接收(Discontinuous Reception，DRX)，移动台按照与网络侧协商好的不连续接收周期和算法，来计算何时应该去接收属于自己的寻呼消息，具体方法如下： [0003] 每个寻呼信道(PCH)都有一个寻呼指示信道(Page Indicator Channel，PICH)与之配对使用，移动台只在一定的寻呼时机(paging occasion)去不连续的监听PICH上的PI(Paging Indication，寻呼指示)信息。寻呼时机的计算： [0004] Paging Occasion＝{(IMSI div K)mod(DRX cycle length div PBP)}*PBP+n*DRX cycle length+Frame Offset； (1) [0005] PI＝DRX Index mod Np； [0006] where DRX Index＝IMSI div8192 [0007] 其中：IMSI(International Mobile Subscriber Identity国际移动用户标识)用于标识国际移动用户；K为可用的承载PCH的SCCPCH(Secondary Common Control Physical Channel，辅助公共控制物理信道)的个数；DRX cycle length为不连续接收周期；PBP为寻呼块周期，对于FDD(Frequency Division Duplex，频分复用)，PBP＝1；Frame Offset为帧偏移，对于FDD，帧偏移为0，对于TDD(Time Division Duplex，时分复用)，帧偏移值在系统消息中指定；NPICH为承载寻呼指示帧的帧数，等于寻呼指示帧的重复长度；NGAP是某个寻呼时机的最后一个承载寻呼指示的帧与第一个承载寻呼消息的帧之间的帧数；DRXIndex为不连续接收指数，其值为(IMSI div8192)；对于FDD，Np是一个帧中的寻呼指示的数目，对于TDD，Np是一个寻呼块中的寻呼指示的数目；NPCH为寻呼组的个数。其中，NPICH，Np，NPCH都在系统消息中下发。 [0008] 通过以上公式，移动台可以计算出自己需要监控的寻呼指示帧的SFN(System Frame Number，系统帧号)以及需要监控的PI。如果在寻呼时机中监控到属于自己的寻呼指示的信息为“后续有寻呼消息”，对于FDD，在指定tPICH＝7680chips后，到承载寻呼消息的SCCPCH上接收寻呼消息(PCH是传输信道，其映射到物理信道为SCCPCH)。现有技术WCDMA中PICH与SCCPCH的时隙关系如图1所示。 [0009] 在WCDMA(Wideband Code Division Multiple Access，宽带码分多址)中的PICH帧结构如图2所示，包括用于寻呼指示的288比特和预留的12比特。WCDMA的Release7版本中，引入了增强寻呼特性，对于支持增强寻呼特性的Cell_PCH状态下或URA_PCH状态下的移动台，可以利用HSDPA(High Speed Downlink Package Access，高速下行链路分组接入)技术实现传输比特率的增加，即从HS-PDSCH(High-Speed Physical Downlink Shared Channel，高速物理下行共享信道)接收寻呼消息，PICH与HS-PDSCH的时隙关系如图3所示。其具体的实现方式如下： [0010] 对于URA_PCH状态下的移动台，如果移动台支持增强寻呼特性，并且当移动台进入到一个支持增强寻呼特性的小区中时，移动台会按照现有的方式监听寻呼指示信道上的寻呼指示。与非增强寻呼的区别在于，增强寻呼用于计算寻呼时机的公式中的K是从系统广播消息中获得的小区中支持HSDPA的PICH的数目，并且移动台监控的PICH的信道是通过读取系统广播消息中的相关信息以及移动台的U-RNTI(User Radio Network Temporary Identity，用户无线网络临时标识)来进行计算并进行选择的： [0011] 移动台所选择监听的寻呼指示信道的编号＝U-RNTI mod K [0012] 公式中的K值为支持HSDPA的候选寻呼指示信道的条数。 [0013] 当URA_PCH状态的移动台监听寻呼指示信道并检测到属于自己的寻呼指示的信息为“后续有寻呼消息”，则在指定的时间间隔后，到承载寻呼消息内容的HS-PDSCH(High-Speed Physical Downlink Shared Channel，高速物理下行共享信道)上接收寻呼消息内容。 [0014] 现有技术中一种通信系统如图4所示，包括： [0015] SRNC(Serving RNC，服务RNC)是指移动台与网络之间的RRC(Radio Resource Control，无限资源控制)协议的终结点，移动台的RRC上下文都存储于服务RNC中，并且SRNC是移动台与核心网进行通信的唯一的接口。 [0016] CRNC(Controlling RNC，控制RNC)，是指移动台由于移动等原因，进入了属于这个RNC的小区中，移动台使用了这个RNC范围内的资源，但是移动台与核心网进行通信时仍需要通过SRNC。 [0017] 移动台的服务RNC和控制RNC可能是同一个RNC，也可以是不同的RNC。当移动台的服务RNC与控制RNC不一致时，服务RNC可以决定发起SRNS Relocation的过程(即服务无线网络系统重定位过程)，将移动台的RRC上下文从服务RNC转移到控制RNC，从而使得之前的控制RNC成为其服务RNC。 [0018] 考虑下面的场景：图4所示的一个通信系统中，移动台处于URA_PCH状态。移动台在无线网络控制器A范围内的小区中建立RRC连接，即无线网络控制器A是移动台的服务RNC。但是之后由于移动台的移动等原因，移动台驻留在了无线网络控制器B之下的小区D中，即无线网络控制器B成为移动台的控制RNC。 [0019] 图4中无线网络控制器C范围内的小区E与无线网络控制器C之下的小区D属于相同的URA，也即当移动台由于移动等原因执行小区重选从小区D重选到小区E时，虽然当前无线网络控制器C成为了移动台的控制RNC，但移动台并不会发起URA更新过程通知网络侧。 [0020] 当服务RNC收到来自核心网的对于这个URA_PCH状态移动台的数据或者呼叫时，由于服务RNC中会存储这个移动台的RRC上下文，因此可以知道这个移动台的RRC状态以及所在的URA标识信息，于是在属于这个URA的小区中发送寻呼消息，具体实现过程如图5所示，包括以下步骤： [0021] 步骤s501，服务RNC向其他的至少包含一个该URA小区的RNC发送寻呼请求消息，该寻呼请求消息中携带：paging area(寻呼域)，即URA标识信息、被呼移动台的IMSI，以及这个移动台的DRX周期参数等信息。其中，寻呼域是指需要发送寻呼的范围，可以是一个URA标识，也可以是一个小区的标识，当控制RNC得到寻呼域时，即知道了需要在哪些小区的范围内发送这个寻呼消息。 [0022] 步骤s502，收到寻呼请求消息的RNC(在图4的通信系统中，RNC B和RNC C都会收到这个寻呼请求消息)，根据被呼移动台的IMSI和DRX周期参数计算移动台的寻呼时机，并将寻呼消息的内容以及PI指示的信息放在PCH数据帧中通过Iub接口发送给基站。 [0023] 步骤s503，基站收到PCH数据帧，则根据PCH数据帧中的内容，在寻呼指示信道的相应位置发送寻呼指示信息，在SCCPCH信道发送寻呼消息的内容。 [0024] 步骤s504，移动台根据自己的IMSI，DRX参数等信息计算出监听寻呼指示的时机，并根据寻呼指示的信息判断是否需要到SCCPCH信道接收寻呼消息内容。 [0025] 在引入增强寻呼特性后，上述的步骤s502中，收到寻呼请求的RNC也可能会将寻呼消息的内容以及PI指示的信息放在HS-DSCH数据帧中通过Iub接口发送给基站。 [0026] 步骤s503，基站收到HS-DSCH数据帧，则根据HS-DSCH数据帧中的内容，在寻呼指示信道的相应位置发送寻呼指示信息，在HS-PDSCH信道发送寻呼消息的内容。 [0027] 移动台根据自己的能力信息以及当前小区的系统广播消息中表达的小区能力信息决定在SCCPCH信道上接收寻呼消息还是在HS-PDSCH信道上接收寻呼消息。 [0028] 综上所述，在实现本发明的过程中，发明人发现现有技术中至少存在如下问题：根据现有协议的描述，如果移动台支持增强寻呼的功能，并且系统广播消息中的相关信息表明移动台当前所驻留的小区也是支持增强寻呼功能时，移动台在监听到寻呼指示信道上的寻呼指示，接下来会去HS-PDSCH信道上接听寻呼消息的内容。然而，移动台接收到的驻留小区中的系统广播消息是来自于CRNC的配置，即当前小区支持增强寻呼只能表明CRNC是支持增强寻呼特性的，并不能表明SRNC是否支持增强寻呼特性。 [0029] 虽然CRNC可以从移动台在小区更新或者URA更新消息中携带信息获得移动台是否支持增强寻呼的能力信息，然后根据移动台的能力信息来判断将寻呼消息发送在SCCPCH信道或者HS-PDSCH信道。然而，如果移动台从来没有在当前CRNC的范围内发起过上行接入时，即移动台小区重选到不同的RNS(Radio Network Subsystem，无线网络子系统)范围，但是仍属于相同的URA的小区，因此无须发起URA更新的过程。因此CRNC如果仅仅根据该小区是否支持增强寻呼的能力信息来选择寻呼信道，移动台可能收不到寻呼消息，存在呼损的可能性。 [0030] 比如在图4中，当移动台从小区D重选到小区E的范围，由于小区D和小区E属于相同的URA，因此当网络侧需要对移动台发起寻呼时，移动台还没有在无线网络控制器C的范围内发起过上行信令接入，于是无线网络控制器C无法得知移动台的能力信息，也就无法知道移动台收到寻呼指示后会去SCCPCH还是HS-PDSCH信道上监听寻呼消息，于是存在呼损的可能性。 发明内容[0031] 本发明实施例提供一种确定寻呼传输信道的方法及系统，以解决现有技术中无法得知移动台的能力信息，也无法得知移动台收到寻呼指示后，会去SCCPCH还是HS-PDSCH信道上监听寻呼消息的问题。 [0032] 为达到上述目的，本发明实施例一方面提供一种确定寻呼传输信道的方法，包括以下步骤： [0033] 控制RNC获取移动台的能力信息； [0034] 所述控制RNC根据所述移动台的能力信息以及寻呼域的能力信息确定发送寻呼消息的信道。 [0035] 另一方面，本发明实施例还提供了一种触发服务无线网络子系统重定位的方法，包括以下步骤： [0036] 移动台判断服务RNC和控制RNC的能力信息是否一致； [0037] 如果不一致，则所述移动台发起上行接入过程，使原来的控制RNC成为新的服务RNC。 [0038] 再一方面，本发明实施例还提供了一种确定寻呼传输信道的系统，包括移动台和基站，还包括RNC，用于获取移动台的能力信息，并根据所述移动台的能力信息以及寻呼域的能力信息确定发送寻呼消息的信道。 [0039] 再一方面，本发明实施例还提供了一种触发服务无线网络子系统重定位的系统，包括移动台，用于判断服务RNC和控制RNC的能力信息是否一致，如果不一致，则发起上行接入过程，使原来的控制RNC成为新的服务RNC。 [0040] 与现有技术相比，本发明实施例具有以下优点：通过本发明实施例，控制RNC获取移动台的能力信息，并根据该移动台的能力信息以及寻呼域的能力信息确定发送寻呼消息的信道。在移动台判断服务RNC和控制RNC的能力信息不一致时，可以通过发起上行接入过程，使原来的控制RNC成为新的服务RNC。从而弥补了现有技术无法得知移动台的能力信息的缺陷，避免寻呼损失。附图说明 [0041] 图1是现有技术WCDMA中PICH与SCCPCH的时隙关系示意图； [0042] 图2是现有技术WCDMA中的PICH帧结构示意图； [0043] 图3是现有技术WCDMA中的PICH与HS-PDSCH的时隙关系示意图； [0044] 图4是现有技术中一种通信系统结构图； [0045] 图5是现有技术中一种确定寻呼传输信道的方法流程图； [0046] 图6是本发明实施例一中移动台确定寻呼传输信道方法流程图； [0047] 图7是本发明实施例二中移动台确定寻呼传输信道方法流程图； [0048] 图8是本发明实施例三中移动台确定寻呼传输信道方法流程图； [0049] 图9是本发明实施例四中移动台确定寻呼传输信道方法流程图； [0050] 图10是本发明实施例五中移动台确定寻呼传输信道方法流程图； [0051] 图11是本发明实施例六中移动台确定寻呼传输信道方法流程图； [0052] 图12是本发明实施例七中移动台确定寻呼传输信道方法流程图； [0053] 图13是本发明实施例十一中一种无线网络控制器触发服务无线网络子系统重定位的方法的流程图； [0054] 图14是本发明实施例十二中一种无线网络控制器触发服务无线网络子系统重定位的方法的流程图； [0055] 图15是本发明实施例十三中一种无线网络控制器触发服务无线网络子系统重定位的方法的流程图。 具体实施方式[0056] 本发明实施例中控制RNC获取移动台的能力信息和寻呼域的能力信息，然后控制RNC根据所述移动台的能力信息以及寻呼域的能力信息确定发送寻呼消息的信道。其中，所述移动台的能力信息为所述移动台是否支持增强寻呼特性，所述寻呼域的能力信息为所述寻呼消息发送小区是否支持增强寻呼特性。 [0057] 其中，根据移动台的能力信息以及寻呼域的能力信息确定发送寻呼消息的信道具体包括：控制RNC收到服务无线网络控制器SRNC对于某移动台的寻呼请求时，确定需要将所述寻呼请求在一个支持增强寻呼特性的小区中下发给所述移动台；所述控制RNC判断是否存储有所述移动台支持增强寻呼的信息，如果有，则在HS-PDSCH上发送寻呼消息，指示所述移动台按照增强寻呼方式在HS-PDSCH上发送寻呼消息。如果所述控制RNC中没存储所述移动台支持增强寻呼的信息，则所述控制RNC将所述移动台按照不支持增强寻呼特性和支持增强寻呼特性的两种情况计算出两个寻呼时机，并在所述两个寻呼时机中都传输相应的寻呼指示。 [0058] 其中，判断存储有所述移动台支持增强寻呼的信息之前包括：所述控制RNC获取并存储所述移动台是否支持增强寻呼特性。所述控制RNC获取并存储所述移动台是否支持增强寻呼特性具体包括：所述移动台向所述SRNC发送更新请求，所述请求中包括所述移动台是否支持增强寻呼特性的指示；所述SRNC向所述控制RNC发送寻呼请求，所述请求中携带所述指示；所述控制RNC获取并存储所述指示。或，所述控制RNC接收所述移动台更新时发送的RRC消息，获取并存储所述消息中所述移动台是否支持增强寻呼特性的指示。或，移动台在URA中的某个小区中发起上行接入并携带支持增强寻呼特性的能力信息；通过RNC之间的信息交互，移动台的能力信息被至少有一个小区属于该URA范围的所有控制RNC获得。 [0059] 本发明实施例一中一种移动台确定寻呼传输信道方法，如图6所示，包括以下步骤： [0060] 步骤s601，移动台在发送给网络侧的上行RRC信令中携带移动台支持增强寻呼特性能力的信息； [0061] 该上行RRC信令包含但不限于以下RRC信令：可以是RRC连接建立过程中的RRC信令，可以是小区更新消息，可以是URA更新消息。 [0062] 步骤s602，服务RNC将该移动台支持增强寻呼特性能力的信息存储于该移动台对应的RRC上下文中； [0063] 步骤s603，控制RNC接收寻呼请求消息； [0064] 该寻呼请求消息中携带移动台是否支持增强寻呼特性的指示信息； [0065] 或者也可以只携带移动台支持增强寻呼特性的指示信息，不携带该信息时认为移动台不支持增强寻呼特性。 [0066] 步骤s604，控制RNC根据移动台的能力信息以及寻呼域的能力信息决定发送寻呼消息的信道。 [0067] 如果移动台支持增强寻呼，并且寻呼消息发送的小区支持增强寻呼特性，则在HS-PDSCH信道上发送寻呼消息； [0068] 如果移动台支持增强寻呼，但是寻呼消息发送的小区不支持增强寻呼特性，则在SCCPCH信道上发送寻呼消息； [0069] 如果移动台不支持增强寻呼，但是寻呼消息发送的小区支持增强寻呼特性，则在SCCPCH信道上发送寻呼消息； [0070] 如果移动台不支持增强寻呼，并且寻呼消息发送的小区不支持增强寻呼特性，则在SCCPCH信道上发送寻呼消息。 [0071] 即，只有当移动台和寻呼消息发送的小区同时支持增强寻呼特性时，才在HS-PDSCH信道上发送寻呼消息。 [0072] 本发明实施例二中一种移动台确定寻呼传输信道方法，如图7所示，包括以下步骤： [0073] 步骤s701，移动台在发送给网络侧的上行RRC信令中携带移动台支持增强寻呼特性能力的信息； [0074] 该上行RRC信令包含但不限于以下RRC信令：可以是RRC连接建立过程中的RRC连接建立请求信令，可以是RRC连接建立完成，可以是小区更新消息，可以是URA更新消息。 [0075] 步骤s702，控制RNC从步骤s701所述的上行RRC消息中，获得并存储移动台是否支持增强寻呼特性的信息。 [0076] 步骤s703，控制RNC接收寻呼请求消息。 [0077] 步骤s704，与步骤s604相同。 [0078] 实施例一和实施例二的共同之处是，控制RNC需要通过某种途径获得移动台是否支持增强寻呼特性的能力信息；并利用移动台的能力信息和需要下发寻呼消息的小区是否支持增强寻呼特性的能力信息来共同判断在哪个信道上下发寻呼消息。不同的是，实施例一中是从服务RNC发送的寻呼请求消息中获得，而实施例二中是从移动台发送给网络侧的上行RRC消息中获得。 [0079] 本发明实施例三中一种移动台确定寻呼传输信道方法，如图8所示，包括以下步骤： [0080] 步骤s801，服务RNC每次为移动台分配新的U-RNTI时，或者每次服务RNC标识发生变化时，网络侧向移动台发送的RRC消息中携带SRNC是否支持增强寻呼特性的指示。其中，所述的RRC消息可以包括但不限于以下消息：切换到UTRAN命令(HANDOVER TO UTRAN COMMAND)；物理信道重配置消息(PHYSICAL CHANNEL RECONFIGURATION)；无线承载配置消息(RADIO BEARER RECONFIGURATION)；无线承载释放消息(RADIO BEARER RELEASE)；无线承载建立消息(RADIO BEARER SETUP)；RRC连接建立消息(RRC CONNECTION SETUP)；传输信道重配置消息(TRANSPORT CHANNEL RECONFIGURATION)；URA更新确认消息(URA UPDATE CONFIRM)；UTRAN移动通知消息(UTRAN MOBILITY INFORMATION)。 [0081] 步骤s802，移动台可以通过该指示判断服务RNC是否支持增强寻呼； [0082] 当网络侧为移动台分配了新的U-RNTI，但是却并未携带该指示时，移动台可以认为这个服务RNC不支持增强寻呼特性。 [0083] 步骤s803，控制RNC收到寻呼请求消息。 [0084] 步骤s804，控制RNC根据移动台的能力信息决定寻呼信道，发送寻呼消息； [0085] 如果控制RNC中没有存储关于这个移动台是否支持增强寻呼的信息，则控制RNC对于这个移动台，在其HS-PDSCH信道相关的寻呼指示信道以及SCCPCH相关的寻呼指示信道上都发送寻呼指示信息。 [0086] 即控制RNC在计算寻呼时机和PI bitmap(位图)时，将被呼移动台按照不支持增强寻呼特性和支持增强寻呼特性的两种情况，计算出两个寻呼时机，即两个PICH的SFN号，并在这两个寻呼时机中都传输相应的寻呼指示，向移动台表明“后续有寻呼消息”，并在HS-PDSCH信道相关的寻呼指示信道帧的扩展比特中包含“寻呼消息在SCCPCH”的信息。 [0087] 步骤s805，在SCCPCH信道上发送寻呼消息的内容。 [0088] 步骤s806，如果移动台支持增强寻呼特性，则移动台会读到HS-PDSCH信道相关的寻呼指示信道上的寻呼指示以及扩展比特中的“寻呼消息在SCCPCH”的信息。从而接下来到SCCPCH信道上接收寻呼消息的内容。 [0089] 实施例三中，只有满足以下条件的移动台会去读取PICH帧中的扩展比特：移动台处于URA_PCH状态，移动台支持增强寻呼特性，且当前所处小区支持增强寻呼特性，并且移动台的服务RNC不支持增强寻呼特性(可能是由于SRNC为Rel7以前版本的RNC，或者是一个Rel7版本之后的但是不支持增强寻呼特性的RNC)，不满足以上条件的移动台即使读到这个扩展比特，也会忽略其含义。 [0090] 从以上的分析可以知道，不满足这些条件的寻呼仍然会利用HSDPA信道下发；即使满足这些条件，寻呼消息仍然有机会在HSDPA信道下发，这取决于控制RNC是否了解移动台的增强寻呼特性能力，于是可以有效的利用HSDPA特性。 [0091] 本发明实施例四中，处于URA_PCH状态的支持增强寻呼特性的移动台了解到服务RNC不支持增强寻呼特性，而当前小区支持增强寻呼特性，则移动台在SCCPCH信道接收寻呼消息。控制RNC在计算寻呼时机和PI位图时，将被呼移动台按照不支持增强寻呼特性的移动台处理。具体过程如图9所示，包括以下步骤： [0092] 步骤s901～s903与步骤s801～s803相同。 [0093] 步骤s904，当控制RNC收到寻呼请求时，如果控制RNC获知服务RNC不支持增强寻呼特性，则对于这个移动台，在SCCPCH相关的寻呼指示信道上发送寻呼指示信息。 [0094] 控制RNC得知服务RNC的是否支持增强寻呼特性的方法可以是：控制RNC可以从SRNC发来的信令中获得，也可以从移动台发来的信令中获得。 [0095] 步骤s905，移动台监听到SCCPCH相关的寻呼信道上的寻呼指示后到SCCPCH信道上接收寻呼消息。 [0096] 本发明实施例五如图10所示，包括以下步骤： [0097] 步骤s1001，控制RNC接收寻呼请求消息。 [0098] 步骤s1002，如果控制RNC需要在支持增强寻呼的小区中下发寻呼消息，则控制RNC需要判断是否存储了关于这个移动台是否支持增强寻呼的信息，如果没有，则转步骤s1003。当然，实际应用中步骤s1002也可以省略。 [0099] 步骤s1003，控制RNC向寻呼请求中指示的小区中下发寻呼消息。控制RNC在HS-PDSCH信道和SCCPCH信道上发送寻呼消息， [0100] 发送的方式可以在HS-PDSCH信道和SCCPCH信道上同时发送寻呼消息，或者； [0101] 可以先在HS-PDSCH上发送寻呼消息，如果在一定时间内没有收到移动台的寻呼响应，再在SCCPCH上发送寻呼消息；或者 [0102] 可以先在SCCPCH上发送寻呼消息，如果在一定时间内没有收到移动台的寻呼响应，再在HS-PDSCH上发送寻呼消息；或者 [0103] 也可以先在HS-PDSCH上发送一定次数的寻呼消息，再在SCCPCH上发送一定次数的寻呼消息；或者 [0104] 也可以先在SCCPCH上发送一定次数的寻呼消息，再在HS-PDSCH上发送一定次数的寻呼消息；或者 [0105] 也可以在HS-PDSCH和SCCPCH上间隔发送寻呼消息。总之，无论采取何种发送方式，只要是在两个信道上都发了，就属于本发明的保护范围。 [0106] 如果在不支持增强寻呼特性的小区中下发，则控制RNC仅在SCCPCH上传输寻呼消息。 [0107] 在实施例五中，如果控制RNC需要在不支持增强寻呼特性的小区中下发寻呼消息，则控制RNC直接在SCCPCH信道上下发寻呼消息。如果控制RNC中存储了被呼移动台的能力信息，则当移动台和寻呼消息发送的小区都支持增强寻呼特性时，在高速物理下行共享信道HS-PDSCH信道上发送寻呼消息。当移动台和/或需要发送寻呼消息的小区不支持增强寻呼特性时，在SCCPCH信道上发送寻呼消息。 [0108] 本发明实施例六，如图11所示，包括以下步骤： [0109] 步骤s1101～s1102与S601～S602相同。 [0110] 步骤s1103，服务RNC可以根据移动台属于的URA标识信息，将移动台的增强寻呼特性能力信息通知给至少有一个小区属于该URA的其他RNC，于是移动台所在的控制RNC可以知道移动台支持增强寻呼特性的能力信息。 [0111] 步骤s1104，控制RNC接收寻呼请求消息。 [0112] 步骤s1105与步骤s604相同。 [0113] 本发明实施例七，如图12所示，包括以下步骤： [0114] 步骤s1201～s1202与S701～S702相同。 [0115] 步骤s1203，控制RNC可以根据移动台属于的URA标识信息，将移动台的增强寻呼特性能力信息通知给至少有一个小区属于该URA的其他RNC，于是即使移动台由于移动控制RNC发生变化，移动台当前所在的控制RNC仍然可以知道移动台支持增强寻呼特性的能力信息。 [0116] 步骤s1204～s1205与步骤s1104～s1105相同。 [0117] 实施例六、实施例七的共同之处是，通过RNC之间的信息交互，移动台的能力信息被至少有一个小区属于该URA范围的所有RNC获得。 [0118] 本发明实施例八： [0119] 服务RNC在寻呼请求消息或者其他的Iur接口上的信令中携带服务RNC是否支持增强寻呼特性的信息，以使控制RNC了解服务RNC是否支持增强寻呼的能力，如果未携带，认为服务RNC不支持增强寻呼。 [0120] 移动台通过步骤s801～s802可以了解服务RNC是否支持增强寻呼的信息。 [0121] 对于控制RNC，如果确定服务RNC不支持增强寻呼特性，则只在SCCPCH上发送寻呼消息；对于移动台，无论当前小区是否支持增强寻呼特性，只要其服务RNC不支持增强寻呼特性，则只在SCCPCH上接收寻呼消息。 [0122] 实施例九： [0123] 当控制RNC收到寻呼请求，需要在一个支持增强寻呼的小区中发送寻呼消息时： [0124] 如果寻呼请求中携带了移动台的能力信息，则根据移动台的能力信息在相应的信道上下发寻呼消息； [0125] 如果寻呼请求中没有携带移动台的能力信息，则认为移动台不支持增强特性，于是在SCCPCH信道上传输寻呼消息； [0126] 实施例十： [0127] 当控制RNC收到寻呼请求，需要在一个支持增强寻呼的小区中发送寻呼消息时： [0128] 如果控制RNC获知服务RNC不支持增强寻呼特性，则在SCCPCH信道上传输寻呼消息。 [0129] 控制RNC得知服务RNC是否支持增强寻呼特性的方法可以是：控制RNC可以从SRNC发来的信令中获得，也可以从移动台发来的信令中获得。 [0130] 本发明实施例十一，如图13所示，包括以下步骤： [0131] 步骤s1301，服务RNC每次为移动台分配新的U-RNTI时，在相应的RRC消息中携带服务RNC是否支持增强寻呼特性的指示。 [0132] 步骤s1302，移动台可以通过这个指示信息判断服务RNC是否支持增强寻呼。 [0133] 步骤s1303，移动台执行小区重选到一个支持增强特性的小区中。 [0134] 步骤s1304，如果移动台支持增强寻呼特性，且其服务RNC不支持增强特性，则移动台需要发起一个上行RRC过程。 [0135] 这个上行的RRC过程可以是小区更新或者URA更新或者其他的上行接入信令。 [0136] 这个上行的RRC消息中可以携带移动台是否支持增强特性的信息；也可以携带触发上行接入信令的原因。 [0137] 步骤s1305，服务RNC收到这个消息后，发起服务RNS relocation过程，重定位过程结束后，则原来的控制RNC成为移动台的新的服务RNC。 [0138] 本发明实施例十二，如图14所示，包括以下步骤： [0139] 步骤s1401，服务RNC每次为移动台分配新的U-RNTI时，在相应的RRC消息中携带服务RNC是否支持增强寻呼特性的指示。 [0140] 从图中可以看出，服务RNC主要是在RRC消息中携带本服务RNC是否支持增强寻呼特性的指示。显然，除了在为移动台分配新的U-RNTI时，在相应的RRC消息中携带本服务RNC是否支持增强寻呼特性的指示，也可以在其他的RRC消息中携带该指示，比如:服务RNC通过RRC消息指示移动台进入URA_PCH状态时，可以在相应的RRC消息中携带本服务RNC是否支持增强寻呼特性的指示。 [0141] 另外，服务RNC通过RRC消息携带本服务RNC是否支持增强寻呼特性的指示的这个步骤，除了在本实施例中有该步骤之外，在前述实施例十一及后面的实施例十三中均有同样的步骤，且具体实现相同，因此在其他两个实施例中不再详细描述。 [0142] 步骤s1402，移动台可以通过这个指示信息判断服务RNC是否支持增强寻呼。 [0143] 步骤s1403，支持增强寻呼特性的移动台，如果其服务RNC不支持增强特性，并且由于移动或者执行小区重选或者状态迁移后驻留到一个支持增强特性的小区中，则移动台需要向控制RNC发起一个上行RRC过程。 [0144] 这个上行的RRC过程可以是小区更新或者URA更新或者其他的上行接入信令。 [0145] 这个上行的RRC消息中可以携带移动台是否支持增强特性的信息；也可以携带触发这个上行接入信令的原因。 [0146] 步骤s1404，控制RNC获得并保存移动台支持增强寻呼的信息。 [0147] 步骤s1405，控制RNC获知服务RNC不支持增强寻呼特性； [0148] 控制RNC获知服务RNC不支持增强寻呼特性的过程可以通过Iur接口上的(包括但不限于)公共资源建立请求等信令中获得，也可以从移动台发来的信令中获得。 [0149] 另外，服务RNC可以通过不携带增强寻呼特性相关的信息来使得控制RNC认为其不支持增强寻呼特性。 [0150] 值得注意的是步骤s1404和步骤s1405没有时间上的顺序关系。 [0151] 步骤s1406，控制RNC发起RRC连接释放过程。 [0152] 步骤s1407，移动台收到RRC连接释放信令后，释放当前的RRC连接。 [0153] 步骤s1408，移动台在原先的控制RNC的小区中重新发起RRC连接建立过程，从而原来的控制RNC成为移动台新的服务RNC。 [0154] 本发明实施例十三，如图15所示，包括以下步骤： [0155] 步骤s1501，服务RNC每次为移动台分配新的U-RNTI时，在相应的RRC消息中携带服务RNC是否支持增强寻呼特性的指示。 [0156] 步骤s1502，移动台可以通过这个指示信息判断服务RNC是否支持增强寻呼。 [0157] 步骤s1503，移动台执行小区重选到一个支持增强特性的小区中。 [0158] 步骤s1504，如果移动台支持增强寻呼特性的，且其服务RNC不支持增强特性，则移动台需要发起一个上行RRC过程。 [0159] 这个上行的RRC过程可以是小区更新或者URA更新或者其他的上行接入信令。 [0160] 这个上行的RRC消息中可以携带移动台是否支持增强特性的信息；也可以携带触发上行接入信令的原因。 [0161] 步骤s1505，服务RNC发起RRC连接释放过程。 [0162] 步骤s1506，移动台在原控制RNC的小区中重新发起RRC连接建立过程，使原来的控制RNC成为移动台新的服务RNC。 [0163] 当移动台检测到当前服务RNC的能力与控制RNC的能力不一致时，或者移动台以其他方式获知当前服务RNC的能力与控制RNC的能力不一致时(例如，移动台具体可以通过网络侧专门用于通知移动台的信令获知该能力信息；或者，网络侧可以在某个信令中携带指示，通知移动台当前服务RNC的能力与控制RNC的能力不一致)，会发起上行接入过程。例如：当移动台获知当前服务RNC不支持增强寻呼特性，而当前控制RNC支持增强寻呼特性时，移动台就会发起一个上行接入过程。上述过程可以有多种实现方式，实施例十一、实施例十二和实施例十三分别是实现上述过程的一种具体实现方式，任何可以实现上述过程的方式均应落入本发明实施例的保护范围。 [0164] 本发明实施例十一和实施例十二，十三的共同之处是，使得原来支持增强寻呼特性的控制RNC成为移动台新的服务RNC，从而回避了发明目的中无法确定寻呼信道的场景的发生。 [0165] 另外，为了简化对标准的更改，也可以省略以上各实施例中控制RNC获取移动台的能力信息的步骤，直接将寻呼消息在SCCPCH和HS-PDSCH上发送，发送方式具体如下： [0166] 如果需要在支持增强寻呼特性的小区发送寻呼消息，则控制RNC在HS-PDSCH信道和SCCPCH信道上发送寻呼消息： [0167] 发送的方式可以在HS-PDSCH信道和SCCPCH信道上同时发送寻呼消息，或者； [0168] 可以先在HS-PDSCH上发送寻呼消息，如果在一定时间内没有收到移动台的寻呼响应，再在SCCPCH上发送寻呼消息；或者 [0169] 可以先在SCCPCH上发送寻呼消息，如果在一定时间内没有收到移动台的寻呼响应，再在HS-PDSCH上发送寻呼消息；或者 [0170] 也可以先在HS-PDSCH上发送一定次数的寻呼消息，再在SCCPCH上发送一定次数的寻呼消息；或者 [0171] 也可以先在SCCPCH上发送一定次数的寻呼消息，再在HS-PDSCH上发送一定次数的寻呼消息；或者 [0172] 也可以在HS-PDSCH和SCCPCH上间隔发送寻呼消息。总之，无论采取何种发送方式，只要是在两个信道上都发了，就属于本发明的保护范围。 [0173] 如果在不支持增强寻呼特性的小区中下发，则控制RNC仅在SCCPCH上传输寻呼消息。 [0174] 本发明实施例还提供了一种确定寻呼传输信道的系统，包括移动台和基站，还包括RNC，用于获取移动台的能力信息，并根据所述移动台的能力信息以及寻呼域的能力信息决定发送寻呼消息的信道。 [0175] 所述RNC具体包括：移动台能力获取单元，用于从寻呼请求消息中获取移动台是否支持增强寻呼特性；发送寻呼消息信道确定单元，与所述移动台能力获取单元连接，用于当移动台和寻呼消息发送的小区都支持增强寻呼特性时，确定在高速物理下行共享信道HS-PDSCH信道上发送寻呼消息；当移动台和/或需要发送寻呼消息的小区不支持增强寻呼特性时，确定在SCCPCH信道上发送寻呼消息；如果控制RNC无法获得移动台的能力信息，确定在HS-PDSCH信道和SCCPCH信道上发送寻呼消息。 [0176] 所述RNC还包括寻呼消息发送单元，用于在所述HS-PDSCH信道和SCCPCH信道上发送寻呼消息，具体为：在HS-PDSCH信道和SCCPCH信道上同时发送寻呼消息，或者[0177] 先在HS-PDSCH上发送寻呼消息，如果在一定时间内没有收到移动台的寻呼响应，再在SCCPCH上发送寻呼消息；或者 [0178] 先在SCCPCH上发送寻呼消息，如果在一定时间内没有收到移动台的寻呼响应，再在HS-PDSCH上发送寻呼消息或者 [0179] 先在HS-PDSCH上发送一定次数的寻呼消息，再在SCCPCH上发送一定次数的寻呼消息；或者 [0180] 先在SCCPCH上发送一定次数的寻呼消息，再在HS-PDSCH上发送一定次数的寻呼消息；或者 [0181] 在HS-PDSCH和SCCPCH上间隔发送寻呼消息。 [0182] 所述RNC还包括：移动台寻呼指示单元，与所述发送寻呼消息信道确定单元连接，用于在所述控制RNC无法获得移动台的能力信息时，向所述移动台发送指示信息，指示所述移动台到SCCPCH信道上接收所述寻呼消息。 [0183] 本发明实施例还提供了一种无线网络控制器触发服务无线网络子系统重定位的系统，包括移动台，用于判断服务RNC和控制RNC的能力信息是否一致，如果不一致，则发起上行接入过程，使原来的控制RNC成为新的服务RNC。 [0184] 所述移动台包括：判断单元，用于判断服务RNC和控制RNC的能力信息是否一致；切换单元，与所述判断单元连接，用于在所述判断单元判断所述服务RNC和控制RNC的能力信息不一致之后，发起上行接入过程，使原来的控制RNC成为新的服务RNC。 [0185] 所述切换单元包括：消息发送子单元，用于向所述服务RNC发送上行RRC消息；信令接收子单元，用于接收所述控制RNC发送的RRC连接释放信令；连接释放子单元，与所述信令接收子单元连接，用于在所述信令接收子单元接收到RRC连接释放信令之后，释放当前的RRC连接；连接建立子单元，与所述连接释放子单元连接，用于在所述连接释放子单元释放当前的RRC连接之后，在原来的控制RNC的小区中重新发起RRC连接建立过程，使原来的控制RNC成为新的服务RNC。 [0186] 所述触发服务无线网络子系统重定位的系统还包括服务RNC，用于在接收到所述移动台发送的RRC消息之后，发起服务RNS重定位过程，使原来的控制RNC成为新的服务RNC。 [0187] 所述触发服务无线网络子系统重定位的系统还包括控制RNC，用于向所述移动台发送RRC连接释放信令。 [0188] 本发明实施例中，移动台可以通过服务RNC发送的RRC消息获知该服务RNC是否支持增强寻呼特性；并且控制RNC可以获知移动台是否支持增强寻呼的能力，并可以确定移动台收到寻呼指示后会去SCCPCH还是HS-PDSCH信道上监听寻呼消息，避免呼损。 [0189] 通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。 [0190] 以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。 |
||||||
QQ群二维码
意见反馈
意见反馈