CN102783242A

CN102783242A - 基于sri消息传输的状态或模式转换触发

Info

Publication number: CN102783242A
Application number: CN201080062345XA
Authority: CN
Inventors: 约翰娜·丽莎·德怀尔; 保罗·卡澎特
Original assignee: Research in Motion Ltd
Current assignee: BlackBerry Ltd
Priority date: 2009-11-23
Filing date: 2010-10-05
Publication date: 2012-11-14
Also published as: KR101417550B1; JP2013511873A; US9119208B2; JP5525621B2; HUE049498T2; CN107018579B; KR20120096548A; AU2010321205A1; BR112012012351A2; US9144104B2; EP2505034A1; AU2010321205B2; MX2012005868A; US20120014326A1; WO2011060998A1; ES2805149T3; JP2014143752A; CN107018579A; BR112012012351B1; EP2505034B1

Abstract

一种用户设备UE，实现处理(产生)指示消息的方法，指示消息例如SCRI(信令连接释放指示)消息，以触发如Cell_PCH、URA_PCH或Cell_FACH的状态之间的转换。如果高层指示长期不再有分组交换数据，例如在特定时间段内UE与网络之间没有数据交换，特定时间段通常使用“禁止定时器”来估计，然后如果在至少一个RRC(无线资源控制)状态下已经触发(即发送)了多少指示消息(即SCRI消息)的计数小于最大数目，则UE递增该计数，并将原因设置到指示消息(即“UE请求的PS数据会话结束”)中，以及发送指示消息(即SCRI)。

Description

基于SRI消息传输的状态或模式转换触发

相关申请的交叉引用

本申请要求于2009年11月23日递交的美国临时专利申请NO.61/263,818的优先权，在此通过引用的方式将其整体并入。

技术领域

本公开涉及用户设备(UE)或其他的无线或移动设备与无线网络之间的无线资源控制，以及具体地，涉及无线网络(例如，通用移动电信系统(UMTS)网络)中的操作状态和模式之间的转换。

背景技术

通用移动电信系统(UMTS)是用于传输文本、数字语音、视频和多媒体的宽带的基于分组的系统。其高度支持第三代移动通信的标准，并一般而言基于宽带码分多址接入(W-CDMA)。

在UMTS网络中，协议栈的无线资源控制(RRC)部分负责UE和UTRAN之间的无线资源的分配、配置和释放。在3GPP TS 25.331规范中对该RRC协议进行了详细描述。将UE可以处于的两个基本模式定义为“空闲模式”和“UTRA RRC连接模式”(或者如此处所使用的，简称为“连接模式”)。UTRA代表UMTS陆地无线接入。在空闲模式下，要求UE或其他移动设备只要想要发送任何的用户数据，或者响应于只要UTRAN或服务通用分组无线业务(GPRS)支持节点(SGSN)向其寻呼以从例如推送服务器的外部数据网络接收数据的寻呼，都要请求RRC连接。在第三代伙伴计划(3GPP)规范TS 25.304和TS 25.331中详细描述了空闲模式和连接模式行为。

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

在该状态下，在上行链路和下行链路中向UE分配专用信道以用于交换数据。UE必须执行在3GPP TS 25.331中描述的动作。

在该状态下不向用户设备分配专用信道。取而代之，使用公共信道来交换少量的突发数据(bursty data)。UE必须执行在3GPP TS 25.331中描述的动作，包括在3GPP TS 25.304中定义的小区选择过程。

UE使用断续接收(DRX)来经由寻呼指示符信道(PICH)监视广播消息和寻呼。不可能有上行链路活动。UE必须执行在3GPP TS 25.331中描述的动作，包括在3GPP TS 25.304中定义的小区选择过程。UE必须执行小区重选之后的小区更新过程。

UE使用断续接收(DRX)来经由寻呼指示符信道(PICH)监视广播消息和寻呼。不可能有上行链路活动。UE必须执行在3GPP TS 25.331中描述的动作，包括在3GPP TS 25.304中定义的小区选择过程。除了仅经由UTRAN注册区(URA)重选来触发URA更新过程之外，该状态与CELL_PCH类似。

由UTRAN来控制从空闲模式到连接模式或反之的转换。当空闲模式UE请求RRC连接时，网络决定是否将UE移动到CELL_DCH或CELL_FACH状态。当UE处于RRC连接模式时，再次地，网络决定何时释放RRC连接。在释放连接之前，或者在一些情况下替代释放连接，网络还可以将UE从一个RRC状态移动到另一RRC状态。通常由UE和网络之间的数据活动或不活动来触发状态转换。由于对于给定的应用，网络可能不知道UE何时已经完成了数据交换，通常预期更多的数据去往/来自UE，将RRC连接保持一些时间。通常这样做来降低呼叫建立和后续的无线资源建立的延迟。仅可以由UTRAN来发送RRC连接释放消息。该消息释放UE和UTRAN之间的信号链路连接和所有的无线资源。一般而言，术语“无线承载”指代在UE和UTRAN之间分配的无线资源。以及，术语“无线接入承载”一般指代在UE和例如SGSN(服务GPRS服务节点)之间分配的无线资源。本公开将会不时地提及术语“无线资源”，该术语应该根据需要指代无线承载和/或无线接入承载中的任一个或其两者。

以上的问题是：即使UE上的应用已经完成其数据事务并且不预期任何的其他数据交换，其仍然等待网络将其移动至正确的状态。网络可能甚至不知道UE上的应用已经完成其数据交换的事实。例如，UE上的应用可以使用其基于应答的协议来与其应用服务器交换数据，该应用服务器是通过UMTS核心网来接入的。示例是在用户数据报协议/互联网协议(UDP/IP)上运行的应用实现其自己的有保证的传送。在这种情况下，UE知道应用服务器是否已经发送或接收了所有数据分组，并能够更好地确定是否发生任何其他的数据交换并因此决定何时终止与分组服务(PS)域相关联的RRC连接。由于UTRAN控制何时将RRC连接状态改变到不同的状态或空闲模式，以及UTRAN不知道UE和外部服务器之间的数据传送的状态，UE可以被强制停留在比所要求的更高的数据速率状态或模式，很可能导致移动台的电池寿命降低，还很可能由于没有必要地保持占据无线资源并从而使其对另一用户不可用的事实，导致浪费网络资源。

对以上问题的一个解决方案是当UE认识到其完成数据事务时，该UE向UTRAN发送信令释放指示。根据3GPP TS 25.331规范的8.1.14.3节，UTRAN可以在接收到来自UE的信令释放指示时释放信令连接，使得UE转换到空闲模式或其他一些RRC状态。以上解决方案的问题是UTRAN可能变得被来自该UE和其他UE的信令释放指示消息所淹没。

发明内容

根据本申请的一个方面，提供了由用户设备处理指示消息的方法，该方法包括：在用户设备处：如果高层指示长期不再有PS数据；以及如果在至少一个RRC状态下已经触发了多少指示消息的计数小于最大数目，则：递增在至少一个RRC状态下已经触发了多少指示消息的计数；在指示消息中设置原因；以及发送指示消息。

根据本申请的另一方面，提供了一种用户设备，被配置为处理指示消息，该用户设备被配置为：如果高层指示长期不再有PS数据；以及如果在至少一个RRC状态下已经触发了多少指示消息的计数小于最大数目，则：递增在至少一个RRC状态下已经触发了多少指示消息的计数；在指示消息中设置原因；以及发送指示消息。

附图说明

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

图1是示出RRC状态和转换的方框图；

图2是示出各种UMTS小区和URA的UMTS网络的示意；

图3是示出RRC连接建立中的各个阶段的方框图；

图4A是根据当前的方法，由UTRAN发起的CELL_DCH连接模式状态与空闲模式之间的示例性转换的方框图；

图4B是示出使用信令释放指示，CELL_DCH状态连接模式转换到空闲模式之间的示例性转换的方框图；

图5A是由UTRAN发起的在CELL_DCH不活动状态到CELL_FACH不活动状态再到空闲模式之间的示例性转换的方框图；

图5B是示出使用信令释放指示，CELL_DCH不活动状态与空闲模式之间的示例性转换的方框图；

图6是UMTS协议栈的方框图；

图7是可以与本方法相关联地使用的示例性UE；

图8是与本方法和系统相关联地使用的示例性网络；

图9是示出在UE处增加信令连接释放指示的原因的步骤的流程图；

图10是示出UE在接收到具有原因的信令连接释放指示时所采取的步骤的流程图；

图11示出了在图8中示出的网络的示例性操作期间，示例性逻辑和物理信道分配的图形表示，在图8中，向UE提供多个并发的分组数据通信服务会话；

图12示出了根据本公开的实施例，提供释放各个分组数据服务的无线资源的无线资源释放功能的UE和网络单元的功能框图；

图13示出了表示根据本公开的实施例的操作而产生的信令的消息序列图，通过该操作，释放对PDP上下文的无线资源分配；

图14示出了也表示根据本公开的实施例的操作而产生的信令的消息序列图，通过该操作来释放无线资源分配，该消息序列图与图13中示出的消息序列图相似；

图15示出了表示本公开的实施例的过程的过程图(processdiagram)；

图16示出了示意本公开的实施例的操作方法的方法流程图；

图17示出了也示意本公开的实施例的操作方法的方法流程图；

图18示出了实施例的方法流程图，在该实施例中，基于网络单元处的无线资源简档来做出转换决定；

图19示出了能够在图18的方法中使用网络单元的简化框图；

图20示出了用于发送转换指示或请求消息的数据流程图；以及

图21示出了在UE处用于设置禁止定时器值的数据流程图。

具体实施方式

下面提供的示例和实施例描述了用于将用户设备(UE)或其他移动设备在无线网络(例如，如UMTS网络)中的各种操作状态/模式之间进行转换的各种方法和系统。应该理解，其他类型的网络中的其他实现也是可能的。例如，也可以将相同的技术应用与码分多址接入(CDMA)网络(例如，3GPP2IS-2000)、宽带CDMA(W-CDMA)网络(例如，3GPP UMTS/高速分组接入(HSPA)网络)、演进的UTRAN网络(例如，LTE)，或者广义地应用与基于以下无线接入技术的任何网络：该无线接入技术使用网络控制的无线资源或者不维持对设备应用级数据交换的状态的任何知识。以下描述的虽然为了简洁而关于UMTS网络来描述的特定示例和实现也可以应用与这些其他的网络环境。此外，下面有时将网络单元描述为UTRAN。然而，如果使用了除UMTS以外的其他网络类型，可以基于该网络类型来适当地选择网络单元。此外，网络单元可以是UMTS系统或任何其他适当的网络系统中的核心网，其中，网络单元是做出转换决定的实体。

在具体的示例中，本系统和方法提供了从RRC连接模式到更具电池效率或无线资源效率的状态或模式的转换，同时在网络处提供了做出决定的能力。具体地，本发明和装置提供了基于接收到来自UE的指示的转换，该指示(隐式地或显式地)指示了应该发生和与无线资源的特定信令连接相关联的RRC状态或模式到另一状态或模式的转换。应该意识到，这种转换指示或请求可以使用当前标准下的现有通信(例如，信令连接释放指示消息)，或者可以是改变UE的状态的新的专用消息，例如“优选RRC状态请求”或“数据传送完成指示消息”。数据传送完成指示消息是指示高层数据传送完成的消息。在此使用的指示可以指代任一场景，并且可以并入请求。

在一些情况下，当UE上的一个或多个应用已经完成了数据交换和/或当确定UE应用不预期交换任何其他数据时，可以发送源自于UE的转换指示。然后，网络单元可以使用该指示和其中提供的任何信息以及在此定义为无线资源简档的与无线资源有关的其他信息(例如服务质量、接入点名称(APN)、分组数据协议(PDP)上下文、历史信息等等)，来做出关于是将移动设备转换到另一模式或状态，还是什么都不做的网络特有的决定。UE或移动设备提供的转换指示可以采用多种形式，并且可以在不同的条件下发送。在第一示例中，可以基于驻留在UE上的所有应用的复合状态来发送转换指示。具体地，在UMTS环境下，如果UE上的应用确定其完成了数据交换，可以向UE软件的“连接管理器”组件发送“完成”指示。在一个实施例中，连接管理器可以跟踪所有现有的应用(包括基于一个或多个协议来提供服务的应用)、相关的分组数据协议(PDP)上下文、相关的分组交换(PS)无线资源以及相关的电路交换(CS)无线资源。PDP上下文是UE和跨越UMTS核心网运行的PDN(公共数据网络)之间的逻辑关联。可以将UE上的一个或多个应用(例如，电子邮件应用和浏览器应用)与一个PDP上下文相关联。在一些情况下，UE上的一个应用与一个主PDP上下文相关联，以及可以将多个应用与辅助PDP上下文捆绑。连接管理器从UE上同时活动的不同应用接收“完成”指示。例如，用户可以从推送服务器接收电子邮件，同时浏览网页。在电子邮件应用已经发送应答之后，其可以指示它已经完成了它的数据事务。浏览器应用可以表现得不同，并代之以对何时向连接管理器发送“完成”指示进行预测性的确定(例如，使用不活动定时器)。

基于来自活动应用的这种指示的复合状态，UE软件可以决定发送转换指示，该转换指示向网络指示或请求应该发生从一个状态或模式到另一个状态或模式的转换。备选地，UE软件可以代之以在其发送转换指示之前等待，并引入延迟来确保应用真正完成了数据交换，并且不需要维持在高度需要电池或无线资源的状态或模式下。基于业务历史和/或应用简档，延迟可以是动态的。只要连接管理器以一定的概率确定没有应用预期交换数据，其都可以向网络发送转换指示来指示应该发生转换。在特定的示例中，转换指示可以是针对适当的域(例如，PS域)的请求转换到空闲模式的信令连接释放指示。备选地，转换指示可以是向UTRAN请求连接模式内的状态转换的请求。

如下面将更详细地描述的，基于接收到转换指示和可选的无线资源简档，网络单元(例如，UMTS环境下的UTRAN)可以决定将UE从一个状态或模式转换到另一状态或模式。

其他转换指示是可能的。例如，替代依靠UE上的所有活动应用的复合状态，在备选的实施例中，UE软件可以在每次UE应用已完成数据交换和/或该应用不预期交换其他数据时发送转换指示。在该情况下，基于下面参考图18描述的UE的可选无线资源简档，网络单元(例如，UTRAN)可以使用该指示来做出转换决定。

在又一示例中，转换指示可以简单地指示UE上的一个或多个应用完成数据交换和/或UE应用不预期交换任何其他数据。基于该指示以及UE的可选的无线资源简档，网络(例如，UTRAN)可以决定是否将UE转换到更适当的状态或模式或操作。

在其他示例中，转换指示可以是隐式的，而不是显式的。例如，指示可以是周期性发送的状态报告的一部分。这种状态报告可以包括例如无线链路缓存是否有数据的信息或者可以包括关于输出业务的信息。

当UE发送转换指示时，其可以包括附加信息，以协助网络单元做出基于指示进行动作的决定。该附加信息可以包括UE发送该消息的理由或原因。该原因或理由(下面更详细地解释)可以基于UE确定需要类似“快速休眠”的行为。这种附加信息可以是转换指示消息中的新信息单元或新参数的形式。

在另一实施例中，在UE上可以存在定时器，以确保可以不发送转换指示，直到从发送先前的转换指示开始过去一段时间(禁止持续时间)。该禁止定时器限制UE太过频繁地发送转换指示消息，以及还允许网络通过依靠仅以给定的最大频率触发的消息来做出确定。可以通过值预先配置或者由网络来设置(指示或信号通知)的定时器确定该持续时间。如果由网络来设置该值，可以在新的或者现有的消息(例如，RRC连接请求、RRC连接释放、无线承载建立、UTRAN移动性信息或者系统信息块等等)中对其进行传送，以及可以是这些消息中的信息单元。例如，备选地，可以在UTRAN响应于从UE接收到的RRC连接请求消息而发送的RRC连接建立消息的禁止转换指示部分中传送该值。

在备选实施例中，可以在类型取决于UE状态的消息中向UE传送该值。例如，网络可以将该值作为系统信息消息的一部分向小区中的所有UE发送，该系统信息消息是在UE处于空闲、URA_PCH、Cell_PCH或CELL_FACH状态时由UE读取的。

在又一实施例中，可以将该值作为RRC连接建立消息的一部分发送。

网络产生的消息还可以通过不将禁止定时器包括在消息中或者消息内的信息单元中，来传送隐式的禁止定时器值。例如，在确定从接收到的消息中省略了禁止定时器时，UE应用预定值来作为禁止定时器值使用。禁止定时器值省略的一个示例性使用是禁止UE发送转换指示消息。在这种情况下，当UE检测到接收到的消息中对所预期的禁止定时器值的省略时，可以基于该省略来禁止UE发送任何的转换指示消息。对此实现的一种方式是UE采用无穷大的禁止定时器值。

在另一实施例中，当UE检测到禁止定时器值的省略(以及，例如采用无穷大的禁止定时器值)时，UE可以发送转换指示，然而不包括任何的附加信息，具体地，UE可以省略触发发送转换指示的原因(下面将进一步更详细地描述)。转换指示消息中原因单元的省略可以确保通过允许UE使用请求或指示转换的现有转换指示消息(例如，信令连接释放指示)来进行后向兼容。

进一步参考示例性实施例来详细描述不将禁止定时器包括在接收到的消息中的情况，其中，在小区中广播或者向UE发送系统信息块，以及将系统信息块配置为传送禁止定时器值。在本实施例中，如果UE接收到不在消息或消息内的信息单元中包含禁止定时器(已知为T3xx)的系统信息块，在这种情况下，UE可以确定不使UE发送转换指示消息，例如，通过将禁止定时器T3xx设置为无穷大来进行。

还参考另一示例性实施例来详细描述不包括禁止定时器的情况，其中，从UTRAN移动性信息消息省略禁止定时器T3xx。在这种情况下，接收方UE可以继续应用先前存储的禁止定时器值。备选地，在检测到禁止定时器T3xx的省略时，UE可以确定不使UE发送转换指示消息，例如，通过将禁止定时器T3xx设置为无穷大来进行。

在又一示例性实施例中，UE在检测到接收的消息或消息内的信息单元中省略了禁止定时器时，将禁止定时器值设置为另一预设值(例如，0秒、5秒、10秒、15秒、20秒、30秒、1分钟、1分30秒、2分钟中的一个)。备选地或者附加地，这些示例可以应用于其他网络产生的消息。

在其他实施例中，如果没有在消息或信息单元中向UE发送或信号通知禁止定时器(值)，或者没有从广播系统信息读取或者从与一个小区到另一个小区的转换有关的其他专用UTRAN消息接收到禁止定时器，可以发生也可以不发生转换指示的发送。

具体地，在一个实施例中，UE在检测到不存在禁止定时器时，不基于高层确定不再有PS数据要发送来发起转换指示。

在备选实施例中，UE在检测到不存在禁止定时器时，可以基于高层确定不再有PS数据要发送来发起转换指示。

在又一实施例中，如果在消息内或者消息中的信息单元内没有从UTRAN接收到定时器值(经由广播或其他方式)，不将UE处的定时器值设置为无穷大，而是UE可以将禁止定时器设置为零，或者备选地，删除定时器的任何配置，并代之允许发送转换指示。在该情况下，UE可以省略或者禁止将原因附着到转换指示消息中。在一个实施例中，使用信令连接释放指示消息来作为转换指示的一个示例。

在一个实施例中，使用信令连接释放指示过程来传送转换指示。UE使用信令连接释放指示过程来指示UTRAN其信令连接中的一条已被释放。

具体地，根据TS 25.331的8.1.14.2节，UE应该在从特定CN域的高层接收到释放信令连接的请求时，检查在信息单元“CN域标识”中标识的特定CN域的变量“ESTABLISHED_SIGNALLING_CONNECTIONS”中的信令连接是否存在。如果存在，UE可以发起信令连接释放指示过程。

在没有向UE信号通知或者以其他方式传送禁止定时器值的情况下，在信令连接释放指示消息中不指定信令连接释放指示原因。本领域技术人员将意识到，在本备选实施例中，缺少定时器值不会导致定时器值被设置为无穷大。

在UTRAN侧，在接收到没有原因的信令连接释放指示消息时，UTRAN向高层指示针对所标识的CN域标识的信令连接释放。然后，这可以发起对已建立的无线资源控制连接的释放。

在另一备选实施例下，当UTRAN向UE信号通知或传送定时器值(例如，信息单元“连接模式下的UE定时器和常数”中的禁止定时器T3xx)(或者使用系统信息，如SIB1、SIB3或SIB4，或者利用专用的UTRAN移动性信息消息)时，根据以下方式来发生释放过程。首先，UE可以检查是否存在所指示的任何电路交换域连接。可以在变量“ESTABLISHED_SIGNALLING_CONNECTIONS”中指示这种连接。如果没有电路交换域连接，可以发生第二检查，以确定高层是否指示将长时间不存在分组交换域数据。

如果不存在电路交换域连接，以及预期长时间不存在分组交换域数据，UE可以接下来检查定时器T3xx是否正在运行。

如果定时器T3xx没有在运行，UE向分组交换(PS)域设置信息单元“CN域标识”。此外，信息单元“信令连接释放指示原因”被设置为“UE请求的PS数据会话结束”。使用AM RLC在DCCH上发送信令连接释放指示消息。此外，在发送之后启动定时器T3xx。

