CN103843447A - 用于从pch或fach状态开始的语音呼叫建立的方法和系统 - Google Patents

Abstract

一种在用户设备处用于建立电路交换呼叫的方法，所述用户设备处于小区前向接入信道（CELL_FACH）状态、小区寻呼信道（CELL_PCH）状态或UTRAN注册区域寻呼信道（URA_PCH）状态下，所述方法包括：接收对电路交换呼叫待处理的指示；向网络单元发送用于便于所述用户设备向小区专用信道（CELL_DCH）状态转移的消息，所述消息是具有指示待处理上行链路数据超过阈值的业务量指示符信息单元的小区更新消息或RRCConnectionRequest消息之一；以及建立所述电路交换呼叫。

Description

用于从PCH或FACH状态开始的语音呼叫建立的方法和系统

技术领域

本公开涉及语音呼叫建立，且具体地涉及当通用移动电信系统（UMTS）用户设备（UE）处于CELL_PCH、URA_PCH或CELL_FACH状态下时的语音呼叫建立。

背景技术

在通用移动电信系统（UMTS）中，在语音呼叫结束之后，或由于在分组数据会话期间的数据不活跃，网络可以将具有已建立的分组数据协议（PDP）上下文的设备（例如，始终开机的设备）转移至CELL_PCH或URA_PCH状态，而不是转移至空闲模式下。该转移过程使得移动设备保持在已连接状态而没有指派任何无线资源，且为后续呼叫提供了更快的连接建立和需要更少的网络信令。

在CELL_PCH或URA_PCH状态下，用户设备（UE）使用不连续接收（DRX）来监视广播消息并经由寻呼指示符信道（PICH）进行寻呼，并根据需要执行小区更新或URA更新。

在各种网络通信中，当UE处于CELL_PCH状态或URA_PCH状态下时，或者在一些情况下甚至在设备处于CELL_FACH状态下时，如果接收到针对该设备的电路交换语音呼叫或者电路交换语音呼叫源自该设备，则网络可以不执行将设备快速转移至CELL_DCH状态。取而代之地，网络可以首先在直到建立无线承载为止的信令消息的交换期间将设备移动或保持在CELL_FACH状态下。这导致通过公共的低速率物理信道来执行呼叫建立，导致增大呼叫建立的时延。此外，在UE处于边界区域且要求将设备从一个小区转移到另一个小区的情况下，由于在CELL_FACH状态下不可能实现软切换或更软切换这一事实，在一些情况下呼叫建立可能失败。

附图说明

参考附图将更好地理解本公开，在附图中：

图1是示出了在UE的各种状态和模式之间进行转移的框图；

图2是示出了业务量测量报告的信令的数据流图；

图3是示出了在UE处用于向CELL_DCH快速转移的示例过程的过程图；

图4是示出了在UE处在确定网络能力之后向CELL_DCH快速转移的示例过程的过程图；

图5是对用于业务量测量报告的信令无线承载加以优先的过程图；

图6是示出了具有业务量指示符的小区更新的信令的数据流图；

图7是示出了在UE处用于向CELL_DCH快速转移的备选实施例的过程图；

图8是示出了在UE处用于在确定网络能力之后进行快速转移的备选实施例的过程图；

图9是示出了使用RrcConnectionRequest消息从空闲模式进行呼叫建立的信令的数据流图；

图10是示出了在UE处用于向CELL_DCH快速转移的备选实施例的过程图；

图11是示出了在UE处用于在确定网络能力之后进行快速转移的备选实施例的过程图；

图12是示出了能够与本公开一起使用的示例UE的框图；以及

图13是示出了示例网络架构的框图。

具体实施方式

本公开提供了在用户设备处用于建立电路交换呼叫的方法，所述用户设备处于小区前向接入信道（CELL_FACH）状态、小区寻呼信道（CELL_PCH）状态或UTRAN注册区域寻呼信道（URA_PCH）状态下，所述方法包括：接收对电路交换呼叫待处理的指示；向网络单元发送用于便于向小区专用信道（CELL_DCH）状态转移的消息，所述消息是具有指示待处理上行链路数据超过阈值的业务量指示符信息单元的小区更新消息；以及建立所述电路交换呼叫。

本公开还提供了一种被配置用于建立电路交换呼叫的用户设备，所述用户设备处于小区前向接入信道（CELL_FACH）状态、小区寻呼信道（CELL_PCH）状态或UTRAN注册区域寻呼信道（URA_PCH）状态下，所述用户设备包括：处理器；以及通信子系统，其中，所述处理器和通信子系统协作以：接收对电路交换呼叫待处理的指示；向网络单元发送用于便于向小区专用信道（CELL_DCH）状态转移的消息，所述消息是具有指示待处理上行链路数据超过阈值的业务量指示符信息单元的小区更新消息；以及建立所述电路交换呼叫。

本公开涉及UMTS，且具体地涉及在UMTS下各种无线资源控制（RRC）模式和状态之间的转移。具体地，用户设备（UE）可以处于空闲模式或与网络已连接（活跃）模式下。在已连接模式下，UE可以处于以下4种状态之一，即Cell_DCH、Cell_FACH、Cell_PCH以及URA_PCH，如下所述。

下面参考图1来描述在已连接模式和空闲模式之间的转移。

具体地，在诸如UMTS网络之类的第三代（3G）网络中，协议栈的无线资源控制（RRC）部分负责在UE和通用陆地无线接入网（UTRAN）之间的无线资源的指派、配置和释放。在3GPP TS25.331规范中详细描述了该RRC协议。UE可以处于的两种基本模式被定义为“空闲模式”和“UTRA已连接模式”。UTRA代表UMTS陆地无线接入。在空闲模式下，在UE想要发送任何用户数据的任何时间，UE需要请求RRC连接，或者在UTRAN针对电路交换（CS）或分组交换（PS）连接寻呼UE的任何时间UE需要响应于寻呼请求RRC连接。在3GPP规范TS25.304和TS25.331中详细描述了空闲和已连接模式下的行为。本公开所示的术语和定义符合TR21.905中的那些术语和定义。