在成功传送信令连接释放指示消息(在以上过程中，由RLC来确认)时，结束以上过程。在本实施例中，当定时器T3xx正在运行时或者直到定时器T3xx已经到期之前，禁止UE发送具有被设置为“UE请求的PS数据会话结束”的信令连接释放指示原因的信令连接释放指示消息。

当T3xx定时器正在运行时，如果由于长时间没有其他的分组交换域数据而发起信令连接释放指示过程，UE负责实现是否在T3xx定时器到期时发起该过程。UE的决定可以基于确定其是否有任何的后续信令连接释放指示或请求消息要发送，以及如果有，UE的决定可以包括对用于发起在此描述的过程的一些或全部的相同检查进行重新检查。

在UTRAN侧，如果接收到的信令连接释放指示消息不包括信令连接释放指示原因，UTRAN可以从高层请求释放信令连接，以及高层从而可以发起信令连接的释放。如果另一方面，接收到的信令连接释放指示消息包括原因，UTRAN可以释放信令连接或发起至更具有电池效率的状态(例如，CELL_FACH、CELL_PCH、URA_PCH或IDLE_MODE)的转换。

以上的禁止持续时间可以基于UE想要转换到的状态。例如，移动设备是否指示其相对于其他RRC状态/模式对一些RRC状态/模式的最新偏好，禁止持续时间可以不同。例如，如果移动设备指示相对于Cell_FACH或相对于Cell_PCH/URA_PCH状态对空闲模式的偏好，禁止持续时间可以不同。在由网络来设置禁止持续时间的情况下，通过网络向移动设备指示/发送值的两个(或更多)集合来对此进行实现，该值的两个(或更多)集合取决于场景来使用。备选地，可以通过仅向移动设备指示/信号通知适当的禁止持续时间值的方式来进行指示：例如，如果UE想要转换到Cell_PCH，与如果UE想要转换到空闲模式相比，可以设置不同的经过持续时间。

取决于移动设备当前处于哪种RRC状态/模式(例如，Cell_DCH/Cell_FACH对Cell_PCH/URA_PCH，或者Cell_DCH对Cell_FACH，或者Cell_PCH/URA_PCH)，从以上而来的禁止持续时间可以不同。

取决于网络是否已经对来自移动设备的偏好RRC状态信息进行动作，来自以上的禁止持续时间可以不同。这种识别可以发生在网络上，或者发生在移动设备侧。在第一种情况下，这可以影响到网络向移动设备指示/信号通知的禁止值。在该第二种情况下，可以由网络预先配置或指示/信号通知禁止持续时间值的不同集合。作为具体情况，如果网络已经对来自移动设备的偏好RRC状态信息进行了动作，例如，已经发起了至UE所指示的状态的状态转换，可以减少或取消禁止持续时间/功能。

取决于例如网络的偏好、特征、能力、负荷或容量，来自以上的禁止持续时间可以不同。如果网络能够接收频繁的转换指示消息，其可以指示短的禁止持续时间。如果网络不能够或者不想接收频繁的转换指示消息，其可以指示长的禁止持续时间。网络可以指示UE不能发送转换指示消息的特定时间段。例如，可以通过数值方式指示特定时间段(即，0秒、30秒、1分钟、1分30秒、2分钟或者无穷大)。接收到0秒的禁止持续时间的UE能够没有延迟地发送转换指示。接收到无穷大的禁止持续时间的UE不能够发送转换指示。

替代禁止持续时间，或者除了禁止持续时间之外，可以使用/指定每时间窗口的消息的最大数目(例如，“每10分钟不超过15条消息”)。

以上的禁止持续时间/每时间窗口最大消息的组合是可能的。

通过示例的方式，本公开一般性地描述了UTRAN对来自UE的RRC连接请求消息的接收。在接收到RRC连接请求消息时，UTRAN应该例如接受该请求，并向UE发送RRC连接建立消息。RRC连接建立消息可以包括禁止转换指示，已知是定时器T3xx。在UE接收到RRC连接建立消息时，UE应该例如存储定时器T3xx的值，替换任何先前存储的值，或者如果定时器T3xx不在RRC连接建立消息中，则将定时器的值设置为无穷大。在一些实施例中，RRC连接建立消息必须包括禁止转换指示，以确保UE知道UTRAN支持禁止转换指示信令。

在一个实施例中，假设在DCH状态下的移动期间，UE将维持其当前存储的禁止定时器的值。在将禁止定时器设置为无穷大的一些情况下，这可以意味着UE必须等待网络数据不活动定时器到期，以及等待网络将该UE移动到其可以接收或确定禁止定时器的新值的RRC状态。当在切换之前禁止定时器是除无穷大之外的其他值的情况下，持续使用该其他值，直到UE能够将定时器值更新为在新的小区中指示的定时器值。

在一些实例中，在一些网络或者在网络内的一些小区中可以不实现禁止定时器和转换指示(例如，信令连接释放指示)消息。出于移动性的目的，如果不存在对发送转换指示或请求消息的特征的可用支持(尤其在使用了原因的情况下)，UE应该缺省不发送该消息。这避免了不必要的发送以及网络资源和电池资源的相关浪费。

此外，出于移动性的目的，网络内使用的不同厂商的网络设备可导致相邻小区使用不同的禁止定时器，当UE在小区间移动时，需要在UE上进行更新定时器值。

在一个备选实施例中，通过假设所有的切换和相关承载控制消息包括禁止定时器T3xx的值来处理上述情况。在此，将这种消息称为移动性消息。这允许UE在小区间移动时接收新的禁止定时器值。这也允许在这些移动性消息之一不包含禁止定时器值的情况下，UE设置禁止定时器的缺省定时器值。将会意识到，如果在移动性消息中没有接收到禁止定时器值，这指示了该小区不能用于快速休眠。

作为转换指示过程的另一示例，UE可以使用数据传送完成指示过程来向UTRAN指示其已经确定不需要传送任何的更多PS域数据。与上述示例相结合，如果定时器T3xx在运行，UE在定时器T3xx到期之前不能发送数据传送完成指示消息。

数据传送完成指示过程从如下指示开始：RRC或高层将长时间不再有PS域数据。如果在变量ESTABLISHED_SIGNALLING_CONNECTIONS中指示了CS域连接或者如果定时器T3xx被设置为无穷大，过程结束。否则，如果定时器T3xx没有在运行(即，已到期)或者被设置为0秒，向低层提交数据传送完成指示消息，以DCCH上使用AM RLC来传输，在此之后，当已经向低层传送了消息时，启动或复位定时器T3xx。

UTRAN在接收到数据传送完成指示时可以决定发起UE转换到更具电池效率的RRC状态或空闲状态。

当定时器T3xx正在运行时，UE不应该发送数据传送完成指示消息。

本公开提供了控制用户设备使用转换指示消息的方法，包括：将禁止转换指示包括在配置消息中；以及向用户设备发送具有禁止转换指示的配置消息。

本公开还提供了被配置为控制用户设备使用转换指示消息的网络单元，该网络单元被配置为：将禁止转换指示包括在配置消息中；以及向用户设备发送具有禁止转换指示的配置消息。

本公开还提供了用户设备(UE)处用于发送转换指示的方法，该方法包括：根据从网络单元接收到的禁止转换指示来设置定时器；检测数据传送完成；以及在检测到定时器不在运行时发送转换指示。

本公开还提供被配置为发送转换指示的用户设备，该用户设备被配置为：根据从网络单元接收到的禁止转换指示来设置定时器；检测数据传送完成；以及在检测到定时器不在运行时发送转换指示。

现在参考图1。图1是示出UMTS网络中协议栈的无线资源控制部分的各种模式和状态的方框图。具体地，RRC可以处于RRC空闲模式110或RRC连接模式120。

本领域技术人员将意识到，UMTS网络由两个陆基网络段组成。它们是核心网(CN)和通用陆地无线接入网(UTRAN)(如图8中示出的)。核心网负责向外部网络交换和路由数据呼叫和数据连接，而UTRAN处理所有的无线相关功能。

在空闲模式110下，只要需要在UE和网络之间交换数据，UE都必须请求RRC连接来建立无线资源。这可以是UE上的应用需要连接来发送数据的结果，或者是UE监视寻呼信道来指示UTRAN或SGSN是否已寻呼UE以从外部网络(例如，推送服务器)接收数据的结果。此外，只要UE需要发送移动性管理信令消息(例如，位置区更新)，UE也请求RRC连接。

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

UE从空闲模式110自主转换到CELL_FACH状态124，在CELL_FACH状态124中，UE进行其初始的数据传送，在这之后，网络确定使用哪个RRC连接状态来用于继续的数据传送。这可以包括网络将UE移动到小区专用信道(CELL_DCH)状态122或者将UE保持在小区前向接入信道(CELL_FACH)状态124。

在CELL_DCH状态122中，向UE分配用于上行链路和下行链路以交换数据的专用信道。由于具有向UE分配的专用物理信道，该状态通常需要来自UE的最多的电池功率。

备选地，UTRAN可以将UE维持在CELL_FACH状态124。在CELL_FACH状态下，不向UE分配专用信道。取而代之，使用公共信道来以少量的突发数据(bursty data)发送信令。然而，UE仍然必须持续监视PACH，并因此与CELL_PCH状态、URA_PCH状态和空闲模式相比，其消耗了更多的电池功率。

在RRC连接模式120中，RRC状态可以根据UTRAN的判断而改变。具体地，如果检测到数据不活动达特定的时间量，或者检测到数据吞吐量低于特定的阈值，UTRAN可以将RRC状态从CELL_DCH状态122移动到CELL_FACH状态124、CELL_PCH状态126和URA_PCH状态128。类似地，如果检测到净荷高于特定的阈值，则可以将RRC状态从CELL_FACH状态124移动到CELL_DCH状态122。

从CELL_FACH状态124，在一些网络中如果检测到数据不活动达预定的时间，UTRAN可以将RRC状态从CELL_FACH状态124移动到寻呼信道(PCH)状态。该状态可以是CELL_PCH状态126或URA_PCH状态128。

从CELL_PCH状态126或URA_PCH状态128，为了发起请求专用信道的更新过程，UE必须移动到CELL_FACH状态124。这是UE控制的唯一状态转换。

空闲模式110以及CELL_PCH状态126和URA_PCH状态128使用断续接收循环(DRX)来监视广播消息，并通过寻呼指示符信道(PICH)进行寻呼。不可能有上行链路活动。

CELL_PCH状态126和URA_PCH状态128之间的区别在于：如果UE的当前UTRAN注册区(URA)不在当前小区中存在的URA标识的列表中，URA_PCH状态128仅触发URA更新过程。具体地，参考图2。图2示出了各种UMTS小区210、212和214的示意。如果重选到CELL_PCH状态，所有这些小区需要小区更新过程。然而，在UTRAN注册区中，每个都将在相同的UTRAN注册区(URA)320内，并因此当处于URA_PCH模式下时，当在210、212和214之间移动时不触发URA更新过程。

如图2中可见的，其他小区218在URA 320外部，并可以成为单独的URA的一部分，或者没有URA。

本领域技术人员应该意识到，从电池寿命的角度来看，空闲模式与以上状态相比提供了最低的电池使用。具体地，因为UE仅需要定期监视寻呼信道，无线装置不需要持续开启，而是将代之以周期性唤醒。与电池寿命折衷的是发送数据的延迟。然而，如果该延迟不是太大，处于空闲模式并节省电池功率的好处超过了连接延迟的坏处。

再次参考图1。各种UMTS基础结构厂商基于各种标准在状态122、124、126和128之间移动。这些标准可以是网络运营商关于节省信令或节省无线资源的偏好等等。下面描述示例性的基础结构。

在第一示例性基础结构中，紧接在CELL_FACH状态下发起接入之后，RRC在空闲模式和Cell_DCH状态之间移动。在Cell_DCH状态下，如果检测到两秒的不活动，RRC状态改变到Cell_FACH状态124。如果在Cell_FACH状态124下，检测到10秒的不活动，则RRC状态改变到Cell_PCH状态126。Cell_PCH状态126下45分钟的不活动将导致RRC状态移动回到空闲模式110。

在第二示例性基础结构中，取决于有效载荷阈值，可以在空闲模式110和连接模式120之间发生RRC转换。在第二基础结构中，如果有效载荷低于特定阈值，则UTRAN将RRC状态移动到CELL_FACH状态124。相反，如果数据有效载荷高于特定有效载荷阈值，则UTRAN将RRC状态移动到CELL_DCH状态122。在第二基础结构中，如果在CELL_DCH状态122下检测到两分钟的不活动，UTRAN将RRC状态移动到CELL_FACH状态124。在CELL_FACH状态124下的5分钟的不活动之后，UTRAN将RRC状态移动到CELL_PCH状态126。在CELL_PCH状态126下，在移动回空闲模式110之前要求两个小时的不活动。

在第三示例性基础结构中，空闲模式110与连接模式120之间的移动总是到CELL_DCH状态122。在CELL_DCH状态122下的5秒的不活动之后，UTRAN将RRC连接移动到CELL_FACH状态124。CELL_FACH状态124下不活动30秒导致移动回空闲模式110。

在第四示例性基础结构中，从空闲模式到连接模式的RRC转换直接进入到CELL_DCH状态122。在第四示例性基础结构中，CELL_DCH状态122包括两个配置。第一配置包括具有高数据速率的配置，以及第二配置包括较低数据速率，然而仍然在CELL_DCH状态下。在第四示例性基础结构中，从空闲模式110的RRC转换直接进入高数据速率CELL_DCH子状态。在10秒的不活动之后，RRC状态转换到低数据速率CELL_DCH子状态。从CELL_DCH状态122的低数据子状态起17秒的不活动导致RRC状态将其改变为空闲模式110。

以上的四个示例性基础结构示出了各种UMTS基础结构厂商如何实现状态。本领域技术人员将意识到，在每种情况下，如果与所需停留在CELL_DCH或CELL_FACH状态下的时间相比，花在交换实际数据(例如，电子邮件)上的时间显著要短。这导致没有必要的电流汲取，使得用户在较新代的网络(例如，UMTS)中比在之前代的网络(例如，GPRS)中体验更差。

此外，虽然从电池寿命的角度看，CELL_PCH状态126比CELL_FACH状态124更优，与空闲模式110相比，通常将CELL_PCH状态126下的DRX循环设置为较低的值。因此，与在空闲模式110中相比，在CELL_PCH状态126下，需要UE更频繁地唤醒。

具有与空闲状态110的DRX循环相似的DRX循环的URA_PCH状态128很可能是电池寿命和连接的延迟之间的最优折衷。然而，当前在UTRAN中没有实现URA_PCH状态128。在一些情况下，从电池寿命的角度看，因此期望在应用完成数据交换之后尽可能快地快速转换到空闲模式。

现在参考图3。当从空闲模式转换到连接模式时，需要进行各种信令和数据连接。参考图3，要执行的第一项是RRC连接建立310。如上指示的，仅可以由UTRAN来拆除该RRC连接建立310。

一旦完成RRC连接建立310，开始信令连接建立312。

一旦信令连接建立312完成，开始加密和完整性建立314。在这完成时，完成无线承载建立316。在这点上，可以在UE和UTRAN之间交换数据。

一般而言，以相反的次序类似地完成拆除连接。拆除无线承载建立316，并在然后拆除RRC连接建立310。在这点上，如图1中示出的，RRC移动到空闲模式110。

虽然当前的3GPP规范不允许UE释放RRC连接或者指示其对RRC状态的偏好，UE仍然可以指示针对特定的核心网域(例如，分组交换应用所使用的分组交换(PS)域)的信令连接的终止。根据3GPP TS25.331的8.1.14.1节，UE使用信令连接释放指示过程来向UTRAN指示其信令连接之一已被释放。该过程可进而发起RRC连接释放过程。

从而，停留在当前的3GPP规范内，可以在拆除信令连接建立312时发起信令连接释放。拆除信令连接建立312在UE的能力之内，并进而根据规范，这“可以”发起RRC连接释放。

本领域技术人员将意识到，如果拆除信令连接建立312，在已经拆除信令连接建立312之后，UTRAN将还需要清除解密和完整性建立314以及无线承载建立316。

如果拆除信令连接建立312，在没有活动的CS连接的情况下，通常由当前厂商基础结构的网络来拆除RRC连接建立。

将这用于上述的特定转换指示示例之一，如果UE确定其完成了数据交换，例如，如果向UE软件的“连接管理器”组件提供数据交换完成的指示，则连接管理器可以确定是否拆除信令建立312。例如，设备上的电子邮件应用发送如下指示：其已经从推送电子邮件服务器接收到该推送服务器实际接收到电子邮件的肯定应答。在一个实施例中，连接管理器可以跟踪所有现有的应用、相关的PDP上下文、相关的PS无线资源以及相关的电路交换(CS)无线承载。在其他实施例中，网络单元(例如，UTRAN)可以跟踪现有的应用、相关的PDP上下文、QoS、相关的PS无线资源以及相关的CS无线承载。即使在已经发送“完成”指示之后，可以在UE或网络单元处引入延迟，以确保应用真正完成数据交换并且不再要求RRC连接。可以使该延迟等于与应用或UE相关联的不活动超时。每个应用可以具有其自己的不活动超时，并从而延迟可以是所有应用超时的合成。例如，电子邮件应用可以有5秒的不活动超时，而活动的浏览器应用可以有60秒的超时。禁止持续时间定时器可以进一步延迟发送转换指示。基于所有这些来自于活动的应用的指示的复合状态，以及在一些实施例中的无线资源简档和/或禁止持续时间定时器延迟，UE软件决定，针对适当的核心网(例如，PS域)，在发送转换指示(例如，信令连接释放指示或状态改变请求)之前其应该或者必须等待多长时间。如果在网络单元处实现延迟，该单元确定是否以及如何转换UE，然而仅在延迟已经按计划进行之后才操作转换。

可以基于业务模式历史和/或应用简档来使得不活动超时是动态的。

如果网络单元将UE转换到空闲模式110(这可以发生在图1中示出的RRC连接模式120的任何阶段)，网络单元释放RRC连接并将UE如图1中所示移动到空闲模式110。当UE在语音呼叫期间正在执行任何的分组数据服务时，这也是可应用的。在该情况下，网络可以选择仅释放PS域信令连接，而维持CS域信令连接，或者备选地，可以不选择释放任何连接，而代之以维持对PS和CS域的信令连接。

在另一实施例中，可以将原因增加到转换指示，该原因向UTRAN指示该指示的理由。在优选实施例中，原因可以是如下指示：异常状态导致该指示，或者作为所请求的转换的结果，由UE发起该指示。其他正常(即，非异常)的事务也可以导致发送转换指示。

在另一优选实施例中，各种超时可以导致针对异常条件发送转换指示。下面的定时器的示例不是穷举的，其他定时器或异常条件是可能的。例如，10.2.473GPP TS 24.008如下指定定时器3310：

定时器T3310

使用该定时器来指示附着失败。附着失败可以是网络的结果，或者可以是射频(RF)问题，例如，冲突或者坏的RF。

附着尝试可以发生多次，附着失败由预定数目的失败或显式的拒绝而产生。

3GPP的10.2.47的第二定时器是定时器T3330，如下对其进行指定：

定时器T3330

使用该定时器来指示路由区更新失败。在定时器到期时，可以多次请求另一路由区更新，以及路由区更新失败由预定数目的失败或者显式的拒绝而产生。

3GPP的10.2.47的第三定时器是定时器T3340，如下对其进行指定：

定时器T3340

使用该定时器来指示GMM服务请求失败。在定时器到期时，可以多次发起另一GMM服务请求，以及GMM服务请求失败由预定数目的失败或者显式的拒绝而产生。

从而，替代限于异常条件和UE释放的转换指示原因，转换指示原因还可以包括与定时器因异常条件而失败有关的信息。在将信令连接释放指示作为转换指示来使用的特定示例中，可以如下构建该指示：

信令连接释放指示

UE使用该消息来向UTRAN指示释放现有信令连接的请求。信令连接释放指示原因的增加允许UTRAN或其他网络单元接收信令连接释放指示的原因，而不管其是否由异常条件造成，以及异常条件是什么。基于对信令连接释放指示的接收，进而允许在UTRAN处发起RRC连接释放过程。

在该示例的一个实现中，在从特定CN(核心网)域的高层接收到释放(或放弃)信令连接的请求时，如果在变量中标识了信令连接，UE发起信令连接释放指示过程。例如，针对以IE(信息单元)“CN域标识”来识别的特定CN域，存在变量ESTABLISHED_SIGNALING_CONNECTIONS。如果变量没有标识任何现有的信令连接，通过另一方式放弃针对该特定的CN域的任何正在进行的信令连接的建立。在Cell_PCH或URA_PCH状态下发起信令连接释放指示过程时，UE使用原因“上行链路数据传输”来执行小区更新过程。当小区更新过程成功完成时，UE以以下信令连接释放指示过程来继续。

即，UE将信息单元(IE)“CN域标识”设置为较高的逻辑层所指示的值。IE的值指示了相关信令连接被高层标记为要释放的CN域。如果将CN域标识设置到PS域，以及如果高层指示发起该请求的原因，则相对应地设置IE“信令释放指示原因”。UE还将具有由高层所指示的标识的信令连接从变量“ESTABLISHED_SIGNALING_CONNECTIONS”中移除。UE使用应答模式无线链路控制(AM RLC)来在例如专用控制信道(DCCH)上发送信令连接释放指示消息。在确认由RLC成功传送释放指示消息之后，过程结束。

根据本公开的实施例，还使用了IE“信令连接释放指示原因”。例如，将该释放原因与现有的消息定义相校准。例如，如下构建高层释放原因消息：

在该示例中，T3310、T330和T3340到期对应于上述对应编号的定时器到期。在一个实现中，原因值可被设置为“UE请求的PS数据会话结束”，而不是“UE请求的空闲转换”，以移除对空闲转换的偏好的UE指示，并允许UTRAN对状态转换做出决定，虽然所预期的结果对应于由原因值标识的结果。优选地，然而不是必然地，对信令连接释放指示的扩展是非关键扩展。

现在参考图9。图9是示例性UE监视是否针对各个域(例如，PS或CS)来发送信令连接释放指示的流程图。该过程在步骤910中开始。

UE转换到步骤912，在步骤912中，UE检查是否存在异常条件。这种异常条件可以包括例如如上所述的定时器T3310、定时器T3320或者定时器T3340到期。如果这些定时器到期特定的预定次数，或者如果基于这些定时器中的任何定时器的到期，接收到显式的拒绝，UE进行到步骤914，在步骤914中，UE发送信令连接释放指示。向信令连接释放指示消息附加信令释放指示原因字段。信令释放指示原因字段至少包括信令释放指示基于异常套件或状态，一个实施例包括特定的定时器超时以导致异常条件。

相反，如果在步骤912中，UE发现不存在异常条件，UE进行到步骤920，在步骤920中，UE检查在UE处是否预期有其他数据。如上所述，这可以包括当发送电子邮件，以及在UE处回收到对发送电子邮件的确认时。UE将确定预期没有其他数据的其他示例可以是本领域技术人员所知的。

如果在步骤920中，UE确定数据传送完成(或者在电路交换域的情况下，呼叫完成)，UE进行到步骤922，在步骤922中，UE发送信令连接释放指示，其中，已经增加了信令释放指示原因字段，并包括UE请求空闲转换或简单地指示PS会话结束的事实。

从步骤920，如果数据没有完成，UE环回(loop back)并在步骤912中继续检查是否存在异常条件，以及在步骤920中检查数据是否完成。

一旦在步骤914或步骤922中发送了信令连接释放指示，过程进行到步骤930并结束。

UE包括功能单元，例如，该功能单元能够通过UE微处理器的操作或者通过硬件实现可以执行的应用或算法来实现，形成检查器或转换指示发送器。检查器被配置为检查是否应该发送转换指示。以及，转换指示发送器被配置为响应于检查器对应发送转换指示的指示来发送转换指示。转换指示可以包括转换指示原因字段。

在一个实现中，网络代之以隐式地知道定时器的超时，以及UE不需要发送指示定时器的超时的原因值。亦即，定时器在网络授权时开始计时。定义原因代码，以及由网络向UE提供原因代码。UE使用这种原因代码来发起定时器。网络隐式地知道定时器后续超时的原因，因为网络早先发送的原因代码使定时器开始计时。因此，UE不需要发送对定时器的超时进行指示的原因值。

如图9以及之前的描述所建议的，可以包括原因并与转换指示(例如，信令连接释放指示)一起发送，以指示：1.)异常条件，以及2.)正常条件(不是异常条件，例如，如请求PS数据会话结束和/或转换到空闲模式)。因此，在各种实现中，UE处的操作允许将原因增加到转换指示，以指示异常条件，或者备选地，指示对请求空闲转换或PS数据会话结束的偏好，即，正常操作。当然，这种操作还包括UE操作，在该UE操作中，仅当要进行异常条件的指示时，才将原因增加到转换指示。以及，相反，这种操作还包括UE操作，在该UE操作中，将原因增加到转换指示来仅指示正常的(即，非异常)操作和事物。亦即，关于图9，在这种备选操作中，如果在步骤912处存在异常条件，“是”分支去往步骤914，而如果不存在异常条件，则UE直接进行到结束步骤930。相反，在另一这种备选操作中，在开始步骤912之后，路径直接去往数据结束步骤920。如果数据结束，“是”分支去往步骤920，以及之后去往步骤930。如果在步骤920处数据没有完成，“否”分支返回到相同的步骤，即，步骤920。

返回图10，当网络单元在步骤1010中接收到转换指示(例如，所示出的信令连接释放指示)时，网络单元在步骤1014中检验转换指示原因字段(如果存在)，以及在步骤1016中检查原因是否是异常原因，或者是否是由于UE请求空闲转换和/或PS数据会话结束而造成的。如果在步骤1016中，信令连接释放指示具有异常原因，网络节点进行到步骤1020，在步骤1020中，可以出于性能监视和告警监视的目的来记录告警。可以适当地更新关键性能指示器。

相反，在步骤1016中，如果转换指示(例如，信令连接释放指示)的原因不是异常条件的结果，或者换言之，是UE请求PS数据会话结束或者空闲转换的结果，网络节点进行到步骤1030，在步骤1030中，不产生告警，以及可以将指示从性能统计中滤除，由此防止性能统计被扭曲。从步骤1020或步骤1030，网络节点进行到步骤1040，在步骤1040处结束过程。

转换指示的接收和检验可以导致网络单元发起分组交换数据连接终止，或者备选地，转换到另一更适合的状态，例如CELL_FACH、CELL_PCH、URA_PCH或IDLE_MODE。

如上建议的，在一些实现中，还可以使用在转换指示中缺少原因来确定转换指示是正常还是异常条件的结果，以及是否必须产生告警。例如，如果原因仅被增加来表示正常条件(即，非异常，例如，请求PS数据会话结束和/或转换至空闲模式)，以及网络单元接收没有增加原因的转换指示，网络单元可以从缺少原因推出转换指示是异常条件的结果，并可选地产生告警。相反，在另一示例中，如果原因仅被增加来表示异常条件，以及网络单元接收没有原因的转换指示，网络单元可以从缺少原因推出转换指示是正常条件(例如，请求PS数据会话结束和/或转换至空闲模式)的结果，并且不产生告警。

本领域技术人员将意识到，可以使用步骤1020来进一步区分各种告警条件。例如，可以使用T3310超时来保持统计的第一集合，以及可以使用T3330超时来保持统计的第二集合。步骤1020可以区分异常条件的原因，由此允许网络运营商更有效地跟踪性能。

网络包括功能单元，例如，该功能单元能够通过处理器的操作或者通过硬件实现可以执行的应用或算法来实现，形成检验器和告警产生器。检验器被配置为检验转换指示的转换指示原因字段。检验器检查转换指示原因字段是否指示了异常条件。告警产生器被配置为，如果检验器的检验确定信令连接释放指示原因字段指示了异常条件，可选择地产生告警。

在一个实现中，在接收到信令连接释放指示时，UTRAN转发接收到的原因，并从高层请求释放信令连接。然后，高层能够发起信令连接的释放。IE信令释放指示原因向UE的高层指示触发UE的RRC来发送消息的原因。原因可能是异常的高层过程的结果。通过成功接收该IE，确保了对消息的原因的辨别。

可能的场景包括如下场景：在RLC确认成功传送信令连接释放指示消息之前，在信令无线承载RB2上发生RLC实体的发送侧的重新建立。在这种发生的情况下，例如，UE使用信令无线承载RB2上的AMRLC来在上行链路DCCH上重传信令连接释放指示消息。在来自UTRAN过程的RAT(无线接入技术)间切换发生在RLC确认成功传送信令连接释放指示或请求消息之前的情况下，UE在新的RAT中时放弃信令连接。

在另一实施例中，替代“信令连接释放指示”或请求，可以使用“数据传送完成指示”。与以上图9和10中描述的功能相类似的功能可应用于该数据传送完成指示。

在一个实施例中，UE使用数据传送完成指示来向UTRAN通知UE已经确定没有正在进行的CS域数据传送，以及其已经完成其PS数据传送。例如，使用AM RLC在DCCH上从UE向UTRAN发送这种消息。示例性消息示出如下。

10.2.x 数据传送完成指示

UE使用该消息来向UTRAN通知UE已经确定没有正在进行的CS域数据传送，以及其已经完成其PS数据传送。

RLC-SAP：AM

逻辑信道：DCCH

方向：UE→UTRAN

数据传送完成指示

现在参考图20。图20示出了从UE向UTRAN发送转换指示或请求(例如信令连接释放指示或数据传送完成指示)的实施例。过程在步骤2010处开始，并进行到步骤2012，在步骤2012中，在UE上进行检查，以确定UE处的条件是否适于发送转换指示消息。例如，参考以下的图11，在本公开中描述了这种条件，这种条件可以包括UE上的一个或多个应用确定其完成了数据交换。这种情况还可以包括等待一定的持续时间，以等待定时器T3xx到期(如果在运行)。

在另一以及备选的实施例中，条件可以包括如果定时器T3xx被设置为无穷大，排除发送转换指示。如将要意识到的，T3xx可以包括多个离散值，其中之一表示无穷大值。

如果在步骤2012中，条件不适于发送转换指示或请求消息，过程自身循环，并继续监视，直到条件适于发送转换指示或请求消息。

一旦情况适合，过程进行到步骤2020，在步骤2020中，向UTRAN发送转换指示。在上面的表中示出了示例性的指示。

然后，过程进行到步骤2022，在步骤2022中，进行检查，以确定转换指示是否成功。如本领域技术人员可以意识到的，这可意味着UTRAN已经成功接收到转换指示，并已经发起状态转换。如果是，过程进行到步骤2030，并结束。

相反，如果在步骤2022中确定转换指示没有成功，过程进行到步骤2024，并等待一段时间。可以使用“禁止持续时间”(例如，T3xx)来实现这种等待，禁止持续时间不允许移动设备在给定的持续时间过去之前发送另一转换指示消息。备选地，过程可以限制在给定的一段时间内的转换指示消息的数目(例如，在10分钟内不多于15条消息)。禁止持续时间与限制给定时间段内的消息数目的组合也是可能的。

持续时间可以预先确定，例如，确定为标准中定义的值，可以由网络单元来设置，例如，作为以下消息的一部分：RRC连接请求，RRC连接建立消息、RRC连接释放、无线承载建立、系统信息广播消息、系统信息块消息、活动集合更新、小区更新确认、UTRAN移动性信息消息、切换至UTRAN命令、物理信道重配置消息、无线承载重配置消息、无线承载释放消息、传输信道重配置消息、或者任何的请求、配置或重配置消息。此外，可以基于转换指示消息内的参数来设置持续时间。从而，如果UE正在请求转换至Cell_PCH而不是空闲，持续时间可以更长。

网络单元或对持续时间的发送或信号通知可以采用信息单元的形式。如在此使用的，信号通知或发送可以包括向UE直接发送信息，或者广播信息。类似地，UE处的接收可以包括直接接收或读取广播信道。一个示例性信息单元包括：

禁止转换指示

在一个实施例中，如下定义T3xx的值：

T3xx定义

在一个实施例中，可以将T3xx包括在现有的UMTS信息单元“连接模式下的UE定时器和常数”中。因此，可以将其通过包括在系统信息块类型1中来在小区中广播。在备选实施例中，还可以使用其他系统信息消息来信号通知定时器值，例如，SIB3或SIB4，或者备选地或附加地，可以使用专用UTRAN移动性信息消息来信号通知。

如以上的表中指示的，T3xx值可以在所设置的值之间变化，并包括零值或无穷大值。使用零值来指示不需要发生禁止。无穷大值指示永不应该发送转换指示消息。

在一个移动性实施例中，只要转换到新的网络或小区，UE都复位T3xx值。在该示例中，将值设置为无穷大。这确保了如果转换消息或无线承载消息不包含禁止定时器值，则缺省地，UE不发送转换指示消息。从而，例如，如果转换或无线承载消息不包含“禁止转换指示”，将定时器的值设置为无穷大，以及否则，指示中接收到的定时器的值替换任何先前存储的值。

在另一备选实施例中，如下定义T3xx的值。定时器T3xx的包括是可选的，由此确保了如果没有包括，UE不需要必须支持配置或使用该定时器：

备选的T3xx定义

从而，在小区中接收到禁止定时器是对UE的指示：小区识别到转换指示消息的使用。UE可以使用原因值来确定(如果因为确定长时间不再有PS域数据而由RRC或高层发起)对转换指示进行信号通知。当网络接收到具有该原因值的转换指示消息(如本文中所涉及的，不管具有何种形式)时，其可以确定向UE信号通知改变至更具电池效率的RRC状态的状态转换。

然而，在备选实施例中，当在小区中没有接收到或读取禁止定时器时，UE可以确定UTRAN不支持发送转换指示消息的原因。在该情况下，UE可以确定不配置T3xx的值，也不将T3xx与发送或禁止发送转换指示消息相关地使用。

如果UE确定省略禁止定时器，则基于高层确定不再有PS数据要发送，UE可以省略在转换指示消息中包括原因值，并仅发送转换指示消息。

在备选实施例中，UE在确定省略禁止定时器时，UE不应基于更高层确定不再有PS数据要发送来发起转换指示。

在该所描述的行为的一个实施例中，转换指示消息是信令连接释放指示消息。

在第一备选实施例中，从而在小区中接收到禁止定时器是如下指示：小区识别到转换指示消息的使用。在当T3xx未被设置为无穷大值时允许发送该消息的情况下，当网络接收到转换指示时，网络可以确定向UE信号通知至更具电池效率的RRC状态的状态转换(例如，CELL_FACH、CELL_PCH、URA_PCH或IDLE_MODE)。

在使用3GPP TSG-RAN225.331标准的具体示例中，将以下增加到下面标识的部分：

禁止转换指示

将其增加到章节：

10.2.48.8.6系统信息块类型3；

10.2.48.8.7系统信息块类型4；

10.2.1活动集合更新；

10.2.8小区更新确认；

10.2.16a切换至UTRAN命令；

10.2.22物理信道重配置；

10.2.27无线承载重配置；

10.2.30无线承载释放；

10.2.33无线承载建立；

10.2.40RRC连接建立；

10.2.50传输信道重配置；

除了消息10.2.48.8.6系统信息块类型3和10.2.48.8.7系统信息块类型4之外，上述消息都是移动性信息消息的示例。

以上覆盖了连接和系统操作，以及各个小区之间的转换，确保了如果小区支持转换指示消息，则UE具有禁止定时器值。例如，切换至UTRAN命令确保了从另一无线接入技术(例如，第二代网络)到第三代网络的转换将提供禁止定时器值(如果第三代网络的目标小区支持)。

具体地参考图21，如引用标号2110示出为“开始”的，作为前提或者在UE的其他操作期间，已发生小区间的转换。过程进行到步骤2112，在步骤2112中，接收配置消息。该消息可以是以上标识的任何消息，并包括移动性和非移动性消息。然后，过程进行到步骤2114，在步骤2114中，检查配置消息是否包括禁止定时器值。

如果没有，过程进行到步骤2120，在步骤2120中，将禁止定时器值设置为无穷大。相反，如果确定配置消息的确包括禁止定时器值，过程从步骤2114进行到步骤2130。在步骤2130中，在UE上存储禁止定时器值，替换定时器先前的值。然后，过程进行到步骤2140并结束。将意识到，在一个实施例中，不管网络或小区中的改变何时发生，或者不管何时需要发送转换指示，都调用图21的过程。

一旦在步骤2024中，过程等待预定的时间，过程进行回到步骤2012，以确定是否仍然存在发送转换指示的条件。如果是，过程环回步骤2020和2022，并结束。

基于以上所述，可以在各个实施例中提供禁止定时器值。在第一实施例中，可以仅使用RRC连接建立消息传送禁止定时器值来提供禁止定时器值。

在第二实施例中，可以使用系统信息来传送禁止定时器值。

在第三实施例中，可以使用RRC连接建立和系统信息消息二者来发送禁止定时器值，以确保空闲模式以及Cell_PCH/Cell_FACH和DCH状态下的UE具有最近的信息。

在第四实施例中，可以如第三实施例中一样来发送禁止定时器值，并增加在无线承载建立中发送禁止定时器值，以使得当没有无线承载地建立PDP上下文时，当后续建立无线承载来发送数据消息时，可以在此时传送禁止定时器值。

在第五实施例中，可以将第四实施例与以上所述并包括重新配置、小区更新信息和切换至UTRAN命令的所有移动性相关的消息相组合，以传送禁止定时器值。

在第一至第四实施例中，在移动期间，UE维持其当前存储的禁止定时器值。如上指示的，在将禁止定时器设置为无穷大的一些情况下，这可以意味着UE必须等待网络定时器到期，以及等待网络将该UE移动到其可以接收或确定禁止定时器的新值的RRC状态。当在切换之前禁止定时器是除无穷大之外的其他值的情况下，持续使用该其他值，直到UE能够将定时器值更新为在新的小区中指示的定时器值。

对于第五实施例，使用图21的过程来确保在移动期间更新禁止定时器值，以及不没有必要地从UE发送转换指示消息。

例外可以发生在RLC重新建立或RAT间改变时。如果RLC实体的发送侧的重新建立发生在已经由RLC确认了转换指示消息的成功传送之前，在一个实施例中，UE使用AM RLC在上行链路DCCH上重传转换指示消息。

在一个实施例中，如果从UTRAN的RAT间切换过程发生在已经由RLC确认转换指示消息的成功传送之前，UE在新的RAT中时放弃信令连接。

在网络侧，与参考下面的图18描述的过程相类似地处理该过程。

再次参考图1，在一些情况下，可更期望在连接模式120下，在例如URA_PCH状态128的状态中，而不是在空闲模式110下。例如，如果要求针对至连接模式120下的CELL_DCH状态122或CELL_FACH状态124的连接的延迟更低，优选处于连接模式120PCH状态。有多种方式来对此进行实现，例如，如通过修改标准以允许UE请求UTRAN将其移动至特定的状态(例如，在本情况下，URA_PCH状态128)。

备选地，连接管理器可以考虑到其他因素，例如RRC连接当前处于什么状态。例如，如果RRC连接处于URA_PCH状态，可以决定移动到空闲模式110是不必要的，并从而不发起信令连接释放过程。

在另一备选中，网络单元(例如，UTRAN)可以自己考虑到其他因素，例如RRC连接当前处于什么状态，以及如果例如RRC处于URA_PCH状态，其可以决定移动到空闲模式110是没有必要的，并代之以简单地将UE转换到更适合的状态，而不是释放连接。

参考图4。图4A示出了根据以上的基础结构“四”示例的当前的UMTS实现。如图4中示出的，时间在水平轴上。

UE以RRC空闲状态110开始，并基于需要发送本地或移动设备产生的数据或从UTRAN接收的寻呼来开始建立RRC连接。

如图4A中示出的，RRC连接建立310首先发生，以及在该时间期间，RRC状态是在连接状态410下。

接下来，发生信令连接建立312、加密和完整性建立314以及无线承载建立316。在这些过程期间，RRC状态是CELL_DCH状态122。如图4A中示出的，在本示例中，用于从RRC空闲移动到建立无线承载的时间的经过时间大致是两秒。

接下来交换数据。在图4A的示例中，这在大约2至4秒内实现，并由步骤420示出。

在步骤420中交换数据之后，除了根据需要的间歇性RLC信令PDU之外，不交换数据，从而网络重新配置无线资源，以在大约10秒之后移动到叫低数据速率的DCH配置中。在步骤422和424中对此进行示出。

在较低数据速率DCH配置中，在17秒内什么都不接收，在该点处，在步骤428中，网络释放RRC连接。

一旦在步骤428中发起RRC连接释放，RRC状态进行到断开状态430大约四十毫秒，在此之后，UE处于RRC空闲状态110。

如图4A中还示出的，针对RRC处于CELL_DCH状态122的时间段示出了UE电流消耗。如图所示，对于CELL_DCH状态的整个持续时间，电流消耗是大约200至300毫安。在断开和空闲期间，假设DRX循环是1.28秒，利用了大约3毫安。然而，在电池上以200至300毫安汲取了35秒的电流消耗。

现在参考图4B。图4B使用了以上的相同示例性基础结构“四”，只是现在实现信令连接释放。

如图4B中示出的，发生相同的建立步骤310、312、314和316，当在RRC空闲状态110和RRC CELL_DCH状态122之间移动时，这花了相同量的时间。

此外，在图4B处也进行图4A的步骤420处用于示例性电子邮件的RRC数据PDU交换，并且这花了大约2至4秒。

图4B的示例中的UE具有应用特有的不活动超时，在图4B的示例中，该不活动超时是2秒，并由步骤440示出。在连接管理器已经确定存在不活动达到特定量的时间之后，UE发送转换指示，在本情况下，在步骤442中和步骤448中该转换指示是信令连接释放指示，网络基于接收到该指示并基于UE的无线资源简档来进行到释放RRC连接。

如图4B中示出的，CELL_DCH步骤122期间的电流消耗仍然是大约200至300毫安。然而，连接时间仅为大约8秒。本领域技术人员将意识到，移动设备在小区DCH状态122中停留的时间量短得多，导致UE设备的显著电池节省。

现在参考图5。图5示出了使用以上指示为基础结构“三”的基础结构的第二示例。与图4A和4B一样，发生连接建立，连接建立花了大约2秒。这需要RRC连接建立310、信令连接建立312、加密和完整性建立314和无线承载建立316。