如本领域技术人员将意识到的：UMTS网络包含两个基于陆地的网络段。它们是核心网（CN）和通用陆地无线接入网（UTRAN）（如图13所示）。核心网负责对CS或PS呼叫进行交换和路由以及负责通向外部网络的连接，而UTRAN处理所有无线相关功能。

当处于UTRA RRC已连接模式时，设备可以处于以下4种状态之一。它们是：

CELL_DCH：在该状态下在上行链路和下行链路上向UE分配了专用信道用于交换数据。UE必须执行如3GPPTS25.331中概述的动作。

CELL_FACH：在该状态下没有向用户设备分配专用信道。取而代之地，使用公共信道来交换少量的突发数据。UE必须执行如3GPP TS25.331概述的动作，3GPP TS25.331包括如3GPP TS25.304中定义的小区选择过程。

CELL_PCH：UE使用不连续接收（DRX）来监视广播消息并经由寻呼指示符信道（PICH）来监视寻呼。在该状态下，UE是在小区级别已知的。UE必须执行如3GPP TS25.331中概述的动作，3GPP TS25.331包括如3GPP TS25.304中定义的小区选择过程。UE必须针对每个小区重新选择过程，执行小区更新过程。

URA_PCH：UE使用不连续接收（DRX）来监视广播消息并经由寻呼指示符信道（PICH）来监视寻呼。上行链路活动是不可能的。UE必须执行如3GPP TS25.331中概述的动作，3GPP TS25.331包括如3GPP TS25.304中定义的小区选择过程。除了下述区别之外，该状态与CELL_PCH类似：UE是在UTRA注册区域（URA）级别上已知的，且被要求执行URA更新过程。

图1是示出了UE上的协议栈的无线资源控制部分的各种模式和状态的框图。具体的，RRC可以要么处于RRC空闲模式110，要么处于RRC已连接模式120。

在空闲模式110下，在UE需要与网络交换信息的任何时间，UE请求RRC连接以建立无线资源。这可以要么是作为UE发起连接的结果，要么是作为UE监视寻呼信道以指示UTRAN是否针对CS或PS呼叫已寻呼了该UE的结果。此外，在UE需要发送移动性管理信令消息（例如，位置区域更新）的任何时间，UE也请求RRC连接。

一旦UE已向UTRAN发送了建立无线连接的请求，UTRAN就选择要处于的RRC连接状态。具体地，RRC已连接模式120包括4个不同的状态。它们是CELL_DCH状态122、CELL_FACH状态124、CELL_PCH状态126以及URA_PCH状态128。

从空闲模式110开始，RRC已连接模式120可以要么去往小区专用信道（CELL_DCH）状态122，要么去往小区前向接入信道（CELL_FACH）状态124。

在CELL_DCH状态122下，向UE分配用于上行链路和下行链路的专用信道用于交换数据。由于该状态具有分配给UE的专用物理信道，因此该状态通常提供更快的数据交换、更低的时延、以及鲁棒的无线连接。

备选的，UTRAN可以从空闲模式110移动至CELL_FACH状态124。在CELL_FACH状态124下，不向UE分配专用信道。取而代之地，使用公共信道来交换信令或少量的突发用户平面数据。

在RRC已连接模式120下，RRC状态可以由UTRAN酌情来改变。具体地，如果检测到在特定量的时间上数据不活跃或数据吞吐量低于特定阈值，则UTRAN可以将RRC状态从CELL_DCH状态122移动至CELL_FACH状态124、CELL_PCH状态126或URA_PCH状态128。类似地，如果检测到有效载荷高于特定阈值，则可以将RRC状态从CELL_FACH124移动至CELL_DCH122。

从CELL_FACH状态124开始，如果在一些网络中检测到在预定时间上数据不活跃，UTRAN可以命令UE将RRC状态从CELL_FACH状态124移动至寻呼信道（PCH）状态。这可以是CELL_PCH状态126或URA_PCH状态128。

从CELL_PCH状态126或URA_PCH状态128开始，为了发起与网络的任何通信，UE必须移动至CELL_FACH状态124。

CELL_PCH状态126和URA_PCH状态128使用不连续接收周期（DRX）来监视广播消息以及通过寻呼指示符信道（PICH）的寻呼。上行链路活动是不可能的。

从网络的角度来看，CELL_PCH状态126和URA_PCH状态128之间的差异在于：在URA_PCH状态下，UE在UTRAN注册区域级别上对于网络是已知的；反之在CELL_PCH状态下，UE在小区级别上对于网络是已知的。

在支持CELL_PCH或URA_PCH的网络中，在语音呼叫结束之后，或由于在分组数据会话期间的数据不活跃，始终开机的UE预期在网络的命令下移动至CELL_PCH或URA_PCH状态。这种网络处理对始终开机设备的主要影响是：维持了分组数据协议（PDP）连接，并且还提供了电路交换（CS）服务。

在实现了CELL_PCH或URA_PCH特征的无线网络中，网络通常配置业务量测量，以便于UE为了分组数据呼叫而向无线资源丰富的CELL_DCH状态快速转移。当在UE处满足了业务量测量方面指定的标准时，UE发送指示标准被满足的事件触发的测量报告。对单独消息发送进行补充的另一方法是在用于从CELL_PCH或URA_PCH状态开始建立分组数据呼叫的请求中包括指示符，该指示符暗示已经满足了业务量标准。

然而，由于业务量测量或指示符一般被用于分组数据呼叫，移动发起（MO）或端接（MT）的电路交换语音呼叫的建立通常是在CELL_FACH状态下执行的。

在CELL_FACH状态下，网络和个体UE之间的无线链路不是闭环功率受控的，且宽带码分多址（WCDMA）的关键特征之一“软切换”是不可能的。这使得连接更容易受到不利无线信道条件的影响。此外，在CELL_FACH状态下，无线资源仅允许非常低的数据速率，每秒32千比特是下行链路上的典型配置。此外，CELL_FACH状态是共享的资源，且基于其他用户的网络业务可能进一步增加连接时延。这种条件对于被视为高优先级且在建立语音呼叫所要求的时延和成功率方面具有比分组交换呼叫更高的用户体验影响的电路交换呼叫（例如，语音呼叫）建立是不理想的。