在该建立期间，UE从RRC空闲模式110移动到CELL_DCH状态122，RRC状态连接步骤410在两者中间。

与图4A一样，在图5A中，RLC数据PDU交换发生在步骤420处，以及在图5A的示例中，花了2至4秒。

根据基础结构三，除了根据需要的间歇性RLC信令PDU外，RLC信令PDU交换不接收数据，并从而在步骤422中在5秒的时间段内处于空闲，在该点上，无线资源重新配置UE从CELL_DCH状态122移动到CELL_FACH状态124。这在步骤450中完成。

在CELL_FACH状态124中，RLC信令PDU交换发现在预定量的时间(在这种情况下，30秒)内，除了根据需要的间歇性RLC信令PDU之外没有数据，在这点上，在步骤428中由网络执行RRC连接释放。

在图5A中看出，这将RRC状态移动至空闲模式110。

在图5A中还看出，DCH模式期间的电流消耗在200至300毫安之间。当移动到CELL_FACH状态124中时，电流消耗降低到大约120至180毫安。在释放RRC连接并且RRC进入到空闲模式110中后，功耗大约是3毫安。

在图5A的示例中，作为CELL_DCH状态122或CELL_FACH状态124的UTRA RRC连接模式状态持续了大约40秒。

现在参考图5B。图5B示出了与图5A中相同的基础结构“三”，具有大约2秒的相同连接时间来得到RRC连接建立310、信令连接建立312、加密完整性建立314以及无线承载建立316。此外，RLC数据PDU交换420花了大约2至4秒。

与图4B中一样，UE应用在步骤440中检测到特定的不活动超时，在该点上，UE发送转换指示(例如，信令连接释放指示442)，以及作为结果，网络在步骤448中释放RRC连接。

在图5B中还可以看出，RRC在空闲模式110下开始，移动到CELL_DCH状态122，而不进行到CELL_FACH状态。

在图5B中还将看出，在RRC阶段在CELL_DCH状态122下的时间中，电流消耗大约是200至300毫秒，根据图5的示例，该时间大约是8秒。

因此，图4A和4B，以及图5A和5B之间的对比显示消除了大量的电流消耗，由此扩展了UE的电池寿命。本领域技术人员将意识到，还可以在当前3GPP规范的上下文中使用以上方案。

现在参考图6。图6示出了用于UMTS网络的协议栈。

如图6中看出的，UMTS包括CS控制平面610、PS控制平面611以及PS用户平面630。

在这三个平面内，存在非接入层(NAS)部分614和接入层部分616。

CS控制平面610中的NAS部分614包括呼叫控制(CC)618、补充服务(SS)620以及短消息服务(SMS)622。

PS控制平面611中的NAS部分614包括移动性管理(MM)和GPRS移动性管理(GMM)626。还包括会话管理/无线接入承载管理SM/RABM 624和GSMS 628。

CC 618提供用于电路交换服务的呼叫管理信令。SM/RABM 624的会话管理部分提供PDP上下文激活、去激活和修改。SM/RABM 624还提供服务质量协商。

SM/RABM 624的RABM部分的主要功能是将PDP上下文连接到无线接入承载。从而SM/RABM 624负责无线资源的建立、修改和释放。

接入层616中的CS控制平面610和PS控制平面611位于无线资源控制(RRC)617上。

PS用户平面630中的NAS部分614包括应用层638、TCP/UDP层636和PDP层634。PDP层634例如可以包括互联网协议(IP)。

接入层616在PS用户平面630中包括分组数据会聚协议(PDCP)632。PDCP 632被设计为使WCDMA协议适于在UE和RNC(如图8中看出的)之间承载TCP/IP协议，以及可选地用于IP业务流协议首部压缩和解压缩。

UMTS无线链路控制(RLC)640和媒体接入控制(MAC)层650形成了UMTS无线接口的数据链路子层，并驻留在RNC节点和用户设备上。

层1(L1)UMTS层(物理层660)在RLC/MAC层640和650之下。该层是用于通信的物理层。

虽然可以在各种移动或无线设备上实现以上方案，下面关于图7描述了一个移动设备的示例。现在参考图7。

优选地，UE 700是至少具有语音和数据通信能力的双向无线通信设备。优选地，UE 700具有与互联网上的其它计算机系统通信的能力。取决于所提供的确切功能，作为示例，可以将无线设备称为数据消息收发设备、双向寻呼机、无线邮件设备、具有数据消息收发能力的蜂窝电话、无线互联网装置或数据通信设备。

在使UE 700能够进行双向通信的情况下，UE 700将并入通信子系统711，通信子系统711包括接收机712和发射机714以及相关联的组件，例如一个或多个优选嵌入或者在内部的天线单元716和718、本地振荡器(LO)713以及诸如数字信号处理器(DSP)720的处理模块。对通信领域的技术人员将显而易见的是，通信子系统711的具体设计将取决于设备打算在其中工作的通信网络。例如，UE 700可以包括被设计来在GPRS网络和/或UMTS网络中工作的通信子系统711。

取决与网络719的类型，网络接入要求也将改变。例如，在UMTS和GPRS网络中，网络接入与UE 700的订户或用户相关联。例如，为了在GPRS网络上工作，GPRS移动设备因此需要订户识别模块(SIM)卡。在UMTS中，需要USIM或SIM模块。在CDMA中，需要RUIM卡或模块。在此，这些都将被称为UIM接口。没有有效的UIM接口，移动设备不能具有完全的功能。本地的或者非网络的通信功能以及法律上要求的功能(如果有的话)(例如，紧急呼叫)可以是可用的，然而移动设备700将不能够执行与网络700上的通信有关的其它任何功能。UIM接口714正常来说与卡槽相类似，卡可以与碟或者PCMCIA卡相似地插入和退出卡槽。UIM卡可具有大约64K的存储器并保存了很多关键配置751以及其它信息753，如标识和订户相关信息。

当所要求的网络注册或激活过程已完成后，UE 700可以在网络719上发送和接收通信信号。将天线716通过通信网络719接收到的信号输入到接收机712，接收机512可执行如信号放大、下变频、滤波、信道选择等的这些普通接收机功能，在图7所示的示例系统中还可以提供模数(A/D)转换。对接收信号的A/D转换使得在DSP 720中可以执行更复杂的通信功能，例如，解调和解码。以相似的方式，DSP 720对要发送的信号进行处理，例如包括调制和编码，并将其发送到发射机714以进行数模变换、上变频、滤波、放大并经由天线718在通信网络719上发送。DSP 720不仅处理通信信号，还提供接收机和发射机控制。例如，通过在DSP 720中实现的自动增益控制算法，可以对施加到接收机712和发射机714中的通信信号的增益进行自适应控制。

网络719还可以与多个系统进行通信，包括服务器760以及其他单元(未示出)。例如，网络719可以与企业系统和web客户端系统二者通信，以将各种客户端与各种服务等级相适应。

优选地，UE 700包括控制设备的整体操作的微处理器738。通过通信子系统711来执行至少包括数据通信在内的通信功能。微处理器738还与其他设备子系统进行交互，其他设备子系统例如显示器722、闪存724、随机存取存储器(RAM)726、辅助输入/输出(I/O)子系统728、串口730、键盘732、扬声器734、麦克风736、短距离通信子系统740以及被总体指示为742的其它任何的设备子系统。

图7所示的某些子系统执行与通信相关的功能，而其他子系统可以提供“驻留”或设备上功能。值得注意地，一些子系统(例如，键盘732和显示器722)可被用于通信相关的功能和设备驻留功能，通信相关的功能例如输入用于在通信网络上发送的文本消息，设备驻留功能例如计算器或任务列表。

优选地，将微处理器738所使用的操作系统软件存储在持久存储器如闪存724中，取而代之，持久存储器可以是只读存储器(ROM)或类似的存储单元(未示出)。本领域技术人员将意识到，可将操作系统、特定的设备应用或其部分临时加载到例如RAM 726的易失性存储器中。还可以将接收到的通信信号存储在RAM 726中。此外，优选地，也将唯一标识符存储在只读存储器中。

如图所示，可以将闪存714分段为不同的区域，用于计算机程序758以及程序数据存储750、752、754和756这些不同的存储器类型指示了每个程序可以针对其自己的数据存储要求来分配闪存724的一部分。优选地，除了其操作系统功能外，微处理器738使得可以在移动设备上执行软件应用。在制造期间，通常将对基本操作进行控制的应用的预定集合(例如，至少包括数据和语音通信应用)安装在UE 700上。优选的软件应用可以是个人信息管理器(PIM)应用，PIM应用有能力组织和管理与移动设备的用户相关的数据项，该数据项例如但不限于电子邮件、日程安排、语音邮件、预约和任务项。自然，在移动设备上，一个或更多的存储器存储可以是可用的，以方便PIM数据项的存储。优选地，这种PIM应用程序可具有经由无线网络719发送和接收数据项的能力。在优选的实施例中，经由无线网络719将PIM数据项与移动设备用户的对应数据项进行无缝集成、同步和更新，该对应数据项被存储或与主机系统相关联。还可以通过网络719、辅助I/O子系统728、串口730、短距离通信子系统740或者任何其他适合的子系统742将其他应用加载到移动设备700上，并由用户安装到RAM 726中，或者优选地，安装到非易失性存储器(未示出)中，以由微处理器738来执行。应用安装中的这样灵活性增加了设备的功能，并且可以提供增强的在机功能、通信相关功能或其两者。例如，安全通信应用可以使得使用UE 700来实现电子商务功能和其他这种金融交易。然而，根据以上述所，这些应用在很多情况下需要由运营商来批准。

在数据通信模式下，接收信号(例如，文本消息或网页下载)将由通信子系统711来处理，并输入到微处理器738，微处理器738优选地还对接收信号进行处理，以输出到显示器722，或者备选地输出到辅助I/O设备728。UE 700的用户还可以例如使用键盘732结合显示器732以及可能的辅助I/O设备728来编写数据项(例如，电子邮件消息)，优选地，键盘732是完整字母数字键盘或电话类型的小键盘。然后，可以通过通信子系统711在通信网络上发送这种编写的项目。

对于语音通信，UE 700的整体操作类似，除了优选地可以将接收信号输出到扬声器734，以及可以由麦克风736来产生用于发送的信号。还可以在UE 700上实现备选的语音或音频I/O子系统，例如语音消息录制子系统。虽然优选主要通过扬声器734来完成语音或音频信号输出，也可以使用显示器722来提供对例如主叫方的标识、语音呼叫的持续时间或者其他语音呼叫相关信息的指示。

图7中的串口730通常可在个人数字助理(PDA)类型的移动设备中实现，对于PDA类型的移动设备，与用户的桌面型计算机(未示出)的同步是所期望的。这种端口730可使得用户可以通过外部设备或软件应用来设置偏好，并且除了通过无线通信网络以外，可通过将信息或软件下载提供到UE 700来扩展移动设备700的能力。例如，可以使用备选下载路径来通过直接并从而可靠和可信的连接，将加密密钥加载到设备上，由此使得可以进行安全的设备通信。

备选地，可以使用串口730来用于其他通信，以及串口730可以包括通用串行总线(USB)端口。接口与串口730相关联。

其它通信子系统740(例如，短距离通信子系统)是此外的可选组件，其可以提供UE 700与不同的系统或设备之间的通信，这些设备不是必须是相似的设备。例如，子系统740可以包括红外设备以及相关电路和组件或者蓝牙TM通信模块，以提供与具有类似能力的系统和设备的通信。

现在参考图8。图8是包括通过无线通信网络来通信的UE 802的通信系统800的方框图。

UE 802与一个或多个节点B 806进行无线通信。每个节点B 806负责空中接口处理和一些无线资源管理功能。节点B 806提供与GSM/GPRS网络中的收发基站类似的功能。

图8的通信系统800中示出的无线链路表示一条或多条不同的信道(通常是不同的射频(RF)信道)，以及在无线网络和UE 802之间使用的相关协议。在UE 802和节点B 806之间使用Uu空中接口804。

RF信道是必须节约的有限的资源，通常是由于总带宽的限制和UE 802的有限的电池功率。本领域技术人员将意识到，根据所期望的网络覆盖的整体展开，实际实践中的无线网络可以包括数百个小区。可以通过由多个网络控制器控制的多个开关和路由器(未示出)来连接所有相关的组件。

每个节点B 806与无线网络控制器(RNC)810通信。RNC 810负责控制其区域中的无线资源。一个RNC 810控制多个节点B 806。

UMTS网络中的RNC 810提供与GSM/GPRS网络中的基站控制器(BSC)功能等效的功能。然而，RNC 810包括更多的智能，例如包括不涉及MSC和SGSN的自主切换管理。

在节点B 806和RNC 810之间使用的接口是Iub接口808。主要使用NBAP(节点B应用部分)信令协议，如在3GPP TS 25.433V3.11.0(2002-09)和3GPP TS 25.433V5.7.0(2004-01)中所定义。

通用陆地无线接入网(UTRAN)820包括RNC 810、节点B 806和Uu空中接口804。

向移动交换中心(MSC)830路由电路交换业务。MSC 830是进行呼叫，以及从订户或从PSTN(未示出)取得和接收数据的计算机。

RNC 810和MSC 830之间的业务使用Iu-CS接口828。Iu-CS接口828是UTRAN 820和核心语音网络之间用于承载(通常)语音业务和信令的电路交换连接。所使用的主要信令协议是RANAP(无线接入网应用部分)。在核心网821和UTRAN 820之间的UMTS信令中使用RANAP协议，核心网821可以是MSC 830或SGSN 850(下面更详细地定义)。在3GPP TS 25.413V3.11.1(2002-09)和TS 25.413V5.7.0(2004-01)中定义了RANAP协议。

对于注册到网络运营商的所有UE 802，将永久的数据(例如，UE802的用户的简档)以及临时数据(例如，UE 802的当前位置)存储在归属位置寄存器(HLR)838中。在去往UE 802的语音呼叫的情况下，查询HLR 838以确定UE 802的当前位置。MSC 830的访问位置寄存器(VLR)836负责一组位置区，并存储当前在其负责的区域中的移动台的数据。这包括已从HLR 838发送到VLR 836以用于更快接入的永久性移动台数据的部分。然而，MSC 830的VLR 836还可以分配和存储本地数据，例如临时标识。还由HLR 838来关于系统接入对UE 802进行认证。

通过服务GPRS支持节点(SGSN)850来路由分组数据。SGSN 850是GPRS/UMTS网络中在RNC和核心网之间的网关，并负责从其地理服务区内的UE传送数据分组和向其地理服务区内的UE传送数据分组。Iu-PS接口848用在RNC 810和SGSN 850之间，并且是用于在UTRAN820和核心数据网之间承载(通常)数据业务和信令的分组交换连接。所使用的主要信令协议是RANAP(如上所述)。

SGSN 850与网关GPRS支持节点(GGSN)860通信。GGSN 860是UMTS/GPRS网络和其他网络(例如，互联网或私有网络)之间的接口。GGSN 860在Gi接口上连接到公共数据网络PDN 870。

本领域技术人员将意识到，无线网络可以连接到图8中没有明确示出的其他系统，很可能包括其他网络。即使没有交换实际分组数据，通常网络将正在传输最起码的某种寻呼和系统信息。虽然网络由很多部分组成，这些部分全部在一起工作，以在无线链路处产生特定的行为。

图11示出了根据多个并发的分组数据通信服务会话，对UE的操作进行表示的表示，以1102来总体示出。在此，两个分组数据服务同时是活动的，分别与被指定为PDP₁和PDP₂的特定PDP上下文相关联。曲线1104表示向第一分组数据服务激活的PDP上下文，以及曲线1106表示向第一分组数据服务分配的无线资源。此外，曲线1108表示向第二分组数据服务激活的PDP上下文，以及曲线1112表示向第二分组数据服务分配的无线资源。UE通过服务请求的方式请求无线接入承载分配，由段1114来指示。以及，根据本公开的实施例，UE还请求无线承载服务释放，由段1116来指示。对各个服务的服务请求和服务释放是彼此独立的，亦即，是独立产生的。在图11的示例性示意中，实质上同时地分配PDP上下文和用于相关联的PDP上下文的无线资源。此外，在由UE请求时(如图所示)，或者当RNC(无线网络控制器)决定释放无线资源时，许可无线资源释放。

响应于无线资源释放请求，或者释放无线资源的其他决定，网络可选择地拆除与分组数据服务相关联的无线资源。以逐个无线接入承载的方式，而不是基于整个信令连接来进行无线释放请求，由此允许改进资源分配的粒度控制。

在示例性的实现中，可以将单个分组数据分组进一步形成为主服务和一个或多个辅助服务，例如，标记1118和1122所指示的。无线资源释放还允许识别一个或多个主服务和辅助服务中哪些服务的无线资源分配不再需要，或者期望被释放。由此提供了高效的无线资源分配。此外，提供了UE上的处理器的最优使用，因为可被分配给不必要的处理的处理器功率现在可以更好地用于其他目的。

图12示出了通信系统800的部分，即，关于多个连续的分组数据服务会话，根据本公开的实施例操作的UE 802和无线网络控制器(RNC)/SGSN 810/850。UE包括装置1126，以及RNC/SGSN包括本公开的实施例的装置1128。对形成装置1126和1128的单元进行功能性表示，可以通过任何期望的方式实现，包括处理电路可执行的算法以及硬件或固件实现。虽然被表示为实现在RNC/SGSN处，在其他实施例中，装置1128的单元可以在其他网络位置的其他地方形成，或者分布在一个以上的网络位置上。

装置1126包括检测器1132和转换指示发送器1134。在一个示例性实现中，在UE的会话管理层(例如UMTS中定义的非接入层(NAS))处实现单元1132和1134。

在另一示例性实现中，在接入层(AS)子层处实现该单元。当在AS子层处实现时，将该单元实现为1136处示出的连接管理器的一部分。当通过这种方式实现时，单元不需要知道PDP上下文行为或应用层行为。

检测器检测何时作出决定以发送与分组通信服务相关联的转换指示。例如在应用层或其他逻辑层作出该决定，并向会话管理层以及在会话管理层处实现检测器的提供。将检测器做出的对检测的指示提供给无线资源释放指示发送器。发送器产生并使UE发送转换指示，该转换指示形成图11中示出的服务释放请求1116。

在另一实现中，转换指示合适地包括包含原因的原因字段(例如，在此处和上面描述的任何上述的原因)，或者原因字段标识优选的状态，UE更希望网络使得UE转换到该优选的状态中。

在网络处实现的装置1128包括检验器1142和许可器1144。当接收到转换指示时，检验器检验转换指示。此外，转换许可器1144可选择地操作，以根据转换指示中的请求来转换UE。

在无线资源控制(RRC)层处执行信号通知的实现中，无线网络控制器(RNC)，而不是SGSN执行检验和UE的转换。此外，相对应地，在UE处实现的装置在RRC层处形成，或者装置以其他方式使所产生的指示在RRC层处发送。

在示例性的控制流程中，高层合适地向NAS/RRC层通知向特定PDP上下文分配的无线资源不再需要。向网络发送RRC层指示消息。消息包括例如向无线网络控制器标识分组数据服务的RAB ID或RB ID。此外，作为响应，无线网络控制器的操作触发过程，以决定结束要向UE返回的无线资源释放、无线资源重新配置或者无线资源控制(RRC)连接释放消息。该RNC过程例如与3GPP文档TS 23.060，9.2.5节所阐述的过程相似或者等效。例如，RAB ID有利地用作与标识相关的PDP上下文的网络服务接入点标识符(NSAPI)相同的ID，一般而言应用层知道NSAPI。

在特定的示例中，下面将无线资源释放指示与相关信息一起表示，该无线资源释放指示在RRC层处形成，或者通过其他方式向RRC层提供，并且在RRC层处发送。在RRC层处实现时，该指示也称为例如无线资源释放指示。

图13示出了对根据与PDP上下文相关联的无线资源的释放而产生的示例性信令进行表示的消息序列图(以1137来总体示出)，该信令例如是在图11中示出的图形表示的一部分中以图形示出的信令。通过UE或在RNC处，或者由其他UTRAN实体来发起释放。例如，当在UE处发起时，UE向UTRAN发送无线资源释放指示。

在发起时，产生无线接入承载(RAB)释放请求，并由RNC/UTRAN发送(以段1138来指示)和向SGSN传送。作为响应，向RNC/UTRAN返回RAB分配请求(由段1140来指示)。以及然后，如段1142所指示的，释放在UE 802和UTRAN之间延伸的无线资源。然后，如段1144所指示的，发送响应。

图14示出了以1147总体示出的消息序列图，该序列图与图13中示出的消息序列图相似，然而在此，释放最终PDP上下文的资源。在发起时，向SGSN传送由RNC产生的Iu释放请求1150，响应于此，SGSN返回Iu释放命令(以段1152来指示)。之后，如段1154所指示的，释放在UE和UTRAN之间形成的无线承载。此外，如段1156所指示的，RNC/UTRAN向SGSN返回Iu释放完成。

图15示出了方法流程图(以1162来总体示出)，该方法流程图表示了释放根据PDP上下文分配的无线资源的本公开实施例的过程。

在开始该过程(由步骤1164来指示)之后，确定(由步骤1166来指示)是否已经接收到无线资源释放指示。如果没有，采用“否”分支，到结束步骤1168。

相反，如果已经请求了无线接入承载释放，采用“是”分支，到决定步骤1172。在决定步骤1172处，确定要释放的无线接入承载是否是要释放的最终无线接入承载。如果不是，采用“否”分支，到步骤1178，以及设置优选状态。然后执行例如图13中示出或者例如3GPP文档23.060节，子条款9.2.5.1.1所描述的无线接入承载释放过程。

相反，如果在决定步骤1172处确定该RAB是最后要释放的RAB，采用“是”分支，到步骤1186，执行例如图14中示出的或者例如3GPP文档23.060节子条款9.2.5.1.2所描述的Iu释放过程。

图16示出了方法流程图(以1192来总体示出)，该方法流程图表示了释放根据PDP上下文分配的无线资源的本公开实施例的过程。

在开始该过程(由步骤1194来指示)之后，确定(由步骤1196来指示)是否有RAB(无线接入承载)要释放。如果没有，采用“否”分支，到结束步骤1198。

相反，如果已经请求了无线接入承载释放，采用“是”分支，到决定步骤1202。在决定步骤1202处，确定要释放的无线接入承载是否是要释放的最终无线接入承载。如果不是，采用“否”分支，到设置RAB列表的步骤1204，设置优选状态的步骤1206，以及执行无线接入承载释放过程的步骤1208，该无线接入承载释放过程例如是图13中示出的或者例如3GPP文档23.060节子条款9.2.5.1.1所描述的无线接入承载释放过程。

相反，如果在决定步骤1202处确定该RAB是最后要释放的RAB，采用“是”分支，到步骤1212，并将域设置到PS(分组交换)。然后，如步骤1214所指示的，设置释放原因。以及，如步骤1216所指示的，在DCCH上发送信令连接释放指示。执行例如图14中示出或者例如在3GPP文档23.060节子条款9.2.5.1.2所描述的Iu释放过程。

图17示出了对本公开的实施例的操作的方法进行表示的方法(以1224来总体示出)。该方法便于在允许第一分组服务和第二分组服务同时运行的无线通信系统中提供无线资源的高效使用。首先，如步骤1226所指示的，检测选择释放与第一分组服务和第二分组服务中所选择的分组服务相关联的无线资源。然后，如步骤1228所示，响应于检测到对释放无线资源的选择来发送无线资源释放指示。

然后，在步骤1212，检验无线资源释放指示，以及然后在步骤1214，可选择地许可对无线承载的释放的许可。

在另一实施例中，网络可以基于对来自用户设备或另一网络单元的指示的接收，以及基于用户设备的无线资源简档来发起转换。

从用户设备或其他网络单元接收到的指示可以是上述的不同转换指示中的任何指示。该指示可以是被动的，并从而仅是应该进入相对不高度需要电池的无线状态的空白指示。备选地，指示可以是从UE发送的常规指示的一部分，该常规指示是网络很可能基于时间或多个接收到的指示以及UE的无线资源简档来确定应该进入相对不高度需要电池或无线资源的无线状态。备选地，指示可以是动态的，并向网络单元提供与要转换到的优选状态或模式有关的信息。如以上一样，指示可以包含指示的原因(例如，正常或异常)。在另一实施例中，该指示可以提供与无线资源简档有关的其他信息，例如，关于转换到不同状态或模式的能力，用户设备正确的概率，或者与触发该指示的应用有关的信息。

来自另一网络单元的指示可以包括例如来自媒体或按下通话(push-to-talk)网络实体的指示。在该示例中，当业务条件允许时，向负责转换的网络实体(例如，UTRAN)发送指示。该第二网络实体可以在互联网协议(IP)级来查看业务，以确定是否以及何时发送转换指示。

在另一实施例中，来自UE或第二网络实体的指示可以是隐式的，而不是显式的。例如，可以由负责转换的网络实体(例如，UTRAN)从与输出业务测量有关的设备状态报告来暗示转换指示。具体地，状态报告可以包括无线链路缓存状态，其中，如果不存在输出数据，可以解释为隐式的指示。这种状态报告可以是可从自身不请求或指示任何事的UE重复发送的测量。

从而，指示可以是任何信号，以及可以基于应用的、基于无线资源的、或者是提供与所有用户设备的应用和无线资源有关的信息的复合指示。以上不意味着对任何具体指示的限制，以及本领域技术人员将意识到，可以将任何的指示与本方法和公开一起使用。

现在参考图18。过程在步骤1801处开始，并进行到步骤1810，在步骤1810处，网络单元接收指示。

一旦网络在步骤1810中接收到指示，过程进行到步骤1820，在步骤1820中，可选地检查用户设备的无线资源简档。

此处使用的术语“无线资源简档”指的是取决于网络单元的要求，可以应用于各种情况的宽泛的术语。在宽泛的意义上，无线资源简档包括与用户设备利用的无线资源有关的信息。

无线资源简档可以包括静态简档单元以及动态或协商的简档单元中的任一或二者。这种单元可以包括“禁止持续时间和/或每时间窗口的最大指示/请求消息”值，该值可以是无线资源简档的一部分，在转换简档内或与转换简档分离，以及可以是协商的或者静态的。

静态简档单元可以包括无线资源(例如，RAB或RB)的服务质量、PDP上下文、网络已知的APN以及订户简档中的一个或多个。

本领域技术人员应该意识到，对于无线资源，存在质量服务的各个等级，服务质量的等级可以向网络提供与是否转换到不同的状态或模式有关的信息。从而，如果服务质量是后台，与如果将服务质量设置为交互式相比，网络单元可以更乐意考虑转换到空闲。此外，如果多个无线资源具有相同的服务质量，这可以向网络提供与是将移动设备转换到更适合的状态或模式，还是拆除无线资源有关的指示。在一些实施例中，主PDP上下文和辅助PDP上下文可以具有不同的服务质量，这也可以影响到与是否执行状态/模式转换有关的决定。

此外，APN可以向网络提供与PDP上下文所使用的典型服务有关的信息。例如，如果APN是xyz.com，其中，xyz.com通常被用于提供数据服务(例如，电子邮件)，这可以向网络提供与是否转换到不同的状态或模式有关的指示。这还可以指示路由特性。

具体地，本方法和装置可以使用UE所指定的接入点名称(APN)来设置各个状态之间的转换简档。这可以是描述UE的预订的另一种方式。如将意识到的，归属位置寄存器(HLR)可以存储与订户有关的相关信息，以及可以向无线网络控制器(RNC)提供UE的预订。还可以使用其他网络实体来集中地存储预订信息。不管是使用HLR还是其他网络实体，优选向将预订信息映射至在数据交换期间使用的相关物理参数的其他网络组件(例如，RNC和SGSN)推送信息。

UTRAN可以包括或能够访问数据库或表，在该数据库或表中，各种APN或QoS参数可以与特定的转换简档联系在一起。从而，如果UE是总是开启的设备，这从APN是显而易见的，可以将针对该APN的适当转换简档作为无线资源简档的一部分存储在UTRAN处，或者可以由UTRAN远程访问。类似地，如果使用了QoS或QoS参数的一部分，或者利用简档来发送专用消息，这可以向UTRAN表明基于数据库查询或表中的查找，特定转换简档是期望的。此外，可以通过该手段来指定超出RRC连接状态转换简档的多个行为。它们包括但不限于：

速率适配算法(步骤/步长的周期)；

初始许可的无线承载；

最大许可的无线承载；

最小化呼叫建立时间(避免没有必要的步骤，例如，业务量测量)；以及

空中接口(GPRS/EDGE/UMTS/HSDPA/HSUPA/LTE等)。

此外，如果存在具有不同QoS要求但共享相同APN IP地址的多个PDP上下文(例如，主上下文、辅助上下文等)，可以针对每个上下文使用不同的转换简档。可以通过QoS或专用消息将其信号通知给UTRAN。

如果同时使用多个活动的PDP上下文，可以使用上下文之间的最小公分母。对于RRC状态转换，如果一个应用具有与系统从CELL_DCH状态快速移动到CELL_PCH或空闲状态的转换简档相关联的第一PDP上下文，以及第二PDP上下文与系统更长地停留在CELL_DCH状态下的转换简档相关联，将CELL_DCH维持更长的第二简档将覆盖第一简档。

本领域技术人员将意识到，可以通过两种不同的方式来考虑最小公分母。在此使用的最小公分母意味着在转换到不同的状态之前所需的最长时间。在第一实施例中，最小公分母可以是所激活的PDP中最低的。在备选的实施例中，最小公分母可以是实际具有活动的无线资源的PDP中最低的。可以通过很多不同的方式来复用无线资源，然而最终结果是相同的。

可以针对总是开启的设备来描绘这种方法的示例性情况。如所描述的，可以将各种APN或QoS参数与总是开启的设备的特定行为相联系。考虑初始许可的无线资源，基于“总是开启”简档，该初始许可的无线资源可以是期望的。现在，网络有手段来“知道”对于总是开启的应用(例如，电子邮件)来说，数据突发是短的并且是突发性的。对于本领域技术人员来说，很清楚地看出，给定该信息，没有为网络上的中继(trunking)效率节省代码空间的动机。从而，以很小的不为其他用户保留足够的代码空间的风险，可以为总是启动的设备分配最大的速率。此外，UE受益于更快速地接收数据，并且还由于较短的“开启时间”节省了电池寿命。再次地，对于本领域技术人员来说，高数据速率对电流汲取具有非常小的影响，因为不管数据速率如何，对功率放大器进行完全偏置。

在以上实施例中，对于针对UE的给定RRC连接，UTRAN可以使用查找表来确定要为不同的应用分配的无线资源的资源控制简档。简档可以基于用户预订，并在网络实体(例如，HLR)处存储在网络侧，或者备选地，存储在RNC处，因为RNC将具有更多的可用的最新业务资源(即，可以许可的数据速率)。如果可以实现更高的数据速率，更短的超时可以是可能的。

替代APN，可以使用其他备选，例如，在分组数据协议(PDP)上下文激活或修改的PDP上下文中设置的服务质量(QoS)参数。在多个PDP上下文共享相同的APN地址或者预订简档的情况下，QoS字段还可以包括QoS“分配保持优先级”(可以使用服务数据单元来推断业务数据量)，以设置转换简档。其他备选包括信号通知无线控制简档和信息(例如，禁用持续时间和/或每时间窗口的最大指示/请求消息值)的专用消息，例如以上的指示消息。

在无线资源简档中包括的转换简档还可以包括：基于应用的类型，是否完全应该转换UE的状态。具体地，如果正在将用户设备作为数据调制解调器使用，可以在用户设备上设置偏好，以使得不发送转换指示，或者如果在网络处维持对偏好的知识，应该忽略从正在用作数据调制解调器的UE接收的任何转换指示。从而，可以将在用户设备上运行的应用的特性作为无线资源简档的一部分来使用。

转换简档的另一参数可以涉及转换的类型。具体地，在UMTS网络中，用户设备可以由于各种理由优选进入Cell_PCH状态，而不是进入空闲状态。一个理由可以是如果需要发送或接收数据，UE需要更快速地连接到Cell_DCH状态，并从而移动到Cell_PCH状态将会节省一些网络信令和电池资源，同时仍然提供对Cell_DCH状态的快速转换。以上在非UMTS网络中可以同等应用，并且可以提供在各种连接和空闲状态之间的转换简档。

转换简档还可以包括各种定时器，包括但不限于禁止持续时间和/或每时间窗口最大指示/请求消息、延迟定时器和不活动定时器。延迟定时器提供网络单元在转换到新的状态或模式之前将等待的一段时间。如将意识到的，即使应用已经不活动达到特定时间段，为了确保没有其他数据从应用接收或发送，延迟也可以是有好处的。不活动定时器可以测量应用不接收或发送数据的预定时间段。如果在不活动定时器到期之前接收到数据，通常将复位不活动定时器。一旦不活动定时器到期，用户设备从而可以向网络发送步骤1810的指示。备选地，在步骤1810的发送指示之前，用户设备可以等待特定的时间段，例如针对延迟定时器定义的时间段。

此外，延迟定时器或者禁止持续时间和/或每时间窗口的最大指示/请求消息可以基于向网络单元提供的简档而改变。从而，如果已经请求转换到不同的模式或状态的应用是第一类型的应用(例如，电子邮件应用)，可以将网络单元上的延迟定时器设置为第一延迟时间，而如果应用是第二类型的(例如，即时消息应用)，可以将延迟定时器设置为第二值。网络还可以基于针对特定PDP使用的APN导出禁止持续时间和/或每时间窗口的最大指示/请求消息、延迟定时器或不活动定时器的值。

本领域技术人员将意识到，不活动定时器可以基于所使用的应用类似地变化。从而，与浏览器应用相比，电子邮件应用可以具有更短的不活动定时器，因此电子邮件应用预期离散的消息，在这之后，其可以不接收数据。相反，浏览器应用可以使用即使在更长的延迟之后的数据，并从而要求更长的不活动定时器。

转换简档还可以包括对于请求转换用户设备是正确的概率。这可以基于已编译的与特定用户设备或者用户设备上的应用的准确率有关的统计。

转换简档还可以包括各种断续接收(DRX)时间值。此外，可以在转换简档中提供DRX时间的进展简档。

可以逐个应用地定义转换简档，或者转换简档是用户设备上的各种应用的合成。

本领域技术人员将会意识到，可以在分配无线资源时动态地创建或修改转换简档，并且可以在预订、PS注册、PDP激活、RAB或RB激活时进行，或者针对于PDP或RAB/RB动态改变。转换简档还可以是步骤1810的指示的一部分。在该情况下，网络可以考虑优选RRC状态指示，以确定是否允许转换，以及转换到什么状态/模式。可以基于可用的网络资源、业务模式等来发生修改。

因此，无线资源简档由静态和/或动态字段组成。特定网络使用的无线资源简档可以与其他网络的不同，以及以上描述不意味着限制本方法和系统。具体地，无线资源简档可以包括和排除上述各种单元。例如，在一些情况下，无线资源简档将仅包括特定无线资源的服务质量，并且不包括其他信息。在其他情况下，无线资源简档将仅包括转换简档。在又一些情况下，无线资源简档将包括以下所有项：服务质量、APN、PDP上下文、转换简档等。

可选地，除了无线资源简档之外，网络单元还可以使用安全措施来避免不必要的转换。这种安全措施可以包括但不限于预定时间段中接收到的指示的数目、接收到的指示的总数、业务模式以及历史数据。

在预定时间段中接收到的指示的数目可以向网络指示不应该发生转换。从而，如果用户设备在30秒的时间段内已经发送了例如5个指示，网络可以考虑应该忽略该指示，并且不执行任何转换。备选地，网络可以确定向UE指示无穷大的或者在某个所配置或预定的时间段内，UE不应该发送任何进一步指示。这可以独立于UE上的任何“禁止持续时间和/或每时间窗口的最大指示/请求消息”。

此外，UE可被配置为在配置的、预定的或者协商的时间段内，不发送进一步指示。UE配置可以不包括上述网络侧上的安全措施。

业务模式和历史数据可以向网络提供不应该发生转换的指示。例如，如果用户过去从周一至周五在早上8:30到8:35之间已经接收到大量的数据，如果在周四早上8:32接收到指示，网络可以决定其不应该转换用户设备，因为在早上8:35之前很可能有更多数据。

如果为用户设备分配多个无线资源，网络可以需要考虑用户设备的完整的无线资源简档。在该情况下，可以检验每个无线资源的无线资源简档，并做出复合的转换决定。基于一个或多个无线资源的无线资源简档，网络从而可以决定是否应该进行转换。

对转换指示的另一限制

如前所述，存在UE用于转换到其当前RRC状态的各种机制。转换的发起可以全部由网络来驱动，例如，作为观察到不活动的结果。在该示例中，网络为每个RRC状态维持不活动定时器。如果UE的当前RRC状态的不活动定时器到期，则网络将会发送将UE转换到不同状态的RRC重新配置消息。备选地，可以由UE使用上述的转换指示机制(例如，使用转换指示消息)来驱动转换的发起。由于网络控制RRC状态机，在该情况下，UE可以向网络发送指示：其不需要保持在当前RRC状态下，并请求转换到更少电池消耗的RRC状态。

在一个实施例中，对UE发送转换指示的能力进行限制，该限制根据：是否作为先前由UE发送的转换指示的结果，UE经历了最近到其当前状态的转换。

在另一实施例中，UE在其当前状态下可以发送的转换指示的数目根据：是否作为先前由UE发送的转换指示的结果，UE经历了最近到其当前状态的转换。

在另一实施例中，UE在特定状态下可以发送的转换指示的数目受到限制，而与UE经历的至其当前状态的最近转换的方式无关，其中，该当前状态是该限制所应用于的特定状态中的一个。

在从先前发送的传输指示的RRC状态改变之后，禁止任何进一步转换指示

在一些实施例中，如果作为先前已经发送的转换指示的结果，UE处于其当前状态，则禁止UE在该当前状态下时发送任何进一步转换指示。

UE可以维持指示当保持在UE当前状态下时，UE是否被允许向网络发送转换指示的标记、比特令牌或其他指示符。如果在已向网络发送转换指示之后，网络将UE重新配置为新的RRC状态(例如，网络向UE发送重新配置消息，以进行至新RRC状态的转换)，则设置(或者备选地，清除)指示当UE保持在该当前状态下时，UE不被允许发送进一步转换指示的标记、比特令牌或其他指示符。如果UE由于UE(例如，因为它的缓存显示有数据要发送)或网络(例如，因为网络已经寻呼了UE)的数据事务请求而改变RRC状态，则清除(或备选地，设置)该指示符，以指示UE再次被允许向网络发送转换指示。

在从先前发送的转换指示的RRC状态改变之后，禁止多于预定数目的转换指示

在一些实施例中，如果作为先前已经发送的转换指示的结果，UE处于其当前状态，则在网络将UE维持在该相同的当前状态的同时，禁止UE发送任何多于预定最大数目的进一步转换指示。在一些实施例中，将该预定数目硬编码到UE中。在其他实施例中，由网络来配置该预定数目，并且当UE在不同网络之间移动时，改变该预定数目。例如，可以使用直接去往移动台的信令消息，或者作为广播消息的一部分来进行网络配置。

UE维持指示当保持在其当前状态下时，UE是否被允许向网络发送固定数目的转换指示的标记、比特令牌或其他指示符。如果作为在先前的状态中已经发送转换指示的结果，UE已经转换到该当前状态，则将设置该标记、比特令牌或其他指示符。如果例如作为基于不活动定时器的正常网络驱动转换的结果，UE已经转换到该当前状态，则将不设置该标记、比特令牌或其他指示符，以及将不会有对UE在其当前状态下可以发送的转换指示的数目的限制。

在当UE保持在该当前状态下时，将标记、比特令牌或其他指示符设置为指示UE仅被允许向网络发送固定数目的转换指示的情况下，UE可以另外维持计数器，该计数器对在已经确定作为先前发送的转换指示的结果，UE刚转换到其当前状态下之后，由UE发送的转换指示符的数目进行计数。

在该示例中，如果一旦处于当前状态，UE后续需要从该当前状态发送转换指示，其首先查看标记、比特令牌或其他指示符，以确定保持在其当前状态时，在可以向网络发送的转换指示的数目上是否受到限制。如果受到限制，则UE保持对其发送的转换指示的数目的计数，假设网络响应于转换指示，要将UE移动到其当前RRC状态(在UE需要转换到另一RRC状态以发送转换指示消息的情况下)，或者将UE留在其当前状态下(在UE在其当前状态下可以发送转换指示符的情况下)。

如果当UE将其转换指示计数器的值与所允许的进一步转换指示的预定最大数目(很可能由标记、比特令牌或其他指示符来指示)相比较，转换指示计数器的值大于该预定最大数目时，则UE将在后续不向网络发送进一步转换指示。

如果UE发送的转换指示的结果是在发送转换指示之前，UE从其当前状态转换到不同的RRC状态(例如，通过网络发送的重新配置消息)，该不同的RRC状态与当前状态相比更加高度需要电池，则复位计数器，并在新的当前状态中再次开始该过程。例如，如果最终结果是UE被从PCH重新配置到CELL_FACH，则可以是这种情况。

如果UE由于UE(例如，因为它的缓存显示有数据要发送)或网络(例如，因为网络已经寻呼了UE)的数据事务请求而改变RRC状态，则清除(或备选地，设置)该指示符，以指示UE再次被允许向网络发送转换指示，并复位计数器。

禁止多于预定数目的转换指示

在一些实施例中，当网络将UE保持在其相同的当前状态时，UE被禁止发送任何多于预定最大数目的转换指示。在一些实施例中，将该预定数目硬编码到UE上。在其他实施例中，由网络来配置该预定数目，并且当移动台在不同网络之间移动时，改变该预定数目。例如，可以使用直接去往移动台的信令消息，或者作为广播消息的一部分来进行网络配置。

UE维持计数器，该计数器对自其当前状态之后由UE发送的转换指示的数目进行计数。因此，在转换到当前状态，并且UE后续需要发送从其当前状态的转换指示时，假设对转换指示符的网络响应是将UE返回其当前RRC状态(在UE需要转换到另一RRC状态以发送转换指示消息的情况下)或者使UE留在其当前状态(在UE可以在其当前状态发送转换指示符的情况下)，则UE保持对其发送的转换指示的数目的计数。