表1：呼叫建立时间比较

例如，现在参考表1。在表1中，使用3个网络来测试CS呼叫建立的时延。在每个测试中，网络将CELL_PCH下和空闲模式下的DRX周期长度系数分别设为5和7。如已留意本公开的本领域技术人员将意识到的：DRX周期长度系数5是较短的DRX时段，且从而理论上应当加速呼叫建立过程。

然而，在每种情况下，对于移动发起（MO）和移动端接（MT）呼叫，即使在CELL_PCH状态下使用更短的DRX时段，呼叫建立从空闲模式开始也比从CELL_PCH状态下开始更快。

如可以从第一网络中看到的：对于DRX配置不具有任何时延影响的移动发起呼叫建立场景，呼叫建立时间存在3.673秒的差异。

对于移动端接呼叫情况，在第一网络中，从空闲模式开始的信道建立比从CELL_PCH状态开始的快1.094秒。

此外，与空闲模式下的DRX7配置相比，DRX5配置和CELL_PCH提供了平均480毫秒的平均值。考虑到该事实，在类似的DRX设置下，移动端接电路交换呼叫的性能差异可以近似是1.5秒。

对于第二网络运营商，看到类似的结果。尽管移动发起和移动端接呼叫中的差异在第二网络上稍小，从空闲模式开始的连接依然快于从CELL_PCH状态开始的连接。

在空闲模式的呼叫建立和从CELL_PCH开始的呼叫建立之间的显著时延性能差异部分是由于在CELL_FACH状态下可用的物理信道的非常低的数据速率。在上述网络中，在下行链路上，FACH传输信道数据速率是每秒32千比特，而在上行链路上，随机接入信道（RACH）传输信道数据速率是每秒16千比特。

此外，即使在使用可用于CELL_FACH的最大数据速率的情况下，从CELL_PCH开始的呼叫建立的延迟也很高。这部分是由于以下事实：相同的资源被用于相同小区中的用户的控制信道和业务信道。

如上所述，在呼叫建立期间网络将设备从CELL_PCH状态向CELL_FACH状态转移而不是直接向CELL_DCH状态转移导致了延迟。

利用业务测量进行快速DCH转移

如果在呼叫建立时网络不将设备从CELL_PCH或URA_PCH向CELL_DCH直接转移，UE可以利用业务量测量方法，以更快速地将UE向CELL_DCH状态转移。

这可以使用以下两种量指示符之一来进行。

业务量测量报告

根据3GPP TS25.331第8版标准“Universal MobileTelecommunication System Radio Resource Control”，版本8.14.0，2011年3月29日，其内容以引用方式并入本文中，根据第8.4.2节，UE可向UTRAN发送测量报告。

具体地，根据第8.4.2.2节，如果UE处于CELL_FACH状态下，当任何外出业务量测量满足了变量measurement_identity中存储的报告标准时，UE应当在上行链路DCCH上发送测量报告消息。

类似地，在CELL_PCH或URA_PCH下，如果未发起测量报告，则UE可以在发送测量报告之前移动至CELL_FACH。相反地，如果指示了测量报告，则发送具有原因“上行链路数据发送”的小区更新消息，在此之后发送测量报告。

如果例如已达到业务阈值，则可以发送测量报告，其将使得UE快速地向CELL_DCH转移。

根据本公开的一个实施例，为了向CELL_DCH快速转移，即使尚未满足数据阈值，当接收到针对电路交换呼叫的指示时，UE也可以向UTRAN发送测量报告。这种指示可以是移动发起或移动端接的CS呼叫。

使用现有业务量测量报告的结果允许UE便于转移到CELL_DCH状态中，以减少针对电路交换呼叫的呼叫建立的业务时延，以及增加了电路交换呼叫的无线连接的鲁棒性。

现在参考图2，其示出了在UE210和UTRAN212之间的呼叫流程。

一旦处于CELL_PCH、URA_PCH或CELL_FACH状态下的UE210接收到针对该设备的呼叫待处理的指示，UE210将首先发送小区更新消息，如箭头224所示，以对寻呼过程进行应答。稍后在该过程期间，UE210可以选择向UTRAN发送业务量测量报告，如下面关于图3和4所描述的那样。具体地，该指示可以是来自UTRAN的寻呼，其指示了针对该UE的电路交换呼叫正在等待（移动端接呼叫），如箭头220所示，或者该指示可以是在UE上用户发起的电路交换呼叫（移动发起呼叫），如箭头222所示。

如果UE判定向CELL_DCH的转移可能不是网络发起的，则UE发送业务量测量报告，其指示了业务量超过了预配置的阈值。这种报告由2图中箭头230所示。

响应于对业务量测量报告的接收，UTRAN212发送具有到CELL_DCH的小区更新的确认，如箭头232所示。

一旦UE210已转移到CELL_DCH，电路交换呼叫建立正常发生。这由图2中箭头240所示。

从UE的角度来说，参考图3来描述执行的方法。图3的过程开始于步骤310。该过程的前提条件是UE处于CELL_PCH、URA_PCH或CELL_FACH状态下。

然后该过程进行至步骤312，在步骤312中，进行检查以确定UE是否已接收到电路交换呼叫指示。步骤312的检查可以是针对移动发起呼叫，或可以基于指示了针对该设备的移动端接呼叫正在等待的寻呼信道指示。

从步骤312开始，如果不存在电路交换呼叫指示，则过程继续进行以循环回步骤312，直到接收到电路交换呼叫指示。

一旦在步骤312接收到电路交换呼叫指示，过程进行至步骤320，在步骤320中，从UE向UTRAN发送业务量测量报告。

从步骤320开始，UTRAN基于如线330所示的业务量测量报告，将UE向CELL_DCH状态转移，且过程从步骤320进行至步骤340，在步骤340中建立呼叫。如本领域技术人员将意识到的：呼叫的建立涉及在UE和UTRAN之间用于建立专用电路交换连接的各种通信。

从步骤340开始，过程进行至步骤350并结束。

在备选实施例中，网络可以在特定环境下实现向CELL_DCH状态的快速转移，且从而可能不需要业务量测量报告。现在参考图4。