如果当UE将其转换指示计数器的值与其他转换指示的预定最大数目相比较，转换指示计数器的值大于该预定最大数目时，则UE将在后续不向网络发送进一步转换指示。

如果UE发送的转换指示的结果是在发送转换指示之前，UE从其当前状态被重新配置为不同的RRC状态，该不同的RRC状态与当前状态相比更加高度需要电池，则复位计数器，并在新的当前状态中再次开始该过程。

可以使用是否存在由先前发送转换指示而导致的状态转换，通过各种方式启用/禁用或者限制转换指示的进一步发送：

1)允许发送转换指示的先决条件是，先前的状态转换必须不是UE先前发送转换指示的结果。可以将该先决条件与其他先决条件或禁止相结合，以使得单独满足该先决条件不必然可以允许UE发送转换指示。

2)允许发送转换指示的先决条件是：如果先前的状态转换是UE先前发送转换指示的结果，UE没有发送多于限定数目的转换指示。可以将该先决条件与其他先决条件或禁止相结合，以使得单独满足该先决条件不必然可以允许UE发送转换指示。

3)如果先前的状态转换是UE先前发送转换指示的结果，禁止发送转换指示。这在逻辑上与以上的1)等效。可以将该禁止与其他先决条件或禁止相结合，以使得如果没有触发该禁止，其单独不必然可以允许UE发送转换指示。

4)如果先前的状态转换是UE先前发送转换指示的结果，禁止发送任何多于限定数目的转换指示。这在逻辑上与以上的2)等效。可以将该禁止与其他先决条件或禁止相结合，以使得如果没有触发该禁止，其单独不是必然可以允许UE发送转换指示。

5)如果先前的状态转换不是UE驱动的，允许发送转换指示。

6)如果先前的状态转换是UE先前发送转换指示的结果，仅允许发送最多限定数目的转换指示。

7)对于特定的RRC状态，仅允许发送最多限定数目的转换指示。

与禁止定时器的相互影响

如上指出的，可以将基于状态转换的先决条件或禁止与其他的先决条件或禁止相结合。以上已经描述了在先前发送转换指示之后禁止UE在一段时间内发送转换指示的实施例。在一些实施例中，可以将该禁止与上述基于状态转换的禁止/先决条件相结合。

例如，先前已经将禁止定时器的使用作为在先前发送转换指示之后禁止UE在一段时间内发送转换指示的一个机制来描述，其中，在发送转换指示之后启动禁止定时器，以及仅允许UE在禁止定时器不在运行的情况下发送进一步转换指示。在一些实施例中，将该禁止定时器的使用与基于状态转换的禁止如下相结合：

先前的状态转换是UE先前发送转换指示的结果？禁止发送转换指示，或者在作为UE先前发送转换指示的结果的先前转换之后，禁止发送多于限定数目的转换指示；以及

禁止定时器正在运行？禁止发送转换指示。

在一些实施例中，仅有该两个禁止起作用，在该情况下，可以将行为总结如下：

如果禁止定时器不在运行，并且当前状态不是UE发送的先前转换指示的结果，则允许发送转换指示。

如果禁止定时器不在运行，并且如果在作为UE先前发送转换指示的结果的状态转换之后，已经发送了少于限定数目的转换指示，则允许发送转换指示。

先前状态转换原因维持

UE具有机制来用于维持对当前状态是否是UE先前发送转换指示的结果的指示。该指示可以是存储在UE上可由形成UE的一部分的处理器访问的存储器中的先前状态转换原因值，或者是在硬件中实现的开关(仅列出一些示例)。在特定的示例中，先前状态转换原因是单个比特，该单个比特是第一值(“1”或“0”)以指示先前状态转换是UE先前发送转换指示的结果，否则是第二值(“0”或“1”)。

先前状态转换原因评估

UE具有机制来用于确定当前状态是否是UE先前发送转换指示的结果。

如果UE已经发送了转换指示，并且已经由网络对此进行了肯定应答，使得UE知道网络接收到该转换指示，则UE可以知道，如果其在固定的时间段内接收到RRC重新配置消息，该RRC配置消息是发送转换指示的结果。

如果UE接收到RRC重新配置，并且其在预定的时间段内未曾发送导致重新配置的转换指示(以及被肯定应答)，则UE可以假设状态转换不是响应于UE发送转换指示。

在第一示例中，每次作为网络重新配置的结果而发生状态转换，UE评估状态转换是否是UE先前发送转换指示的结果。如果是这种情况，UE更新先前状态转换原因，以指示先前状态转换是UE驱动的。如果状态指示不是UE先前发送转换指示的结果，则相应地更新先前状态转换原因。

在支持具有原因值的转换的一些实施例中，UE确定其先前是否发送了具有原因值的转换指示，对此，在接收该重新配置之前实现本机制。

在一些实施例中，UE执行以下步骤来确定状态转换是否是UE先前发送转换指示的结果：

1)发送转换指示(或者具有特定原因值的转换指示)；

2)如果在发送转换指示的限定时间间隔内发生与转换指示一致的状态转换，评估状态转换是UE先前发送转换指示的结果，否则，评估状态转换不是UE先前发送转换指示的结果。

在一些实施例中，在发送转换指示时，启动定时器，开始计数，该计数是在超时值处开始的向下计数，或者等效地，向上计数至超时值。如果当发生状态转换时定时器仍在运行，则将其评估为UE先前发送转换指示的结果。

在一些实施例中，使用包括原因代码的转换指示来实现这些实施例中的任意实施例，以允许UE指定转换指示的原因(例如，以指示数据传送或呼叫完成，或者长时间不预期有其他数据)。特定的示例是在3GPP TS 25.331第8.1.14节中定义的信令连接释放指示，其中，原因代码是被设置为“UE请求的PS数据会话结束”的IE“信令连接释放指示原因”。

在一些实施例中，使用不包括原因代码的转换指示来实现这些实施例中的任意实施例。特定的示例是在3GPP TS 25.331第8.1.14节中定义的信令连接释放指示。

确定RRC状态转换的机制的其他示例

如果UE从网络接收到RRC重新配置消息，其可以确定在接收到该重新配置之前，其是否已经发送了具有原因值“UE请求的PS数据会话结束”的SCRI消息。

如果UE已经发送了该消息，以及已经由网络对该消息进行了肯定应答，使得UE知道网络接收到该消息，则UE可以知道如果其在固定的时间段内接收到RRC重新配置消息，该RRC配置消息是发送SCRI的结果。

如果UE处于CELL_DCH或CELL_FACH RRC状态，以及UE已经发送SCRI，该SCRI已被肯定应答，然而网络在固定时间段内没有发送RRC重新配置，则UE可以假设其当前处于网络想要其保持的状态下，UE可以考虑其保持在该状态下的机制是用于快速休眠的目的。

如果UE接收到RRC重新配置，以及其未曾在固定时间段内发送导致重新配置的SCRI消息(并且已被肯定应答)，则UE可以假设该状态转换不是用于快速休眠的目的。

具体示例

参考图1的状态图，假设UE一开始在Cell_DCH状态122下。之后，UE在例如确定其没有更多数据要发送时，发送转换指示。作为响应，网络对转换指示进行肯定应答，并将UE转换至URA_PCH。在一些实施例中，这是直接的状态转换。在其他实施例中，这是经由cell_FACH状态的间接状态转换。在此之后，UE不被允许发送另一转换指示。

注意到，一般而言，也可以将关于URA_PCH状态的实施例和行为的描述应用于CELL_PCH状态。

另一方面，如果网络自己决定将UE转换到URA_PCH(例如，由于不活动定时器到期)，UE被允许发送转换指示。在这点上，UE试图从URA_PCH转换到空闲模式。然而，UE必须转换到CELL_FACH，以发送转换指示。回想到转换指示的目的是将UE移动到具有相对不高度需要电池的状态。如果网络将UE留在CELL_FACH下，这不是转换到更具电池效率的状态(从URA_PCH的仅有的更具电池效率的状态是空闲)，并因此不将CELL_FACH状态视为先前发送转换指示的结果。如果网络在限定的时间段内将UE转换到URA_PCH或空闲模式，则可以将状态转换视为先前发送转换指示的结果。

另一禁止

在一些实施例中，如果UE已经发送了转换指示，该转换指示已被肯定应答，然而网络在固定时间段内没有发送RRC重新配置，则UE假设其当前处于网络想要其保持的状态下。在一些实施例中，当这一系列的事件发生时，禁止UE发送转换指示，尽管当前状态可以不必然是UE先前发送转换指示的结果。

在一些实施例中，仅在UE所保持的状态是CELL_DCH或CELL_FACH RRC状态的情况下实现上述禁止。

由于快速休眠造成的状态

在一些实施例中，当UE处于作为先前发送转换指示的结果的状态下时，认为UE在由调用快速休眠而造成的状态下。在一些实施例中，当UE已经发送转换指示，该转换指示被肯定应答，然而UE没有经历状态改变时，也认为UE在由调用快速休眠而造成的状态下。

如果UE转换到RRC状态(不是空闲状态)，并且这不是因为转换指示(也称为用于快速休眠目的转换指示)，则UE使用禁止定时器来确定何时允许其发送用于快速休眠目的的转换指示。当前在3GPP TS25.331中描述该行为。

如果UE转换到RRC状态(不是空闲状态)，并且这是由于转换指示造成的，则UE将对其行为具有不同的约束。当UE知道其处于这种情况下时，UE将内部设置某种标记或指示。例如，这可以被称为FDM(快速休眠机制)标记。

在一种情况下，UE可以被禁止发送进一步转换指示。备选地，UE可被允许发送对状态转换的进一步请求，然而，进一步请求的数目被限制为某个限定数目，例如，一个或多个。由禁止定时器来控制发送这些请求之间的时间段。

如果当UE使用转换指示来请求状态转换(并且转换指示已被肯定应答)时，网络将UE留在其当前RRC状态(例如，对于CELL_FACH)，或者将其移动回到其发送转换指示的RRC状态(例如，UE曾在CELL_PCH下，移动到CELL_FACH以发送SCRI，然后网络将UE移动回CELL_PCH)，则UE对其被允许发送的剩余转换指示请求的数目进行递减。

如果UE因为发起数据事务而移动到不同的RRC状态(例如，其接收到寻呼并响应该寻呼，或者其请求用于数据事务的资源)，则UE清除FDM标记并重新开始该过程。

如果UE转换到CELL_FACH状态以发送CELL_UPDATE消息或URA_UPDATE消息，并在来自网络的肯定应答中，UE移动回CELL_PCH或URA_PCH状态，则这不清除FDM标记。

然而，如果UE转换到CELL_FACH状态以发送CELL_UPDATE消息或URA_UPDATE消息或转换指示消息，以及网络后续将UE留在CELL_FACH状态，则UE清除FDM标记并重新开始该过程。

在一些情况下，在UE使用具有原因值“UE请求的PS数据会话结束”的SCRI消息响应于快速休眠请求而转换到不同的RRC状态之后，完全防止UE发送SCRI消息。在该情况下，UE设置FDM标记，并仅当其移动到用于数据事务的不同RRC状态时才清除该标记，该数据事务是由UE或网络发起的。

在一些情况下，在特定的预定状态下，UE仅被允许预定的最大数目的转换指示消息。对于不同的状态，该数目可以不同。例如，当处于CELL_PCH或URA_PCH RRC状态时，UE可仅被允许发送“n”个转换指示消息(具有或不具有上述的原因代码)。

在一些实施例中，提供了符合3GPP TS 25.331通用移动电信系统(UMTS)无线资源控制(RRC)协议规范版本8或其演进，并具有修改以便于或实现在此描述的一个或多个实施例的方法和设备。在附录A、附录B和附录C中提供了其示例。所有这些示例涉及SCRI的使用，然而更一般地，可以想到对任何转换指示的使用。

在一些实施例中(参见示例实现的附录A)，定义了UE内部状态变量，在UE第一次从PCH状态内触发FD时设置该UE内部状态变量。如果在然后将UE设置为防止再次从PCH状态内触发FD，当新的PS数据到达以用于发送时，复位该变量。

在一些实施例中(参见示例实现的附录B)，定义计数器V316，并将其初始设置为零。如果V316＜N316(N316是最大值)，允许PCH状态下的UE触发发送具有原因的转换指示(例如，SCRI)。如果UE在PCH状态下确实触发发送转换指示(例如，具有原因值的SCRI)，则V316递增。如果UE在PCH状态下被寻呼，或者如果UE具有可用的上行链路PS数据要转换，将V316复位为零。

如果将N316固定为1，则行为等效于V316是布尔状态变量。注意到，UE具有可用于发送的PS数据明确地排除了发送转换指示(例如，具有原因的SCRI)，并使得复位计数器V316。在该上下文中，例如，UE具有可用PS数据可以意味着用户具有要在RB3(无线承载3)或以上(SCRI消息在RB2上发送)发送的数据。

注意到8.3.1.2(小区更新过程)中的文本提议和8.1.14.2的最后一段是捕获用于复位V316的条件的备选方式。

在一些实施例中(参见示例实现的附录C)，如果网络响应于UE在DCH或FACH状态下发送的转换指示(例如，具有原因的SCRI)将UE移动到PCH状态，禁止UE发送转换指示(例如，具有原因值的SCRI)。可以通过将V316设置为N316来进行禁止转换指示(例如，具有原因值的SCRI)。UE评估该移动是否是由网络“响应于”转换指示来指示的。可以将先前描述的机制用于此，例如，如果在发送转换指示的特定时间内接收到重新配置，则UE可以判断是这种情况。

在一些实施例中，可以将新的标记增加到重新配置消息，如果在网络中通过接收具有原因的SCRI来触发重新配置消息，将该新标记设置为“真”，从而使得UE肯定地知道该重新配置是响应于具有原因值的SCRI的。在附录D中描述其示例。

已经描述了用于禁止发送转换指示的很多不同的实施例，不管是完全地，还是至某个最大数目的转换指示。它们中的很多根据以下的一项或多项：

UE的当前状态是否是先前状态转换的结果；

当前状态是否与UE在发送状态转换之前的状态相同，当前状态是否是比UE在发送状态转换之前的状态更高度需要电池。

在一些实施例中，基于每个状态来实现(或者不实现)用于禁止发送转换指示的机制；在一些实施例中，对于特定的状态，不实现机制。在其他实施例中，针对至少两个状态中的每一个使用不同的机制。

在一个实施例中，当在步骤1810中接收到指示，并在步骤1820中可选地检验无线资源简档时，关于如何继续进行，网络有多个选择。

第一选项是什么都不做。网络可以决定转换是没有保证的，并从而不接受用户设备对转换的指示。本领域技术人员将意识到，什么都不做节省了网络信令，因为状态没有改变，以及具体地，因为没有触发转换。

第二选项是改变设备的状态。例如，在UMTS网络中，设备的状态可以从Cell_DCH改变到Cell_PCH。在非UMTS网络中，状态转换可以发生在连接状态之间。本领域技术人员将意识到，当与转换到空闲模式相比时，改变状态降低了核心网信令的数量。改变状态还可以节省无线资源，因为Cell_PCH状态不要求专用信道。此外，Cell_PCH是相对不高度需要电池的状态，使得UE保留了电池功率。

网络的第三选项是将UE保持在相同的状态下，然而释放与特定APN或PDP上下文相关联的无线资源。该方案节省了无线资源和信令，因为连接维持在其当前状态下，并且不需要被重新建立。然而，这可能较不适于关注UE电池寿命的情况。

网络的第四选项是将UE转换到空闲模式。具体地，在UMTS和非UMTS中，网络可以从连接模式移动到空闲模式。将会意识到，这节省了无线资源，因为根本没有连接要维持。这还节省了用户设备上的电池寿命。然而，要求更大量的核心网信令来重新建立连接。

网络的第五选项是改变数据速率分配，这将节省无线资源，通常允许更多用户使用网络。

其他选项对本领域技术人员是显而易见的。

网络关于使用这5个或更多选项中的哪一个的决定将随着网络而改变。一些过载的网络可以优选保留无线资源，并从而可选择以上的第三、第四或第五选项。其他网络优选最小化信令，并从而可以选择以上的第一或第二选项。

图18中在步骤1830示出了该决定，以及该决定可以基于网络偏好以及用户设备的无线资源简档。可以由网络从用户设备接收用户设备想要转换到另一状态(例如，转换到相对不高度需要电池的状态)的指示来触发该决定。

现在参考图19。图19示出了适于进行以上图18中示出的决定的简化网络单元。网络单元1910包括适于与用户设备通信的通信子系统1920。本领域技术人员将意识到，通信子系统1920不需要与用户设备直接通信，而是可以是去往和来自用户设备的通信的通信路径的一部分。

网络单元1910还包括处理器1930和存储器1940。存储器1940适于针对由网络单元1910提供服务的每个用户设备来存储预配置或静态的无线资源简档。处理器1930适于在接收到通信子系统1920的指示时，考虑用户设备的无线资源简档，并对与转换用户设备有关的网络动作作出决定。本领域技术人员将意识到，通信子系统1920接收到的指示还可以包括用户设备的无线资源简档的一部分或全部，该无线资源简档的一部分或全部然后可以由处理器1930用来作出与任何的转换有关的网络决定。

基于以上方案，网络单元因此从用户设备接转换可以准备就绪(例如，如当数据交换完成和/或在UE处不预期有其他数据时)。基于该指示，网络单元可选地检查用户设备的无线资源简档，该无线资源简档可以包括静态以及动态的简档单元。网络单元还可以检查确保不发生没有必要的转换的安全措施。然后，网络单元可以决定什么都不做，或者转换到不同的模式或状态，或者拆除无线资源。将意识到，这向网络提供了对其无线资源的更多控制，并允许网络基于网络偏好而不是仅基于用户设备偏好来配置转换决定。此外，在一些情况下，关于是否转换，网络比设备具有更多的信息。例如，用户设备知道上行流通信，并基于此，可以决定连接可被断开。然而，网络可以已经接收到针对用户设备的下行流通信，并从而认识到其不能拆除连接。在该情况下，也可以使用延迟定时器来引入延迟，以向网络提供对在不久的将来将不会从用户设备接收到数据的更多确定性。

在此描述的实施例是具有与本公开的技术要素相对应的要素的结构、系统或方法的示例。该书面描述可以使本领域技术人员作出和使用具有备选要素的实施例，该备选要素同样对应于本公开的技术要素。从而，本公开的技术的预期范围包括与在此描述的本公开的技术没有区别的其他结构、系统或方法，以及还包括与在此描述的本公开的技术没有实质区别的其他结构、系统或方法。

附录A

8.1.14信令连接释放指示过程

图8.1.14-1：正常情况下的信令连接释放指示过程

8.1.14.1概述

UE使用信令连接释放指示过程来指示UTRAN其信令连接中的一条已被释放。该过程可进而发起RRC连接释放过程。

8.1.14.2发起

针对特定的CN域，UE应该在从高层接收到释放(放弃)信令连接时：

1>如果针对利用IE“CN域标识”来标识的特定CN域，存在变量ESTABLISHED_SIGNALLING_CONNECTIONS：

2>发起信令连接释放指示过程。

1>否则：

2>如8.1.3.5a中所指定的，针对该特定的CN域，放弃任何正在进行的信令连接建立。

当在CELL_PCH或URA_PCH状态下发起信令连接释放指示过程时，UE应该：

1>如果将变量READY_FOR_COMMON_EDCH设置为“真”：

2>移动至CELL_FACH状态；

2>如果已经通过将IE“连接模式下的UE定时器和常数”中的T305设置为除“无穷大”之外的任何值来配置周期性小区更新，使用定时器T305的初始值来重新启动定时器T305。

1>否则：

2>如果设置了变量H_RNTI和变量C_RNTI：

3>继续如下的信令连接释放指示过程。

2>否则：

3>使用原因“上行链路数据发送”来根据子条款8.3.1执行小区更新过程；

3>当小区更新过程成功完成时：

4>继续如下的信令连接释放指示过程。

UE应该：

1>将IE“CN域标识”设置为由高层来指示的值。该IE的值指示了其相关信令连接被高层标记为要释放的CN域。

1>将具有由高层所指示的标识的信令连接从变量ESTABLISHED_SIGNALING_CONNECTIONS移除。

1>使用AM RLC在DCCH上发送信令连接释放指示消息。

当已经由RLC确认了信令连接释放指示消息的成功传送时，过程结束。

此外，如果将定时器T323值存储在变量TIMERS_AND_CONSTANTS中的IE“连接模式下的UE定时器和常数”中，以及如果在变量ESTABLISHED_SIGNALLING_CONNECTIONS中没有指示CS域连接，UE可以：

1>如果高层指示长期不再有PS数据：

2>如果定时器T323没有运行：

3>如果UE在CELL_DCH状态或CELL_FACH状态下；或者

3>如果UE在CELL_PCH状态或URA_PCH状态下，以及变量TRIGGERED_SCRI_IN_PCH_STATE中的“已触发”为“假”：

4>如果UE在CELL_PCH或URA_PCH状态下，将变量TRIGGERED_SCRI_IN_PCH_STATE中的“已触发”设置为“真”；

4>将IE“CN域标识”设置为PS域；

4>将IE“信令连接释放指示原因”设置为“UE请求的PS数据会话结束”；

4>使用AM RLC在DCCH上发送信令连接释放指示消息；