图4的过程开始于步骤410并进行至步骤412，在步骤412中，进行检查以确定是否已接收到CS呼叫指示。与图3的实施例一样，该指示可以是移动端接或移动发起的呼叫。

如果未接收到指示，图4的过程在步骤412循环。一旦接收到指示，过程从步骤412进行至步骤414。

在步骤414，过程检查网络是否支持向CELL_DCH快速转移。从步骤414开始，如果网络支持快速转移或如果UE不知道网络是否支持快速转移，过程进行至步骤420，在步骤420中，尝试呼叫建立。

在步骤420之后，移动设备可以检查网络是否支持快速转移，如步骤422所示。这种检查可能涉及发现小区更新过程是否引起UTRAN将UE从CELL_FACH转移到CELL_DCH状态。快速转移将是去往CELL_DCH。如果不支持快速转移，则过程进行至步骤424，在步骤424中，移动设备存储网络不支持快速转移的信息，供将来呼叫建立之用。在一些实施例中，对这种信息的存储可以仅到UE的无线装置关闭之前有效或仅到UE转移到新的网络之前有效，其后可以清除存储器。从而，当无线装置开启或转移网络时，UE可以假定支持快速转移，直到在CS呼叫尝试之后为止。备选地，在其他实施例中，学习阶段可以涉及多个CS呼叫尝试以确定网络是否支持快速转移。网络可以例如仅在良好的无线条件下才转移到CELL_DCH，且从而学习阶段可能需要多个CS呼叫尝试以确定网络是否支持向CELL_DCH快速转移。

从步骤422或步骤424开始，过程进行至步骤430并结束。

相反地，如果UE知道网络不支持快速转移，过程从步骤412进行至步骤440，在步骤440中，向网络发送业务量测量报告。这导致UE被转移至CELL_DCH，如线442所示。

然后，过程进行至步骤450，在步骤450中，根据正常过程建立呼叫，然后过程进行并在步骤430处结束。

在一些网络中，即使发送了业务量测量报告，初始直接传输报告也可以抢在业务量测量报告前面，且从而使得呼叫将在CELL_FACH下建立。具体的，UE具有多个信令无线承载（SRB），其中每一个具有特定的用途。在一个实施例中，在SRB2上信号通知业务量测量报告。

初始直接传输消息（IDT）是从UE向UTRAN发送的消息。其通常在SRB3上进行信号通知，且导致从UTRAN向UE返回安全模式命令。该安全模式命令过程是电路交换呼叫建立的一部分，且要求用于多个步骤以完成该过程。如果UE依然处于CELL_FACH状态下，则上面指出的问题（即，高时延和可能的呼叫建立失败）可能发生。

由网络来设置信令无线承载的优先级。一些网络使用相同的优先级来实现所有SRB。在其他网络中，SRB1的优先级最高，SRB2次高，且SRB3是第三高。

如果SRB2的优先级高于SRB3的优先级，则业务量测量报告将具有更高的优先级，且将确保UE在呼叫建立之前转移到CELL_DCH。然而，如果SRB的优先级是相等的，则IDT可能反超业务量测量报告，并从而使得在CELL_FACH下发生呼叫建立。为了避免这种不想要的行为，UE可以实现图5所示的方法。

在图5中，过程开始于步骤510并进行至步骤520。在步骤520中，进行检查以确定用于IDT的SRB的优先级是否大于等于用于业务量测量的SRB的优先级。如果是，则过程进行至步骤530。相反地，如果步骤520的检查结果是否，则过程进行至步骤540并结束。

在步骤530中，UE RRC层向MAC层发送命令，以降低IDT的SRB的优先级。这种改变SRB的优先级的命令对于本领域技术人员将是已知的。基于该命令，MAC层将用于IDT的SRB的优先级降低至比用于业务量测量报告的优先级更低的级别，从而确保UE在呼叫建立之前转移至CELL_DCH。

图5的过程可以例如在上述图3和4的步骤320和440之前执行。

用于确保在业务量测量报告之前不发送IDT的备选方案包括在SRB1上发送业务量测量报告。

其它备选包括推迟将IDT加入队列，直到已发生事件为止。这种事件包括（但不限于）：将加入队列推迟预定时长、将加入队列推迟到接收到针对业务量测量的层2ACK、将加入队列推迟到已选择要发送的业务量测量报告、或将加入队列推迟到已发送业务量测量报告。

在小区更新消息中的业务量指示符

在备选实施例中，取代使用业务量测量报告，UE可以将3GPPTS25.331的8.3.1.3节中定义的小区更新中的业务量指示符信息单元（IE）用于向UTRAN进行信号通知。

具体地，UE可以使用业务量指示符来指示已超过了数据量的阈值。在该过程中，UE将该业务量指示包括在小区更新消息中，而不是发送具有业务量测量的单独测量报告。这种过程预期会加速CELL_DCH转移过程。在该实施例中，UE可以通过将该业务量指示符用于待处理的电路交换呼叫来发起向CELL_DCH状态的快速转移。从而，尽管事实上该呼叫的本质是电路交换的，UE可以将该IE设为真（向网络指示增大了数据业务量阈值）。

如已留意本公开的本领域技术人员将意识到的：在一些实施例中，网络可以不实现业务量指示符特征，在该情况下，UE可以使用如上提供的业务量测量报告。

现在参见图6，其示出了在UE610和UTRAN612之间的信令。在图6的实施例中，UE610接收对电路交换呼叫待处理的指示。这可以是来自UTRAN的针对移动端接呼叫的寻呼指示，如箭头620所示。备选地，这可以是移动发起呼叫，如箭头622所示。

响应于该指示，UE610向UTRAN612发送具有业务量指示符信息单元的小区更新，如箭头630所示。UTRAN612发送具有将UE转移到CELL_DCH状态的小区更新确认的确认消息，如箭头632所示。

然后电路交换呼叫建立正常进行，如箭头640所示。

从UE的角度来说，现在参考图7。在图7中，过程开始于步骤710，其中，前提条件是UE处于CELL_PCH、URA_PCH或CELL_FACH状态下。过程进行至步骤712，其中，进行检查以确定电路交换呼叫指示是否待处理。这可以是移动端接呼叫或移动发起呼叫。如果否，过程进行以循环回步骤712。

一旦已接收到电路交换呼叫指示，过程进行至步骤720，在步骤720中，发送小区更新消息，在该小区更新消息中，将业务量指示符IE设为真。

在步骤720处对消息的发送使得UE向CELL_DCH转移，如箭头730所示。

然后过程进行至步骤740，在步骤740中，在UE和UTRAN之间通过CELL_DCH信道来协商呼叫的建立。

然后过程进行至步骤750并结束。

因此上面转移至CELL_DCH状态，以减少电路交换呼叫建立的时延。

在另一实施例中，可以进行检查以确定网络是否支持在发送具有业务量指示符IE的小区更新消息之前UE向CELL_DCH的快速转移。

现在参考图8。图8的过程开始于步骤810并进行至步骤812，其中，进行检查以确定是否已接收到电路交换呼叫指示。如果否，过程进行至返回步骤812，并继续循环，直到已接收到电路交换呼叫指示符。

从步骤812开始，如果已接收到电路交换呼叫指示，则过程进行至步骤814，在步骤814中，进行检查以确定网络是否支持快速转移。

如果网络支持该转移或如果不知道网络是否支持快速转移，则过程进行至步骤820，以建立呼叫。

然后过程进行至步骤822，在步骤822中，进行检查以确定是使用CELL_FACH还是CELL_DCH来建立呼叫。如果使用CELL_DCH来建立呼叫，则过程进行至步骤830并结束。

相对地，如果使用CELL_FACH来进行呼叫，则过程进行至步骤824，其中，将存储与网络有关的信息以供将来在步骤814处的判决之用。这同样可以在单个或多个CS呼叫尝试之后执行。

然后过程进行至步骤830并结束。

从步骤814开始，如果网络不支持快速转移，则过程进行至步骤840，并发送具有被设为真的业务量指示符IE的小区更新消息。

在步骤840处的消息发送使得转移至CELL_DCH，如步骤842所示。

然后过程进行至步骤850并建立呼叫，然后进行至步骤830并结束。

从网络的角度来说，如果UTRAN接收到具有被设为真的业务量指示符的小区更新消息，或如果网络接收到指示关于阈值的业务量测量的测量报告，则网络可以将UE转移到CELL_DCH状态。尽管这种转移并未在3GPP标准中规定，但除非网络面临无线资源问题，否则网络通常将UE转移到CELL_DCH。随后，通过基于CELL_DCH的专用信道来进行UE和UTRAN之间的通信，然后可以将该专用信道用于建立电路交换呼叫。

RRC连接请求

在另一实施例中，UE可以丢弃现有的到UTRAN的无线资源连接，以便为了新的无线资源连接更快而转移到CELL_DCH状态。具体地，当UE处于CELL_FACH或CELL_PCH或URA_PCH状态下时，为了发起语音呼叫，不是从CELL_PCH发送小区更新或从CELL_FACH发送初始直接传输，而是发送RRCConnectionRequest（RRC连接请求）。

具体地，当UE处于CELL_PCH下时，其应当使用小区更新消息与UTRAN通信。然而，3GPP技术规范指示了在UE和UTRAN之间可能发生失去同步。这可能发生在例如当UE离开UTRAN的范围且与同一公共陆地移动网络（PLMN）通信时。与PLMN的通信可以指示已存在同步问题，且可以使得释放所有RRC连接并进行至空闲模式。

根据本公开，即使并未失去同步，UE也可以向UTRAN发送RRCConnectionRequest。UTRAN将基于该RRCConnectionRequest来建立CELL_DCH无线承载，并将意识到UE已变得与UTRAN失去同步，且从而将释放所有CELL_PCH资源。

如果RRCConnectionRequest指示存在电路交换呼叫，则网络将发起进入CELL_DCH状态的RRC连接建立，其将导致去往CELL_DCH的更快连接，且因此使得电路交换呼叫能够更快速地建立。

关于图9示出了上述信令。具体地，UE910与UTRAN912通信。UE910接收对呼叫待处理的指示。这可以是来自UTRAN912的针对移动端接呼叫的寻呼指示，如箭头920所示，或者可以是移动发起呼叫，如箭头922所示。

一旦UE910接收到指示，UE向UTRAN912发送RRCConnectionRequest，如箭头930所示。该消息通常在UE处于空闲模式下时发送，但是如果UTRAN912在UE处于已连接模式下时接收到该消息，则其将拆除UE的现有RRC连接，并发送RRC连接建立消息，如箭头932所示。

由于RRCConnectionRequest指示电路交换呼叫待处理，所以RRC连接建立将确保UE在CELL_DCH下。

随后，从UE910向UTRAN912发送RRCConnectionSetupComplete（RRC连接建立完成）消息，如箭头934所示。

然后电路交换呼叫建立将正常进行，如箭头940所示。

现在参考图10。在图10中，过程开始于步骤1010，在步骤1010中，前提条件是在UE上实现CELL_PCH、URA_PCH或CELL_FACH状态。

然后过程进行至步骤1012，在步骤1012中，进行检查以确定是否已接收到电路交换呼叫指示。如果否，则过程进行至循环制步骤1012，直到接收到电路交换呼叫指示为止。同样地，电路交换呼叫指示可以是针对在UE上发起呼叫的尝试，在该情况下，正在执行移动发起呼叫。此外，呼叫指示可以是在寻呼信道上的来自网络的用于指示存在进行中的移动端接呼叫的指示。

从步骤1012开始，过程进行至步骤1020，在步骤1020中，从UE向网络发送RRCConnectionRequest。RRCConnectionRequest中的指示是：存在等待的电路交换呼叫，其使得网络拆除现有的RRC连接，并在CELL_DCH状态下建立新的RRC连接。由例如箭头1030示出了向CELL_DCH状态的转移。

然后过程进行至步骤1040，在步骤1040中，通过CELL_DCH来建立呼叫，然后进行至过程结束的步骤1050.