4>启动定时器T323。

当定时器T323正在运行时，应该禁止UE发送IE“信令连接释放指示原因”被设置为“UE请求的PS数据会话结束”的信令连接释放指示消息。

在发送IE“信令连接释放指示原因”被设置为“UE请求的PS数据会话结束”的信令连接释放指示消息之后，如果PS数据变得可用于发送，则UE应该将变量TRIGGERED_SCRI_IN_PCH_STATE中的“已触发”设置为“假”。

8.1.14.2a RLC重新建立或RAT间改变

如果在RLC已经确认信令连接释放指示消息的成功传送之前，在信令无线承载RB2上发生RLC实体的发送侧的重新建立，UE应该：

1>在信令无线承载RB2上，使用AM RLC在上行链路DCCH上重传信令连接释放指示消息。

如果在RLC已经确认信令连接释放指示消息的成功传送之前，发生来自UTRAN过程的RAT间切换，UE应该：

1>当在新的RAT中时放弃信令连接。

8.1.14.3UTRAN接收信令连接释放指示

在接收到信令连接释放指示消息时，如果没有包括IE“信令连接释放指示原因”，UTRAN从高层请求释放信令连接。然后，高层可以发起信令连接的释放。

如果IE“信令连接释放指示原因”包括在信令连接释放指示消息中，UTRAN可以发起至具有高效电池消耗的空闲、CELL_PCH、URA_PCH或CELL_FACH状态的状态转换。

8.1.14.4定时器T323到期

当定时器T323到期时：

1>UE可以确定是否有来自高层的对长期不再有PS数据的任何后续指示，在该情况下，根据子条款8.1.14.2，其触发单个信令连接释放指示消息的发送；

1>过程结束。

13.4.27x TRIGGERED_SCRI_IN_PCH_STATE

该变量包含与在CELL_PCH或URA_PCH状态下是否已经触发了信令连接释放指示消息有关的信息。在UE中有一个这样的变量。

附录B

8.1.14信令连接释放指示过程

图8.1.14-1：正常情况下的信令连接释放指示过程

8.1.14.1概述

8.1.14.2发起

2>发起信令连接释放指示过程。

1>否则：

1>如果将变量READY_FOR_COMMON_EDCH设置为“真”：

2>移动至CELL_FACH状态；

1>否则：

2>如果设置了变量H_RNTI和变量C_RNTI：

3>继续如下的信令连接释放指示过程。

2>否则：

3>当小区更新过程成功完成时：

4>继续如下的信令连接释放指示过程。

UE应该：

1>使用AM RLC在DCCH上发送信令连接释放指示消息。

此外，如果将定时器T323值存储在变量TIMERS_AND_CONSTANTS中的IE“连接模式下的UE定时器和常数”中，以及如果在变量ESTABLISHED_SIGNALLING_CONNECTIONS中没有指示CS域连接，UE应该：

1>如果高层指示长期不再有PS数据：

2>如果定时器T323没有运行：

3>如果UE在CELL_DCH状态或CELL_FACH状态下；或者

3>如果UE在CELL_PCH状态或URA_PCH下，以及V316＜N316：

4>如果UE在CELL_PCH或URA_PCH下，将V316递增1；

4>将IE“CN域标识”设置为PS域；

4>使用AM RLC在DCCH上发送信令连接释放指示消息；

4>启动定时器T323。

如果PS数据变得可用于发送，或者UE接收到触发小区更新过程的寻呼消息，则UE应该将V316设置为0。

8.1.14.2aRLC重新建立或RAT间改变

1>当在新的RAT中时放弃信令连接。

8.1.14.3UTRAN接收信令连接释放指示

8.1.14.4定时器T323到期

当定时器T323到期时：

1>UE可以确定是否有来自高层的对长期不再有PS数据的任何后续指示，在该情况下，根据子条款8.1.14.2，其触发单个信令连接释放指示消息的发送。

1>过程结束。

8.3RRC连接移动性过程

8.3.1小区和URA更新过程

图8.3.1-1：小区更新过程，基本流程

图8.3.1-2：更新UTRAN移动性信息情况下的小区更新过程

图8.3.1-3：物理信道重新配置情况下的小区更新过程

图8.3.1-4：传输信道重新配置情况下的小区更新过程

图8.3.1-5：无线承载释放情况下的小区更新过程

图8.3.1-6：无线承载重新配置情况下的小区更新过程

图8.3.1-6a：无线承载建立情况下的小区更新过程

图8.3.1-7：故障情况下的小区更新过程

图8.3.1-8：URA更新过程，基本流程

图8.3.1-9：更新UTRAN移动性信息情况下的URA更新过程

图8.3.1-10：故障情况下的URA更新过程

8.3.1.1概述

URA更新和小区更新过程服务于多个主要目的：

-在URA_PCH或CELL_PCH状态下重新进入服务区之后通知UTRAN；

-向UTRAN通知AM RLC实体上的RLC不可恢复错误[16]；

-通过周期性更新的方式，被用作CELL_FACH、CELL_PCH或URA_PCH状态下的监督机制。

此外，URA更新过程还服务于以下目的：

-在小区重选至不属于向URA_PCH状态下的UE分配的当前URA的小区之后，检索新的URA标识。

此外，小区更新过程还服务于以下目的：

-使用在小区重选之后UE正驻留的当前小区来更新UTRAN；

-对CELL_DCH状态下的无线链路故障进行动作；

-对UE能力信息消息的传输故障进行动作；

-对于FDD和1.28Mcp TDD，如果没有设置变量H_RNTI，以及对于3.84McpTDD和7.68Mcp TDD：当在URA PCH或CELL_PCH状态下触发时，向UTRAN通知由于接收到源自UTRAN的寻呼或者由于对发送上行链路数据的请求而造成的至CELL_FACH状态的转换；

-计数在URA_PCH、CELL_PCH和CELL_FACH下的对接收MBMS传输感兴趣的UE的数目；

-当在URA_PCH、CELL_PCH和CELL_FACH状态下触发时，向UTRAN通知对接收MBMS服务感兴趣的UE；

-由CELL_PCH、URA_PCH和CELL_FACH状态下的UE来请求MBMS P-T-P RB建立。

URA更新和小区更新过程可以：

1>包括UE中的移动性相关信息的更新；

1>产生从CELL_FACH状态至CELL_DCH、CELL_PCH或URA_PCH状态或者空闲模式的状态转换。

小区更新过程还可以包括：

-AM RLC实体的重新建立；

-无线承载释放、无线承载重新配置、传输信道重新配置或物理信道重新配置。

8.3.1.2发起

UE应该在以下情况下发起小区更新过程：

1>上行链路数据传输：

2>对于FDD和1.28Mcp TDD，如果没有设置变量H_RNTI，以及对于3.84McpTDD和7.68Mcp TDD：

3>如果UE在URA_PCH或CELL_PCH状态下；以及

3>如果定时器T320没有运行：

4>如果UE在RB1或以上有上行链路RLC数据PDU或上行链路RLC控制PDU要发送：

5>使用原因“上行链路数据传输”来执行小区更新。

3>否则：

4>如果设置了变量ESTABLISHMENT_CAUSE：

5>使用原因“上行链路数据传输”来执行小区更新。

1>寻呼响应：

2>如果没有满足当前子条款中用于利用以上指定的原因来执行小区更新的准则；以及

2>如果在URA_PCH或CELL_PCH状态下的UE接收到寻呼类型1消息，该寻呼类型1消息满足子条款8.1.2.3中指定的用于发起小区更新过程的条件：

3>使用原因“寻呼响应”来执行小区更新。

1>无线链路故障：

2>如果没有满足当前子条款中用于利用以上指定的原因来执行小区更新的任何准则；

3>如果UE在CELL_DCH状态下，以及满足子条款8.5.6中指定的无线链路故障准则；或者

3>如果如子条款8.1.6.6中所指定的，UE能力信息消息的传输失败了：

4>使用原因“无线链路故障”来执行小区更新。

1>MBMS ptp RB请求：

2>如果没有满足当前子条款中用于利用以上指定的原因来执行小区更新的任何准则；以及

2>如果UE在URA_PCH、Cell_PCH或Cell_FACH状态下；以及

2>如果定时器T320没有运行；以及

2>如果如子条款8.6.9.6中所指定的，UE应该执行针对MBMSptp无线承载请求的小区更新：

3>使用原因“MBMS ptp RB请求”来执行小区更新。

1>重新进入服务区：

2>如果UE在CELL_FACH或CELL_PCH状态下；以及

2>如果UE已经离开服务区，并在T307或T317到期之前重新进入服务区：

3>使用原因“重新进入服务区”来执行小区更新。

1>RLC不可恢复错误：

2>如果UE检测到AM RLC实体中的RLC不可恢复错误[16]:

3>使用原因“RLC不可恢复错误”来执行小区更新。

1>小区重选：

3>如果UE处于CELL_FACH或CELL_PCH状态，以及UE执行小区重选；或者

3>如果UE处于CELL_FACH状态以及变量C_RNTI是空的：

4>使用原因“小区重选”来执行小区更新。

1>周期性小区更新：

2>如果UE在CELL_FACH或CELL_PCH状态下；以及

2>如果定时器T305到期；以及

2>如果满足子条款8.5.5.2中指定的“在服务区中”的准则；以及

2>如果已经通过将IE“连接模式下的UE定时器和常数”中的T305设置为除“无穷大”之外的任何其他值来配置了周期性更新：

3>对于FDD：

4>如果将变量COMMON_E_DCH_TRANSMISSION设置为假：

5>使用原因“周期性小区更新”来执行小区更新。

4>否则：

5>重新启动定时器T305：

5>以及结束过程。

3>对于1.28Mcp TDD和3.84/7.68Mcp TDD：

4>使用原因“周期性小区更新”来执行小区更新。

1>MBMS接收：

2>如果UE在URA_PCH、Cell_PCH或Cell_FACH状态下；以及

2>如果如子条款8.7.4中所指定的，UE应该执行针对MBMS计数的小区更新：

3>使用原因“MBMS接收”来执行小区更新。

URA_PCH状态下的UE应该在以下情况下发起URA更新过程：

1>URA重选：

2>如果UE检测到向UE分配的当前URA(存储在变量URA_IDENTITY中)没有出现在系统信息块类型2中的URA标识的列表中；或者

2>如果系统信息块类型2中的URA标识的列表是空的；或者

2>如果不能够发现系统信息块类型2：

3>使用原因“URA改变”来执行URA更新。

1>周期性URA更新：

2>如果没有满足当前子条款中用于利用以上指定的原因来执行URA更新的准则

3>如果定时器T305到期，以及如果已经通过将IE“连接模式下的UE定时器和常数”中的T305设置为除“无穷大”之外的任何其他值来配置了周期性更新；或者

3>如果满足子条款8.1.1.6.5中指定的用于发起URA更新过程的条件：

4>使用原因“周期性URA更新”来执行URA更新。

当发起URA更新或小区更新过程时，UE应该：

1>如果UE在RB3或以上有上行链路RLC数据PDU或上行链路RLC控制PDU要发送；或者

1>如果UE接收到寻呼类型1消息，该寻呼类型1消息满足子条款8.1.2.3中指定的用于发起小区更新过程的条件：

2>将计数器V316设置为零。

1>如果定时器T320正在运行：

2>停止定时器T320；

2>如果UE在RB1或以上有上行链路RLC数据PDU或上行链路RLC控制PDU要发送：

3>使用原因“上行链路数据传输”来执行小区更新。

2>否则：

3>如果由于寻呼响应或者无线链路故障而没有触发小区更新过程；以及

3>如果如子条款8.6.9.6中所指定的，UE应该执行针对MBMSptp无线承载请求的小区更新：

4>使用原因“MBMS ptp RB请求”来执行小区更新。

1>如果定时器T319正在运行，停止定时器T319；

1>停止定时器T305；

1>针对FDD和1.28Mcp TDD：

2>如果UE在CELL_FACH状态下；以及

2>如果IE“HS-DSCH公共系统信息”包括在系统信息块类型5或系统信息块类型5bis中；以及

2>对于1.28Mcp TDD，如果IE“公共E-DCH系统信息”在系统信息块类型5中；以及

2>如果UE不支持CELL_FACH状态下的HS-DSCH接收：

3>如果没有设置变量H_RNTI或者没有设置变量C_RNTI：

4>清除变量H_RNTI；

4>清除变量C_RNTI；

4>清除任何存储的IE“HARQ信息”；

4>将变量HS_DSCH_RECEPTION_OF_CCCH_ENABLED设置为真；

4>以及，根据子条款8.5.37中的过程，通过使用IE“HS-DSCH公共系统信息”给出的参数，开始接收HS-DSCH传输信道映射的类型HS-SCCH和HS-PDSCH的物理信道。

3>否则：

4>根据子条款8.5.36中的过程，通过使用IE“HS-DSCH公共系统信息”给出的参数，接收HS-DSCH传输信道映射的类型HS-SCCH和HS-PDSCH的物理信道；

4>确定HSPA_RNTI_STORED_CELL_PCH变量的值，并采取子条款8.5.56中描述的对应动作；

4>确定READY_FOR_COMMON_EDCH变量的值，并采取子条款8.5.47中描述的对应动作；

4>确定COMMON_E_DCH_TRANSMISSION变量的值，并采取子条款8.5.46中描述的对应动作；

4>如果将变量READY_FOR_COMMON_EDCH设置为“真”：

5>对于FDD，如子条款8.5.45所指定地，以及对于1.28Mcp TDD，如子条款8.5.45a所指定地配置CELL_FACH状态和空闲模式下的增强型上行链路。

1>如果UE在CELL_DCH状态下；

2>在RB_TIMER_INDICATOR变量中，将IE“T314到期”和IE“T315到期”设置为假；

2>如果存储的定时器T314和定时器T315的值都等于零；或者

2>如果存储的定时器T314的值等于零，以及没有与任何的无线接入承载相关联的无线承载，针对该无线接入承载，在变量ESTABLISHED_RABS中，IE“重新建立定时器”的值被设置为“使用T315”，以及仅针对于CS域存在信令连接：

3>释放其所有的无线资源；

3>向高层指示释放(放弃)所建立的信令连接(存储在变量ESTABLISHED_SIGNALLING_CONNECTIONS中)和所建

立的无线接入承载(存储在变量ESTABLISHED_RABS中)；

3>清除变量ESTABLISHED_SIGNALLING_CONNECTIONS；

3>清除变量ESTABLISHED_RABS；

3>进入空闲模式；

3>执行子条款8.5.2所指定的当从连接模式进入空闲模式时的其他动作；

3>以及，过程结束。

2>如果所存储的定时器T314的值等于零：

3>释放与任何无线接入承载相关联的所有的无线承载，针对该无线接入承载，在变量ESTABLISHED_RABS中，将IE“重新建立定时器”的值设置为“使用T314”；

3>在变量RB_TIMER_INDICATOR中，将IE“T314到期”设置为真；

3>如果释放了与CN域相关联的所有无线接入承载：

4>释放针对该CN域的信令连接；

4>从变量ESTABLISHED_SIGNALLING_CONNECTIONS移除针对该CN域的信令连接；

4>向高层指示信令连接的释放(放弃)；

2>如果所存储的定时器T315的值等于零：

3>释放与任何无线接入承载相关联的所有的无线承载，针对该无线接入承载，在变量ESTABLISHED_RABS中，将IE“重新建立定时器”的值设置为“使用T315”；

3>在变量RB_TIMER_INDICATOR中，将IE“T315到期”设置为真。

3>如果释放了与CN域相关联的所有无线接入承载：

4>释放针对该CN域的信令连接；

4>向高层指示信令连接的释放(放弃)；

2>如果所存储的定时器T314的值大于零：

3>如果有与任何无线接入承载相关联的无线承载，针对该无线接入承载，在变量ESTABLISHED_RABS中，将IE“重新建立定时器”的值设置为“使用T314”：

4>启动定时器T314。

3>如果没有与任何无线接入承载相关联的无线承载，针对该无线接入承载，在变量ESTABLISHED_RABS中，将IE“重新建立定时器”的值设置为“使用T314”或“使用T315”，以及存在针对CS域的信令连接：

4>启动定时器T314。

2>如果所存储的定时器T315的值大于零：

3>如果有与任何无线接入承载相关联的无线承载，针对该无线接入承载，在变量ESTABLISHED_RABS中，将IE“重新建立定时器”的值设置为“使用T315”；或者

3>如果存在针对PS域的信令连接：

4>启动定时器T315。

2>针对所释放的无线承载：

3>从变量ESTABLISHED_RABS删除与该无线承载有关的信息；

3>当已经释放属于相同无线接入承载的所有无线承载时：

4>使用CN域标识和存储在变量ESTABLISHED_RABS中的RAB标识来向高层指示无线接入承载的本地端释放；

4>从变量ESTABLISHED_RABS删除与该无线接入承载有关的所有信息。

2>如果将变量E_DCH_TRANSMISSION设置为“真”：

3>将变量E_DCH_TRANSMISSION设置为假；

3>停止任何的E-AGCH和E-HICH接收过程；

3>对于FDD，停止任何的E-RGCH接收过程。

3>对于FDD，停止任何的E-DPCCH和E-DPDCH传输过程。

3>对于1.28Mcp TDD，停止任何的E-PUCH传输过程。

3>清除变量E_RNTI；

3>如同IE“MAC-es/e复位指示符”被接收到并被设置为真一样地进行动作；

3>释放所有的E-DCH HARQ资源；

3>不再考虑要被作为服务E-DCH无线链路的任何无线链路。

2>移动至CELL_FACH状态；

2>根据[4]选择当前频率上的适合的UTRA小区；

2>清除变量E_RNTI，以及：

3>确定HSPA_RNTI_STORED_CELL_PCH变量的值，并采取子条款8.5.56中描述的对应动作；

3>确定READY_FOR_COMMON_EDCH变量的值，并采取子条款8.5.47中描述的对应动作；

3>确定COMMON_E_DCH_TRANSMISSION变量的值，并采取子条款8.5.46中描述的对应动作。

2>针对3.84Mcp TDD和7.68Mcp TDD；或者

2>针对FDD和1.28Mcp TDD，如果UE不支持CELL_FACH状态下的HS-DSCH接收；或者

2>如果IE“HS-DSCH公共系统信息”没有包括在系统信息块类型5或系统信息块类型5bis中；或者

2>对于1.28Mcp TDD，如果IE“公共E-DCH系统信息”没有包括在系统信息块类型5中：

3>根据子条款8.5.17选择PRACH；

3>根据子条款8.5.19选择辅助CCPCH；

3>使用在子条款8.6.5.1中指定的系统信息中给出的传输格式设置；

3>采用在子条款8.5.37a中描述的与HS_DSCH_RECEPTION_GENERAL变量有关的动作。

2>否则：

3>如果将变量READY_FOR_COMMON_EDCH设置为“真”：

4>如子条款8.5.45中指定的，配置CELL_FACH状态和空闲模式下的增强型上行链路。

3>否则：

4>根据子条款8.5.17选择PRACH，以及：

5>将在子条款8.6.5.1中指定的系统信息中给出的传输格式设置用于PRACH。

3>清除变量H_RNTI；

3>清除任何存储的IE“HARQ信息”；

3>复位MAC-ehs实体[15]；

3>将变量HS_DSCH_RECEPTION_OF_CCCH_ENABLED设置为真；

3>以及，根据子条款8.5.37中的过程，开始接收HS-DSCH。

2>将变量ORDERED_RECONFIGURATION设置为假。

1>将变量PROTOCOL_ERROR_INDICATOR、FAILURE_INDICATOR、UNSUPPORTED_CONFIGURATION和INVALID_CONFIGURATION设置为假；

1>将变量CELL_UPDATE_STARTED设置为真；

1>如果将与HS-DSCHare有关的任何IE存储在UE中：

2>清除任何所存储的IE“下行链路HS-PDSCH信息”；

2>清除任何所存储的IE“下行链路辅助小区信息FDD”；

2>从变量TARGET_CELL_PRECONFIGURATION中清除所有的项；

2>针对1.28Mcp TDD，清除IE“DL多载波信息”中的IE“HS-PDSCH训练序列配置”以及“HS-SCCH设置配置”；

2>确定HS_DSCH_RECEPTION变量的值，并采取子条款8.5.25中描述的对应动作；

2>确定SECONDARY_CELL_HS_DSCH_RECEPTION变量的值，并采取子条款8.5.51中描述的对应动作。

1>如果将与E-DCH有关的任何IE存储在UE中：

2>清除任何存储的IE“E-DCH信息”；

2>确定E_DCH_TRANSMISSION变量的值，并采取子条款8.5.28中描述的对应动作。

1>如果将IE“DTX-DRX定时信息”或“DTX-DRX信息”中的任何IE存储在UE中：

2>确定DTX_DRX_STATUS变量的值，并采取子条款8.5.34中描述的对应动作。

1>如果将IE“HS-SCCH少量信息”存储在UE中：

2>确定HS_SCCH_LESS_STATUS变量的值，并采取子条款8.5.35中描述的对应动作。

1>如果将与MIMO有关的任何IE存储在UE中：

2>确定MIMO_STATUS变量的值，并采取子条款8.5.33中描述的对应动作。

1>针对1.28Mcp TDD，如果IE“控制信道DRX信息”存储在UE中：