与上述实施例一样，UE可以进行检查以确定网络是否支持为了电路交换呼叫建立而从CELL_PCH或CELL_FACH状态向CELL_DCH状态的快速转移。如果是，则该过程是不必要的。然而，如果否，则过程将进行至发送具有电路交换呼叫指示的RRCConnectionRequest。

具体地，现在参考图11。图11的过程开始于步骤1110并进行至步骤1112，其中，进行检查以确定是否已接收到电路交换呼叫指示。如果否，过程进行以在步骤1112处循环，直到接收到电路交换呼叫为止。

然后过程进行至步骤1114，在步骤1114中，进行检查以确定网络是否支持快速转移。如果是，或如果UE不知道，则过程进行至步骤1120以建立呼叫。

在步骤1120之后，过程进行至步骤1122以确定使用CELL_FACH还是CELL_DCH来进行呼叫建立。如果使用CELL_FACH来执行呼叫建立，则过程进行至步骤1124，在步骤1124中，存储网络不支持快速转移的信息，且过程进行至步骤1130并结束。在一些实施例中，还可以使用学习阶段，以通过多个CS呼叫尝试来确定网络是否支持快速转移。

相反地，从步骤1122开始，如果在CELL_DCH下执行呼叫建立，则网络支持快速转移，且过程从步骤1122直接进行至步骤1130并结束。

如果在步骤1114的检查期间，确定网络不支持快速转移，则过程进行至步骤1140，在步骤1140中，从UE向UTRAN发送指示电路交换呼叫待处理的RRCConnectionRequest。

基于在步骤1140处对消息的接收，网络将拆除现有的RRC连接并建立用于CELL_DCH的新RRC连接。这由步骤1142所示。

然后过程进行至步骤1150，在步骤1150中，使用CELL_DCH来建立呼叫，然后过程进行至步骤1130并结束。

实际测试已经表明针对电路交换呼叫建立转移至CELL_DCH可以比使用CELL_FACH的类似呼叫建立节约近似1.5秒。

基于上述内容，可以通过使得UE更快速地转移至CELL-DCH状态来降低呼叫建立所需的时延。

上面描述了三种提案，包括当设备处于CELL_PCH、URA_PCH或CELL_FACH下时对以下各项的使用：小区更新中的业务测量指示符、业务量测量报告、或RRC连接建立请求。

尽管可以在各种UE上实现上述实施例，下面关于图12来概述一个UE的示例。现在参考图12。

UE1200一般是至少具有语音和数据通信能力的双向无线通信设备。UE1200可以具有与互联网上的其它计算机系统通信的能力。取决于提供的具体功能，无线设备可以被称为例如数据消息收发设备、双向寻呼机、无线电子邮件设备、具有数据消息收发能力的蜂窝电话、无线互联网电器、或数据通信设备。

在UE1200支持双向通信的情况下，其可以并入通信子系统1211，包括接收机1212和发射机1214以及关联的组件，例如一个或多个嵌入式或内置的天线单元1216和1218、本地振荡器（LO）1213、以及处理模块（例如数字信号处理器（DSP）1220）。如对于通信领域技术人员将显而易见的是：通信子系统1211的具体设计将取决于该设备预期工作所处的通信网络。例如，UE1200可以包括被设计为在GPRS网络或UMTS网络中工作。

网络接入要求也将根据网络1219的类型而变化。例如，在UMTS和GPRS网络中，网络接入与UE1200的订户或用户关联。例如，GPRSUE因此要求订户身份模块（SIM）卡，以在GPRS网络上工作。在UMTS中，要求USIM或SIM模块。在CDMA中，要求RUIM卡或模块。本文中它们将被称为UIM接口。在没有有效UIM接口的情况下，UE可以没有完全正常工作。本地或非网络通信功能以及法律要求的功能（如果有的话）（例如，进行紧急呼叫的能力）可以可用，但是UE1200将不能执行涉及通过网络1219进行通信的任何其他功能。UIM接口1244一般类似于其中可以插入和弹出卡的卡槽，类似于磁盘或PCMCIA卡。UIM卡可以保持很多关键配置1251以及其它信息1253（例如标识）、以及订户相关信息。

当已完成所要求的网络注册或激活过程时，UE1200可以通过网络1219发送和接收通信信号。将天线1216通过通信网络1219接收到的信号输入接收机1212，接收机1212可以执行常见的接收机功能，例如信号放大、降频转换、滤波、信道选择等，且在图12所示的示例系统中，还可以执行模数（A/D）转换。对接收信号的A/D转换允许更复杂的通信功能，例如要在DSP1220中执行的解调和解码。类似地，由DSP1220来处理要发送的信号，包括例如调制和编码，并将其输入发射机1214用于数模转换、升频转换、滤波、放大和经由天线1218在通信网络1219上发送。DSP1220不仅处理通信信号，还提供接收机和发射机控制。例如，可以通过在DSP1220中实现的自动增益控制算法来自适应控制在接收机1212和发射机1214中对通信信号应用的增益。

网络1219还可以与包括服务器和其它单元（未示出）在内的多个系统通信。例如，网络1219可以与企业系统和web客户端系统都通信，以适应具有各种服务级别的各种客户端。

UE1200可以包括控制设备整体操作的微处理器1238。通过通信子系统1211来执行包括数据通信在内的通信功能。微处理器1238还与其他设备子系统交互，例如：显示器1222、闪存1224、随机存取存储器（RAM）1226、辅助输入/输出（I/O）子系统1228、串口1230、键盘1232、扬声器1234、麦克风1236、包括一般被表示为1240的短距通信子系统在内的任何其他通信、以及一般被表示为1242的任何其他设备子系统。

图12所示的子系统中的一些执行通信相关功能，反之其他子系统可以提供“驻留”或设备上功能。注意到：一些子系统（例如，键盘1232和显示器1222）可以用于通信相关功能（例如，输入用于通过通信网络发送的文本消息）和设备驻留功能（例如，计算器或任务列表）这二者。