2>确定CONTROL_CHANNEL_DRX_STATUS变量的值，并采取子条款8.5.53中描述的对应动作。

1>针对1.28Mcp TDD，如果IE“SPS信息”存储在UE中：

2>确定E_DCH_SPS_STATUS变量的值，并采取子条款8.5.54中描述的对应动作；

2>确定HS_DSCH_SPS_STATUS变量的值，并采取子条款8.5.36中描述的对应动作。

1>如果UE已不在CELL_FACH状态下；

2>移动至CELL_FACH状态；

2>确定HSPA_RNTI_STORED_CELL_PCH变量的值，并采取子条款8.5.56中描述的对应动作；

2>确定READY_FOR_COMMON_EDCH变量的值，并采取子条款8.5.47中描述的对应动作；

2>确定COMMON_E_DCH_TRANSMISSION变量的值，并采取子条款8.5.46中描述的对应动作；

2>针对3.84Mcp TDD和7.68Mcp TDD；或者

3>根据子条款8.5.17选择PRACH；

3>根据子条款8.5.19选择辅助CCPCH；

3>采用在子条款8.5.37a中描述的与

HS_DSCH_RECEPTION_GENERAL变量有关的动作。

2>否则：

3>如果将变量READY_FOR_COMMON_EDCH设置为“真”：

3>否则：

4>根据子条款8.5.17选择PRACH，以及；

3>如果没有设置变量H_RNTI或者没有设置变量C_RNTI：

4>清除变量C_RNTI；

4>清除变量H_RNTI；

4>清除任何存储的IE“HARQ信息”；

4>将变量HS_DSCH_RECEPTION_OF_CCCH_ENABLED设置为真；

4>以及，根据子条款8.5.37中的过程，开始接收HS-DSCH。

3>否则：

4>根据子条款8.5.36中的过程，接收HS-DSCH。

1>如果UE执行小区重选：

2>清除变量C_RNTI；以及

2>停止在MAC中使用刚从变量C_RNTI清除的该C_RNTI；

2>针对FDD和1.28Mcp TDD，如果设置了变量H_RNTI：

3>清除变量H_RNTI；以及

3>停止在MAC中使用刚从变量H_RNTI清除的该H_RNTI；

3>清除任何存储的IE“HARQ信息”；

2>针对FDD和1.28Mcp TDD，如果设置了变量E_RNTI：

3>清除变量E_RNTI。

2>针对FDD和1.28Mcp TDD，如果的确支持CELL_FACH状态下的HS-DSCH接收，以及IE“HS-DSCH公共系统信息”包括在系统信息块类型5或系统信息块类型5bis中：

3>复位MAC-ehs实体[15]。

3>将变量HS_DSCH_RECEPTION_OF_CCCH_ENABLED设置为真；

3>以及，根据子条款8.5.37中的过程，开始接收HS-DSCH。

2>否则：

3>采用在子条款8.5.37a中描述的与

HS_DSCH_RECEPTION_GENERAL变量有关的动作。

1>根据子条款8.5.15，将CFN与当前小区的SFN有关地进行设置；

1>在小区更新过程的情况下：

2>根据子条款8.3.1.3设置小区更新消息的内容；

2>在上行链路CCCH上提交小区更新消息以用于发送。

1>在URA更新过程的情况下：

2>根据子条款8.3.1.3设置URA更新消息的内容；

2>在上行链路CCCH上提交URA更新消息以用于发送。

1>将计数器V302设置为1；

1>当MAC层指示发送消息的成功或失败时，启动定时器T302。

10.3.3.43连接模式下的UE定时器和常数

该信息单元指定了连接模式下的UE使用的定时器和常数值。

13.4.27x TRIGGERED_SCRI_IN_PCH_STATE

该变量包含与在CELL_PCH或URA_PCH状态下是否已经触发了信令连接释放指示消息有关的信息。在UE中存在一个这样的变量。

13.2UE的计数器

13.3UE常数和参数

13.2UE的计数器

13.3UE常数和参数

附录C

8.1.14信令连接释放指示过程

图8.1.14-1：正常情况下的信令连接释放指示过程

8.1.14.1概述

8.1.14.2发起

2>发起信令连接释放指示过程。

1>否则：

1>如果将变量READY_FOR_COMMON_EDCH设置为“真”：

2>移动至CELL_FACH状态；

1>否则：

2>如果设置了变量H_RNTI和变量C_RNTI：

3>继续如下的信令连接释放指示过程。

2>否则：

3>当小区更新过程成功完成时：

4>继续如下的信令连接释放指示过程。

UE应该：

1>使用AM RLC在DCCH上发送信令连接释放指示消息。

1>如果高层指示长期不再有PS数据：

2>如果定时器T323没有运行：

3>如果UE在CELL_DCH状态或CELL_FACH状态下；或者

3>如果UE在CELL_PCH状态或URA_PCH下，以及V316＜N316：

4>如果UE在CELL_PCH或URA_PCH下，将V316递增1；

4>将IE“CN域标识”设置为PS域；

4>使用AM RLC在DCCH上发送信令连接释放指示消息；

4>启动定时器T323。

如果PS数据变得可用于发送，或者UE接收到触发小区更新过程的寻呼消息，则UE应该将V316设置为0。如果在CELL_DCH或CELL_FACH状态下，UE发送IE“信令连接释放指示原因”被设置为“用户请求的PS数据会话结束”的信令连接释放指示消息，并作为响应，UE接收将UE转换到CELL_PCH状态或URA_PCH状态的重新配置消息，则UE应该将V316设置为N316。如果重新配置消息在500ms内接收到，UE应该将其认为是对信令连接释放指示消息的响应。

8.1.14.2aRLC重新建立或RAT间改变

1>当在新的RAT中时放弃信令连接。

8.1.14.3UTRAN接收信令连接释放指示

8.1.14.4定时器T323到期

当定时器T323到期时：

1>过程结束。

8.3RRC连接移动性过程

8.3.1小区和URA更新过程

图8.3.1-1：小区更新过程，基本流程

图8.3.1-2：更新UTRAN移动性信息情况下的小区更新过程

图8.3.1-3：物理信道重新配置情况下的小区更新过程

图8.3.1-4：传输信道重新配置情况下的小区更新过程

图8.3.1-5：无线承载释放情况下的小区更新过程

图8.3.1-6：无线承载重新配置情况下的小区更新过程

图8.3.1-6a：无线承载建立情况下的小区更新过程

图8.3.1-7：故障情况下的小区更新过程

图8.3.1-8：URA更新过程，基本流程

图8.3.1-9：更新UTRAN移动性信息情况下的URA更新过程

图8.3.1-10：故障情况下的URA更新过程

8.3.1.1概述

URA更新和小区更新过程服务于多个主要目的：

-在URA_PCH或CELL_PCH状态下重新进入服务区之后通知UTRAN；

-向UTRAN通知AM RLC实体上的RLC不可恢复错误[16]；

此外，URA更新过程还服务于以下目的：

此外，小区更新过程还服务于以下目的：

-使用在小区重选之后UE正驻留的当前小区来更新UTRAN；

-对CELL_DCH状态下的无线链路故障进行动作；

-对UE能力信息消息的传输故障进行动作；

-对于FDD和1.28Mcp TDD，如果没有设置变量H_RNTI，以及对于3.84McpTDD和7.68Mcp TDD：当在URA_PCH或CELL_PCH状态下触发时，向UTRAN通知由于接收到源自UTRAN的寻呼或者由于对发送上行链路数据的请求而造成的至CELL_FACH状态的转换；

-由CELL_PCH、URA_PCH和CELL_FACH状态下的UE来请求MBMS P-T-P RB建立。

URA更新和小区更新过程可以：

1>包括UE中的移动性相关信息的更新；

小区更新过程还可以包括：

-AM RLC实体的重新建立；

8.3.1.2发起

UE应该在以下情况下发起小区更新过程：

1>上行链路数据传输：

3>如果UE在URA_PCH或CELL_PCH状态下；以及

3>如果定时器T320没有运行：

5>使用原因“上行链路数据传输”来执行小区更新。

3>否则：

4>如果设置了变量ESTABLISHMENT_CAUSE：

5>使用原因“上行链路数据传输”来执行小区更新。

1>寻呼响应：

3>使用原因“寻呼响应”来执行小区更新。

1>无线链路故障：

4>使用原因“无线链路故障”来执行小区更新。

1>MBMS ptp RB请求：

2>如果UE在URA_PCH、Cell_PCH或Cell_FACH状态下；以及

2>如果定时器T320没有运行；以及

3>使用原因“MBMS ptp RB请求”来执行小区更新。

1>重新进入服务区：

2>如果UE在CELL_FACH或CELL_PCH状态下；以及

3>使用原因“重新进入服务区”来执行小区更新。

1>RLC不可恢复错误：

2>如果UE检测到AM RLC实体中的RLC不可恢复错误[16]:

3>使用原因“RLC不可恢复错误”来执行小区更新。

1>小区重选：

3>如果UE处于CELL_FACH状态以及变量C_RNTI是空的：

4>使用原因“小区重选”来执行小区更新。

1>周期性小区更新：

2>如果UE在CELL_FACH或CELL_PCH状态下；以及

2>如果定时器T305到期；以及

3>对于FDD：

4>如果将变量COMMON_E_DCH_TRANSMISSION设置为假：

5>使用原因“周期性小区更新”来执行小区更新。

4>否则：

5>重新启动定时器T305：

5>以及结束过程。

3>对于1.28Mcp TDD和3.84/7.68Mcp TDD：

4>使用原因“周期性小区更新”来执行小区更新。

1>MBMS接收：

2>如果UE在URA_PCH、Cell_PCH或Cell_FACH状态下；以及

3>使用原因“MBMS接收”来执行小区更新。

URA_PCH状态下的UE应该在以下情况下发起URA更新过程：

1>URA重选：

2>如果系统信息块类型2中的URA标识的列表是空的；或者

2>如果不能够发现系统信息块类型2：

3>使用原因“URA改变”来执行URA更新。

1>周期性URA更新：

4>使用原因“周期性URA更新”来执行URA更新。

当发起URA更新或小区更新过程时，UE应该：

2>将计数器V316设置为零。

1>如果定时器T320正在运行：

2>停止定时器T320；

3>使用原因“上行链路数据传输”来执行小区更新。

2>否则：

4>使用原因“MBMS ptp RB请求”来执行小区更新。

1>如果定时器T319正在运行，停止定时器T319；

1>停止定时器T305；

1>针对FDD和1.28Mcp TDD：

2>如果UE在CELL_FACH状态下；以及

2>如果UE不支持CELL_FACH状态下的HS-DSCH接收：

3>如果没有设置变量H_RNTI或者没有设置变量C_RNTI：

4>清除变量H_RNTI；

4>清除变量C_RNTI；

4>清除任何存储的IE“HARQ信息”；

4>将变量HS_DSCH_RECEPTION_OF_CCCH_ENABLED设置为真；

3>否则：

4>如果将变量READY_FOR_COMMON_EDCH设置为“真”：

1>如果UE在CELL_DCH状态下；

2>如果存储的定时器T314和定时器T315的值都等于零；或者2>如果存储的定时器T314的值等于零，以及没有与任何的无线接入承载相关联的无线承载，针对该无线接入承载，在变量ESTABLISHED_RABS中，IE“重新建立定时器”的值被设置为“使用T315”，以及仅针对于CS域存在信令连接：

3>释放其所有的无线资源；

3>向高层指示释放(放弃)所建立的信令连接(存储在变量ESTABLISHED_SIGNALLING_CONNECTIONS中)和所建立的无线接入承载(存储在变量ESTABLISHED_RABS中)；

3>清除变量ESTABLISHED_SIGNALLING_CONNECTIONS；

3>清除变量ESTABLISHED_RABS；

3>进入空闲模式；

3>以及，过程结束。

2>如果所存储的定时器T314的值等于零：

3>释放与任何无线接入承载相关联的所有的无线承载，针对该无线接入承载，在变量ESTABLISHED RABS中，将IE“重新建立定时器”的值设置为“使用T314”；

3>在变量RB_TIMER_INDICATOR中，将IE“T314到期”设置为真；

3>如果释放了与CN域相关联的所有无线接入承载：

4>释放针对该CN域的信令连接；

4>向高层指示信令连接的释放(放弃)；

2>如果所存储的定时器T315的值等于零：

3>在变量RB_TIMER_INDICATOR中，将IE“T315到期”设置为真。

3>如果释放了与CN域相关联的所有无线接入承载：

4>释放针对该CN域的信令连接；

4>向高层指示信令连接的释放(放弃)；

2>如果所存储的定时器T314的值大于零：

4>启动定时器T314。

2>如果所存储的定时器T315的值大于零：

3>如果存在针对PS域的信令连接：

4>启动定时器T315。

2>针对所释放的无线承载：

3>从变量ESTABLISHED_RABS删除与该无线承载有关的信息；

3>当已经释放属于相同无线接入承载的所有无线承载时：

2>如果将变量E_DCH_TRANSMISSION设置为“真”：

3>将变量E_DCH_TRANSMISSION设置为假；

3>停止任何的E-AGCH和E-HICH接收过程；

3>对于FDD，停止任何的E-RGCH接收过程。

3>对于FDD，停止任何的E-DPCCH和E-DPDCH传输过程。

3>对于1.28Mcp TDD，停止任何的E-PUCH传输过程。

3>清除变量E_RNTI；

3>释放所有的E-DCH HARQ资源；

3>不再考虑要被作为服务E-DCH无线链路的任何无线链路。

2>移动至CELL_FACH状态；

2>根据[4]选择当前频率上的适合的UTRA小区；

2>清除变量E_RNTI，以及：

2>针对3.84Mcp TDD和7.68Mcp TDD；或者

3>根据子条款8.5.17选择PRACH；

3>根据子条款8.5.19选择辅助CCPCH；

2>否则：

3>如果将变量READY_FOR_COMMON_EDCH设置为“真”：

3>否则：

4>根据子条款8.5.17选择PRACH，以及：

3>清除变量H_RNTI；

3>清除任何存储的IE“HARQ信息”；

3>复位MAC-ehs实体[15]；

3>将变量HS_DSCH_RECEPTION_OF_CCCH_ENABLED设置为真；

3>以及，根据子条款8.5.37中的过程，开始接收HS-DSCH。

2>将变量ORDERED_RECONFIGURATION设置为假。

1>将变量CELL_UPDATE_STARTED设置为真；

1>如果将与HS-DSCHare有关的任何IE存储在UE中：

2>清除任何所存储的IE“下行链路HS-PDSCH信息”；

2>清除任何所存储的IE“下行链路辅助小区信息FDD”；

2>从变量TARGET_CELL_PRECONFIGURATION中清除所有的项；

1>如果将与E-DCH有关的任何IE存储在UE中：

2>清除任何存储的IE“E-DCH信息”；

1>如果将IE“HS-SCCH少量信息”存储在UE中：

1>如果将与MIMO有关的任何IE存储在UE中：

1>针对1.28Mcp TDD，如果IE“控制信道DRX信息”存储在UE中：

1>针对1.28Mcp TDD，如果IE“SPS信息”存储在UE中：

1>如果UE已不在CELL_FACH状态下；

2>移动至CELL_FACH状态；

2>针对3.84Mcp TDD和7.68Mcp TDD；或者

3>根据子条款8.5.17选择PRACH；

3>根据子条款8.5.19选择辅助CCPCH；

2>否则：

3>如果将变量READY_FOR_COMMON_EDCH设置为“真”：

3>否则：

4>根据子条款8.5.17选择PRACH，以及；

3>如果没有设置变量H_RNTI或者没有设置变量C_RNTI：

4>清除变量C_RNTI；

4>清除变量H_RNTI；

4>清除任何存储的IE“HARQ信息”；

4>将变量HS_DSCH_RECEPTION_OF_CCCH_ENABLED设置为真；

4>以及，根据子条款8.5.37中的过程，开始接收HS-DSCH。

3>否则：

4>根据子条款8.5.36中的过程，接收HS-DSCH。

1>如果UE执行小区重选：

2>清除变量C_RNTI；以及

2>停止在MAC中使用刚从变量C_RNTI清除的该C_RNTI；

2>针对FDD和1.28Mcp TDD，如果设置了变量H_RNTI：

3>清除变量H_RNTI；以及

3>停止在MAC中使用刚从变量H_RNTI清除的该H_RNTI；

3>清除任何存储的IE“HARQ信息”；

2>针对FDD和1.28Mcp TDD，如果设置了变量E_RNTI：

3>清除变量E_RNTI。

3>复位MAC-ehs实体[15]。

3>将变量HS_DSCH_RECEPTION_OF_CCCH_ENABLED设置为真；

3>以及，根据子条款8.5.37中的过程，开始接收HS-DSCH。

2>否则：

1>根据子条款8.5.15，将CFN与当前小区的SFN有关地进行设置；

1>在小区更新过程的情况下：

2>根据子条款8.3.1.3设置小区更新消息的内容；

2>在上行链路CCCH上提交小区更新消息以用于发送。

1>在URA更新过程的情况下：

2>根据子条款8.3.1.3设置URA更新消息的内容；

2>在上行链路CCCH上提交URA更新消息以用于发送。

1>将计数器V302设置为1；

1>当MAC层指示发送消息的成功或失败时，启动定时器T302。

10.3.3.43连接模式下的UE定时器和常数

该信息单元指定了连接模式下的UE使用的定时器和常数值。

13.4.27x TRIGGERED_SCRI-IN_PCH_STATE

13.2UE的计数器

13.3UE常数和参数

附录D

从25.331第8.2.2节，图8.2.2-3：描述了无线承载重新配置，正常流程。

在此描述消息，所提出的增加是斜体和加粗格式。

10.2.27无线承载重新配置；

从UTRAN发送该消息，以重新配置与QoS的改变有关的参数，或者释放和建立针对广播类型的MBMS服务的ptp传输使用的无线承载。该过程还可以改变MAC、重配置传输信道和物理信道的复用。还使用该消息来执行从GERAN Iu模式到UTRAN的切换。

RLC-SAP：AM或UM或通过GERAN Iu模式发送

逻辑信道：DCCH或通过GERAN Iu模式发送

方向：UTRAN→UE

Claims

1.一种由用户设备来处理指示消息的方法，所述方法包括：

在用户设备处：

如果高层指示长期不再有分组交换PS数据；以及

如果在至少一个无线资源控制RRC状态下已经触发了多少指示消息的计数小于最大数目，则：

递增在所述至少一个RRC状态下已经触发了多少指示消息的计数；

在指示消息中设置原因；以及

发送指示消息。

2.根据权利要求1所述的方法，其中，所述计数中的指示消息均具有被设置为“用户设备UE请求的PS数据会话结束”的原因。

3.根据权利要求1所述的方法，其中，所述原因被设置为“UE请求的PS数据会话结束”。

4.根据权利要求1所述的方法，其中，指示消息是信令连接释放指示消息。

5.根据权利要求1所述的方法，其中，所述至少一个RRC状态包括CELL_PCH状态或URA_PCH状态。

6.根据权利要求1所述的方法，还包括：在满足至少一个复位条件时，复位计数。

7.根据权利要求1所述的方法，其中，用户设备处于CELL_PCH状态或URA_PCH状态。

8.根据权利要求7所述的方法，还包括：如果用户设备处于URA_PCH状态，则转换到CELL_FACH状态，以发送指示消息。

9.根据权利要求1所述的方法，还包括：当禁止定时器正在运行时，禁止发送指示消息。

10.根据权利要求1所述的方法，其中，所述最大数目是1。

11.根据权利要求1所述的方法，其中，UE确定高层是否指示长期不再有PS数据。

12.根据权利要求1所述的方法，其中，UE确定在至少一个RRC状态下时已经触发了多少指示消息的计数是否小于所述最大数目。

13.一种用户设备，被配置为处理指示消息，所述用户设备被配置为：

如果高层指示长期不再有PS数据；以及

如果在至少一个RRC状态下已经触发了多少指示消息的计数小于最大数目，则：

在指示消息中设置原因；以及

发送指示消息。

14.根据权利要求13所述的用户设备，其中，所述计数中的指示消息均具有被设置为“UE请求的PS数据会话结束”的原因。

16.根据权利要求13所述的用户设备，还被配置为：将所述原因设置为“UE请求的PS数据会话结束”。

17.根据权利要求13所述的用户设备，其中，指示消息是信令连接释放指示消息。

18.根据权利要求13所述的用户设备，其中，所述至少一个RRC状态包括CELL_PCH状态或URA_PCH状态。

19.根据权利要求13所述的用户设备，还被配置为：在满足至少一个复位条件时，复位计数。

20.根据权利要求13所述的用户设备，还被配置为：在CELL_PCH状态或URA_PCH状态下操作。

21.根据权利要求20所述的用户设备，还被配置为：如果用户设备处于URA_PCH状态，则转换到CELL_FACH状态，以发送指示消息。

21.根据权利要求12所述的用户设备，还被配置为：当禁止定时器正在运行时，禁止发送具有所设置的原因的指示消息。

22.根据权利要求12所述的用户设备，其中，所述最大数目是1。

23.根据权利要求12所述的用户设备，还被配置为确定高层是否指示长期不再有PS数据。

24.根据权利要求12所述的用户设备，还被配置为确定在至少一个RRC状态下时已经触发了多少指示消息的计数是否小于所述最大数目。