可以将微处理器1238使用的操作系统软件存储在持久性存储器中，例如闪存1224，其可以代之以只读存储器（ROM）或类似存储元件（未示出）。本领域技术人员将意识到：可以将操作系统、特定设备应用、或其一部分临时加载到易失性存储器中，例如RAM1226。还可以将接收到的通信信号存储在RAM1226中。此外，优选地在只读存储器中还存储独一无二的标识符。

如图所示，可以将闪存1224分为用于计算机程序1258和程序数据存储1250、1252、1254和1256的不同区域。这些不同的存储类型指示了每个程序可以分配一部分闪存1224用于其自身的数据存储要求。除了微处理器1238的操作系统功能之外，微处理器1238还可以使得在UE上能够执行软件应用。可以在制造期间在UE1200上安装包括例如数据和语音通信应用在内的控制基本操作的预定应用集合。一个软件应用可以是个人信息管理器（PIM）应用，其具有组织和管理与UE的用户相关的数据项的能力，数据项是例如（但不限于）：电子邮件、日历事件、语音邮件、约会、以及任务项。其它应用可以包括多媒体应用、社交网络应用、即时通讯应用等。

在数据通信模式下，接收信号（例如，文本消息或网页下载）可以由通信子系统1211来处理并被输入到微处理器1238，微处理器1238可以进一步处理接收信号以向显示器1222输出，或备选地向辅助I/O设备1228输出。UE1200的用户还可以使用例如键盘1232（在一个实施例中，其实完整字母数字键盘或电话型键区）结合显示器1222以及可能的辅助I/O设备1228来撰写数据项（例如，电子邮件消息）。然后可以通过通信子系统1211在通信网络上发送这种撰写的项目。

对于语音通信，UE1200的整体操作是类似的，除了接收信号通常将被输出到扬声器1234，且发送信号将由麦克风1236来生成。还可以在UE1200上实现备选的语音或音频I/O子系统，例如语音消息记录子系统。尽管语音或音频信号输出一般主要通过扬声器1234来实现，显示器1222也可以用于提供对例如以下各项的指示：主叫方的身份、语音呼叫的时长、或其它语音呼叫相关信息。

图12中的串口将一般在个人数字助理（PDA）型的UE中实现，可能需要将该PDA型UE与用户的台式计算机（未示出）进行同步。这种端口1230将使得用户能够通过外部设备或软件应用来设置首选项，且将通过除了通过无线通信网络之外的其它方式向UE1200提供信息或软件下载来扩展UE1200的能力。该备选下载路径可以例如用于通过直接且从而可靠并可信的连接将加密密钥加载到设备上，以由此使得安全设备通信成为可能。

备选地，串口1230可以用于其他通信，且可以包括通用串行总线（USB）端口。接口与串口1230相关联。

其他通信子系统1240（例如，短距通信子系统）是可以在UE1200和不同系统或设备（它们不一定是类似设备）之间提供通信的另一可选组件。例如，子系统1240可以包括红外设备和关联电路和组件或Bluetooth^TM通信模块，以提供与支持类似功能的系统和设备的通信。

现在参考图13。图13是包括UE1302的通信系统1300的框图，UE1302通过无线通信网络进行通信。

UE1302与多个接入点之一无线通信，例如UTRAN1320中的节点B1306。每个节点B1306负责空中接口处理和一些无线资源管理功能。节点B1306提供类似于GSM/GPRS网络中基础收发信站的功能。

图13的通信系统1300所示的无线链路表示一个或多个不同信道（通常是不同的射频（RF）信道）和相关联的在无线网络和UE1302之间使用的协议。在UE1302和节点B1306之间使用Uu空中接口1304。

RF信道是必须节省的有限资源，通常是由于整体带宽上的限制和UE1302的有限电池功率。本领域技术人员将意识到：取决于网络覆盖的所需整体扩展区域，无线网络在实际中可以包括上百个小区。所有相关网络组件可以通过多个交换机和路由器（未示出）来连接，由多个网络控制器来控制。

每个节点B1306与无线网络控制器（RNC）1310通信。RNC1310负责控制其区域内的无线资源。一个RNC1310控制多个节点B1306。

UMTS网络中的RNC1310提供了与GSM/GPRS网络中的基站控制器（BSC）功能等价的功能。然而，RNC1310包括更多的智能，包括例如在不涉及MSC和SGSN的情况下的自主切换管理。

在节点B1306和RNC1310之间使用的接口是Iub接口1308。主要使用NBAP（节点B应用部分）信令协议，如3GPP TS25.433V3.11.0（2002-09）和3GPP TS25.433V5.7.0（2004-01）中所定义。

通用陆地无线接入网（UTRAN）1320包括：RNC1310、节点B1306、Uu空中接口1304、以及Iub接口1308。

向移动交换中心（MSC）1330路由电路交换业务。MSC1330是进行呼叫、以及从订户或从PSTN（未示出）获取并接收数据的计算机。

在RNC1310和MSC1330之间的业务使用Iu-CS接口1328。Iu-CS接口1328是用于在UTRAN1320和核心语音网之间传输（通常）语音业务和信令的电路交换连接。使用的主信令协议是RANAP（无线接入网应用部分）。在核心网1321（其可以是MSC1330或SGSN1350（下面更详细定义））和UTRAN1320之间的UMTS信令中使用RANAP协议。RANAP协议在3GPP TS25.413V3.11.1（2002-09）和TS25.413V5.7.0（2004-01）中定义。

对于向网络运营商注册的所有UE1302，在归属位置寄存器（HLR）1338中存储永久数据（例如，UE1302用户的简档）以及临时数据（例如，UE1302当前位置）。在针对UE1302的语音呼叫的情况下，向HLR1338查询，以确定UE1302的当前位置。MSC1330的访客位置寄存器（VLR）负责一组位置区域，并存储当前在其负责区域中的那些移动台的数据。这包括永久移动台数据中已从HLR1338向VLR1336发送的用于更快接入的各部分。然而，MSC1330的VLR1336还可以指派和存储本地数据，例如临时标识。UE1302在系统接入时也由HLR1338来认证。

通过服务GPRS支持节点（SGSN）1350来路由分组数据。SGSN1350是GPRS/UMTS网络中在RNC和核心网之间的网关，且负责在其地理服务区域中传输来自和去往UE的数据分组。在RNC1310和SGSN1350之间使用Iu-PS接口1348，且Iu-PS接口1348是用于在UTRAN1320和核心数据网之间用于传输（通常）数据业务和信令的分组交换连接。使用的主信令协议是RANAP（上述）。

SGSN1350与网关GPRS支持节点（GGSN）1360通信。GGSN1360在UMTS/GPRS网络和其它网络（例如，互联网或私有网络）之间提供接口。GGSN1360通过Gi接口连接到公共数据网PDN1370。

本领域技术人员将意识到：无线网络可以连接到图13中未显式示出的其它系统，其可能包括其它网络。即使不存在交换的实际分组数据，网络也一般将至少持续发送一些寻呼和系统信息。尽管网络包含很多部分，这些部分齐心协力导致无线链路处的特定行为。

尽管本公开讨论了UMTS和其它3G系统，这不意味着是限制性的。本公开可以适用于第四代（4G）系统，例如长期演进（LTE）。

本文描述的实施例是具有与本申请的各技术的各元素相对应的元素的结构、系统或方法的示例。本书面描述可以使得本领域技术人员能够产生并使用具有备选元素的实施例，该备选元素同样对应于本申请的各技术的各元素。从而本申请的各技术的预期范围包括与本文描述的本申请的各技术并无不同的其它结构、系统或方法，且还包括与本文描述的本申请的各技术具有非实质差异的其它结构、系统或方法。

Claims (28)

1.一种在用户设备处用于建立电路交换呼叫的方法，所述用户设备处于小区前向接入信道CELL_FACH状态、小区寻呼信道CELL_PCH状态或UTRAN注册区域寻呼信道URA_PCH状态下，所述方法包括：

接收对电路交换呼叫待处理的指示；

向网络单元发送用于便于所述用户设备向小区专用信道CELL_DCH状态转移的消息；以及

建立所述电路交换呼叫。

2.根据权利要求1所述的方法，其中，所述消息是具有业务量指示符信息单元的小区更新消息，所述业务量指示符信息单元指示待处理的上行链路数据超过阈值。

3.根据权利要求2所述的方法，其中，不存在上行链路数据业务。

4.根据权利要求2所述的方法，其中，所述发送包括：检查所述网络单元是否使得所述用户设备向CELL_DCH状态转移，以及如果是，则发送不具有所述业务量指示符信息单元的小区更新。

5.根据权利要求2所述的方法，其中，如果所述网络单元支持快速转移，则所述方法还包括：存储关于所述网络单元支持快速转移的信息。

6.根据权利要求5所述的方法，其中，基于所述用户设备上的学习阶段来设置所存储的信息。

7.根据权利要求5所述的方法，其中，当无线设备重新激活或网络改变时，重置所存储的信息。

8.根据权利要求1所述的方法，其中，所述消息是无线资源控制连接请求RRCConnectionRequest消息。

9.根据权利要求8所述的方法，其中，所述RRCConnectionRequest消息包括对所述电路交换呼叫待处理的指示。

10.根据权利要求9所述的方法，其中，在所述发送前，所述用户设备拆除RRC连接。

11.根据权利要求8所述的方法，其中，所述发送包括：检查所述网络单元是否使得所述用户设备向CELL_DCH状态转移，以及如果是，则发送小区更新，而不是所述RRCConnectionRequest消息。

12.根据权利要求8所述的方法，其中，如果所述网络单元支持快速转移，则所述方法还包括：存储关于所述网络单元支持快速转移的信息。

13.根据权利要求11所述的方法，其中，基于所述用户设备上的学习阶段来设置所存储的信息。

14.根据权利要求12所述的方法，其中，当无线设备重新激活或网络改变时，重置所存储的信息。

15.一种被配置用于建立电路交换呼叫的用户设备，所述用户设备处于小区前向接入信道CELL_FACH状态、小区寻呼信道CELL_PCH状态或UTRAN注册区域寻呼信道URA_PCH状态下，所述用户设备包括：

处理器；以及

通信子系统，

其中，所述处理器和通信子系统协作以：

接收对电路交换呼叫待处理的指示；

向网络单元发送用于便于所述用户设备向CELL_DCH状态转移的消息；以及

建立所述电路交换呼叫。

16.根据权利要求15所述的用户设备，其中，所述消息是具有业务量指示符信息单元的小区更新消息，所述业务量指示符信息单元指示待处理的上行链路数据超过阈值。

17.根据权利要求16所述的用户设备，其中，不存在上行链路数据业务。

18.根据权利要求16所述的用户设备，其中，所述发送包括：检查所述网络单元是否使得所述用户设备向CELL_DCH状态转移，以及如果是，则发送不具有所述业务量指示符信息单元的小区更新。

19.根据权利要求16所述的用户设备，其中，如果所述网络单元支持快速转移，则所述处理器和通信子系统还协作以：存储关于所述网络单元支持快速转移的信息。

20.根据权利要求19所述的用户设备，其中，基于所述用户设备上的学习阶段来设置所存储的信息。

21.根据权利要求19所述的用户设备，其中，当无线设备重新激活或网络改变时，重置所存储的信息。

22.根据权利要求16所述的用户设备，其中，所述消息是无线资源控制连接请求RRCConnectionRequest消息。

23.根据权利要求22所述的用户设备，其中，所述RRCConnectionRequest消息包括对所述电路交换呼叫待处理的指示。

24.根据权利要求23所述的用户设备，其中，在所述发送前，所述用户设备拆除RRC连接。

25.根据权利要求22所述的用户设备，其中，所述发送包括：检查所述网络单元是否使得所述用户设备向CELL_DCH状态转移，以及如果是，则发送小区更新，而不是所述RRCConnectionRequest消息。

26.根据权利要求22所述的用户设备，其中，如果所述网络单元支持快速转移，所述处理器和通信子系统还协作以：存储关于所述网络单元支持快速转移的信息。

27.根据权利要求26所述的用户设备，其中，基于所述用户设备上的学习阶段来设置所存储的信息。

28.根据权利要求26所述的用户设备，其中，当无线设备重新激活或网络改变时，重置所存储的信息。

Images