用于状态/模式转移的方法和设备与流程

技术领域

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

背景技术：

通用移动电信系统(UMTS)是用于发送文本、数字化语音、视频和多媒体的宽带的、基于分组的系统。它高度遵循第三代的标准并且一般地基于宽带码分多址(W-CDMA)。

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

当处于UTRA RRC已连接模式时，设备可以处于四种状态之一。这些状态是：

CELL_DCH：在该状态中，在上行链路和下行链路中将专用信道分配给UE，以交换数据。UE必须执行如3GPP 25.331中概述的动作。

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

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

URA_PCH：UE使用非连续接收(DRX)，经由寻呼指示符信道(PICH)来监视广播消息和寻呼。不可能有上行链路活动。UE必须执行如3GPP 25.331中概述的动作，其中包括如3GPP TS 25.304中定义的小区选择过程。该状态类似于CELL_PCH，只是仅经由UTRAN注册区域(URA)重选择来触发URA更新(URAUPDATE)过程。

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

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

上述问题的一个解决方案是：当UE认识到其完成数据交易时，使UE向UTRAN发送信令释放指示。依照3GPP TS 25.331规范的8.1.14.3节，当从UE接收到信令释放指示时，UTRAN可以释放信令连接，从而使UE转移至空闲模式或者某其他RRC状态。上述解决方案的问题在于：UTRAN可能变得被来自该UE和其他UE的信令释放指示消息所淹没。

技术实现要素：

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

在具体示例中，本系统和方法提供了从RRC已连接模式至更有效利用电池或者更有效利用无线资源的状态或模式的转移，同时在网络处提供了进行决定的能力。具体地，本发明和设备提供了基于从UE接收指示而进行的转移，该指示隐式地或者显式地指示了应当发生与同无线资源的特定信令连接相关联的RRC状态或模式至另一状态或模式的转移。应当理解，这种转移指示或请求可以利用当前标准下的现有通信，例如信令连接释放指示(SIGNALING CONNECTION RELEASE INDICATION)消息，或者可以是改变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处于空闲(IDLE)、URA_PCH、Cell_PCH或CELL_FACH状态时，该系统信息消息由该UE读取。

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

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

在另一个实施例中，当UE检测到省略了禁止定时器值(并且例如采用无穷大的禁止定时器)时，UE可以发送转移指示，但是不包括任何附加信息，具体地，IE可以省略触发发送转移指示的原因(下面将更详细地描述)。转移指示消息中对原因元素的省略可以通过允许UE使用现有转移指示消息(例如信令连接释放指示(SIGNALING CONNECTION RELEASE INDICATION))请求或指示转移，来确保向后兼容。

参照示例实施例来更详细地描述在接收的消息中不包括禁止定时器，其中，在小区中广播系统信息块，或者将该系统信息块发送至UE，该系统信息块被配置为传送禁止定时器值。在本实施例中，如果UE接收到在消息中或者在消息内的信息元素中不包含禁止定时器(称作T3xx)的系统信息块，那么在这种情况下，UE可以确定通过例如将禁止定时器T3xx设置为无穷大来不使UE能够发送转移指示消息。

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

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

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

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

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

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

在实施例中，使用信令连接释放指示过程来传送转移指示。UE使用该信令连接释放指示过程来向UTRAN指示已经释放其信令连接之一。

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

在没有将禁止定时器值发信号通知给UE或者传送给UE的情况下，在信令连接释放指示(SIGNALING CONNECTION RELEASE INDICATION)消息中没有指定信令连接释放指示原因。本领域技术人员将理解，在该备选实施例中，缺少定时器值不会导致定时器值被设置为无穷大。

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

在另一个备选实施例中，当UTRAN将定时器值发信号通知给UE或者传送给UE时，例如信息元素“处于已连接模式的UE定时器和常量”中的禁止定时器T3xx(或者使用系统信息，例如SIB1、SIB3或SIB4、或者利用专用UTRAN移动性信息消息)，该释放过程根据下述步骤来进行。首先，UE可以检验是否存在所指示的任何电路交换域连接。可以在变量“ESTABLISHED_SIGNALLING_CONNECTIONS”中指示这种连接。如果不存在电路交换域连接，则可以进行第二次检验，以确定上层是否指示了在延长的时段内将不存在分组交换域数据。

如果不存在电路交换域连接并且在延长的时段内预期没有分组交换域数据，则UE可以接下来检验定时器T3xx是否正在运行。

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

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

当T3xx定时器正在运行时，如果由于在延长的时段内没有其他分组交换域数据而发起了信令连接释放指示过程，则UE负责实现在T3xx定时器超时时是否发起该过程。UE决定可以基于确定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 CONNECTION REQUEST)消息。当接收到RRC连接请求消息时，UTRAN应当例如接受该请求并向UE发送RRC连接建立(RRC CONNECTION SETUP)消息。RRC连接建立消息可以包括禁止转移指示，称为定时器T3xx。当UE接收到该RRC连接建立消息时，UE应当例如存储定时器T3xx的值，替换任何先前存储的值，或者，如果定时器T3xx不在RRC连接建立消息中，则UE应当将定时器的值设置为无穷大。在一些实施例中，RRC连接建立消息必须包括禁止转移指示以确保UE知道UTRAN支持禁止转移指示信令。

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

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

此外，为了移动性的目的，在网络内使用的、不同供应商的网络设备可以导致相邻小区使用当UE在小区之间移动时需要在UE上更新的不同禁止定时器。

在一个备选实施例中，这一点是通过提供下述内容来处理的：所有的切换以及相关的承载控制消息包括禁止定时器T3xx的值。此处将这种消息称作移动性消息。这允许UE在小区之间移动时接收新的禁止定时器值。如果这些移动性消息中的一个不包含禁止定时器值，则还允许UE设置禁止定时器的缺省定时器值。应当理解，如果在移动性消息中没有接收到禁止定时器值，则这指示了该小区不支持快速休眠。

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

数据传输完成指示过程开始于以下指示：在延长的持续时间内，RRC或上层将不具有更多的PS域数据。如果在变量ESTABLISHED_SIGNALLING_CONNECTIONS中指示CS域连接或者如果将定时器T3xx设置为无穷大，则该过程结束。否则，如果定时器T3xx没有正在运行(即已经超时)或被设置为0秒，则向下层提交数据传输完成指示(DATA TRANSFER COMPLETE INDICATION)消息以在DCCH上使用AM RLC进行发送，此后，当已经向下层传送消息时，启动或重置定时器T3xx。

当接收到数据传输完成指示时，UTRAN可以决定发起向更有效利用电池的RRC状态或空闲模式的UE转移。

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

因此，本公开提供了一种用于控制用户设备对转移指示消息的使用的方法，该方法包括：将禁止转移指示包括在配置消息中；以及向所述用户设备发送具有所述禁止转移指示的配置消息。

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

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

本公开还提供了一种用户设备，被配置为发送转移指示，所述用户设备被配置为：根据从网络元件接收的禁止转移指示来设置定时器；检测完成数据传输；以及当检测到所述定时器没有运行时，发送所述转移指示。

附图说明

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

图1是示出了RRC状态和转移的框图；

图2是示出了各个UMTS小区和UTRA的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所示的网络的示例操作期间示例逻辑和物理信道分配的图形表示，其中利用UE提供多个并发的分组数据通信服务会话；

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

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

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

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

图16示出了一幅方法流程图，该图示出了本公开的实施例的操作的方法；

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

图18示出了基于网络元件处的无线资源简档来进行转移决定的实施例的方法流程图；

图19示出了能够与图18的方法一起使用的网络元件的简化框图；

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

图21示出了用于在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。

从空闲模式110，UE自主地转移至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。而是使用公共信道来发送少量突发数据中的信令。然而，UE仍然必须连续地监视FACH，因此，其比处于CELL_PCH状态、URA_PCH状态以及空闲模式时消耗更多的电池功率。

在RRC已连接模式120中，可以由UTRAN随意改变RRC状态。具体地，如果在特定量的时间内检测到数据不活动或者检测到数据吞吐量低于特定阈值，则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。

为了发起更新过程以请求专用信道，UE必须从CELL_PCH状态126或URA_PCH状态128移动至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中检测到十秒的不活动，则RRC状态改变为Cell_PCH状态126。在Cell_PCH状态126中的四十五分钟的不活动将导致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中五分钟的不活动之后，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中三十秒的不活动导致移动回到空闲模式110。

在第四示例基础结构中，RRC从空闲模式转移至已连接模式，直接进入CELL_DCH状态122。在第四示例基础结构中，CELL_DCH状态122包括两种配置。第一种配置包括具有高数据速率的配置，第二种配置包括较低数据速率但仍然处于CELL_DCH状态中。在第四示例基础结构中，RRC从空闲模式110直接转移进入高数据速率CELL_DCH子状态。在10秒的不活动之后，RRC状态转移至低数据速率CELL_DCH子状态。CELL_DCH状态122的低数据子状态中十七秒的不活动导致RRC状态改变为空闲模式110。

上述四个示例基础结构示出了各个UMTS基础结构供应商如何实现状态。本领域技术人员应当理解，在每一种情况下，如果与停留在CELL_DCH或CELL_FACH状态中所需要的时间相比，花费在交换实际数据(例如电子邮件)上的时间明显较短的话。这引起不必要的电流耗尽，使在更新一代的网络(如UMTS)中的用户体验比现有一代的网络(如GPRS)中的用户体验差。

此外，尽管从电池寿命的角度来说CELL_PCH状态126比CELL_FACH状态124更优，但是典型地将CELL_PCH状态126中的DRX周期设置为比空闲模式110中更低的值。因此，需要UE在CELL_PCH状态126中比在空闲模式110中更频繁地唤醒。

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

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

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

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

一般地，以相反的顺序类似地完成拆除连接。拆除无线承载建立316，然后拆除RRC连接建立310。此时，如图1所示，RRC移动进入空闲模式110。

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

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

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

如果信令连接建立312被拆除，则在没有CS连接是活动的时，RRC连接建立典型地由当前供应商基础结构的网络来拆除。

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

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

如果网络元件将UE转移至空闲模式110，这可以发生在如图1所示的RRC已连接模式120的任何阶段，则如图1所示，网络元件释放RRC连接并将UE移动至空闲模式110。当在语音呼叫期间UE正在执行任何分组数据服务时，这也适用。在这种情况下，网络可以选择仅释放PS域信令连接，并维持CS域信令连接，或者备选地可以选择不释放任何连接而是同时维持与PS和CS域的信令连接。

在另一实施例中，可以向转移指示添加原因，以向UTRAN指示该指示的理由。在优选实施例中，该原因可以是对以下内容的指示：异常状态引起了指示；或者由于所请求的转移，UE发起了指示。其他正常(即，非异常)交易还可以导致发送转移指示。

在另一优选实施例中，各种超时可以引起针对异常条件而发送转移指示。下面的定时器的示例不是详尽的，其他定时器或者异常条件是可能的。例如，10.2.473GPP TS 24.008指定定时器T3310为：

定时器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域的关联的信令连接是上层所标记要释放的。如果将CN域标识被设置为PS域，并且如果上层指示了发起该请求的原因，则相应地设置IE“信令释放指示原因(SIGNALING RELEASE INDICATION CAUSE)”。UE还将具有由上层指示的标识的信令连接从变量“ESTABLISHED_SIGNALING_CONNECTIONS”中移除。UE在例如专用控制信道(DCCH)上使用肯定应答模式的无线链路控制(AM RLC)来发送信令连接释放指示消息。当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循环回来并在步骤912中继续检验是否存在异常条件以及在步骤920中继续检验是否完成数据。

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

UE包括功能元件，可由例如通过UE微处理器的操作而执行的应用或算法来实现，或者由硬件实现方式来实现，该功能元件形成检验器和转移指示发送器。检验器被配置为检验是否应当发送转移指示。并且，转移指示发送器被配置为响应于检验器的应当发送转移指示的指示，发送转移指示。该转移指示可以包括转移指示原因字段。

在一个实施方式中，取而代之地，隐式地使网络知道定时器的超时，并且UE不需要发送用于指示定时器的超时的原因值。即，在网络授权时，定时器开始定时。定义了原因码，并且网络将原因码提供给UE。UE使用这种原因码来启动定时器。由于网络更早发送的原因码使定时器开始定时，因此网络隐式地知道定时器的随后超时的原因。因此，UE不需要发送用于指示定时器的超时的原因值。

如图9以及以上描述所建议的，原因可被包括进来，并与转移指示(例如信令连接释放指示)一起发送以指示：1.)异常条件以及2.)正常条件(不是异常条件，例如针对PS数据会话结束和/或向空闲模式的转移的请求)。因此，在各个实施方式中，UE处的操作提供将原因添加至转移指示以指示异常条件，或者备选地指示对空闲转移或PS数据会话结束的请求(即正常操作)的偏好。当然，这种操作也包括以下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中，不发出警报并可以从性能统计数据中过滤掉该指示，从而防止性能统计数据倾斜(skewed)。从步骤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上的AM RLC在例如上行链路DCCH上重传信令连接释放指示消息。在RLC确认成功传送了信令连接释放指示或请求消息之前发生来自UTRAN过程的RAT(无线接入技术)间切换的情况下，当处于新的RAT中时，UE中止信令连接。

在另一实施例中，不利用“信令连接释放指示”或请求，而是可以利用“数据传输完成指示”。与上面图9和10所述的功能类似的功能可以适用于该数据传输完成指示。

在一个实施例中，UE使用该数据传输完成指示来向UTRAN通知UE已经确定不存在正在进行的CS域数据传输，并且UE已经完成其PS数据传输。例如，使用AM RLC在DCCH上从UE向UTRAN发送这样的消息。下面示出了示例消息。

10.2.x 数据传输完成指示

UE使用该消息来向UTRAN通知UE已经确定不存在正在进行的CS域数据传输，并且UE已经完成其PS数据传输。

RLC-SAP：AM

逻辑信道：DCCH

方向：UE→UTRAN

数据传输完成指示

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

在另一个且备选的实施例中，该条件可以包括：如果定时器T3xx被设置为无穷大，则阻止发送转移指示。应当理解，T3xx可以包括多个离散值，其中之一表示无穷大值。

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

一旦条件适合，该过程就进行至步骤2020，在步骤2020中，向UTRAN发送转移指示。在上表中示出了示例指示。

然后，该过程进行至步骤2022，在步骤2022中，进行检验以确定转移指示是否成功。本领域技术人员应当理解，这可能意味着UTRAN已经成功地接收到转移指示并已经发起了状态转移。如果是，则该过程进行至步骤2030并结束。

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

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

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

禁止转移指示

在一个实施例中将T3xx的值定义为：

T3xx定义

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

如上表中所指示的，T3xx值可以在集合值之间改变，并可以包括零值或无穷大值。零值用于指示不需要发生禁止。无穷大值指示从不应当发送转移指示消息。

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

在另一个备选实施例中，如下定义T3xx的值。对定时器T3xx的包括是可选的，从而确保了如果不包括，则UE不必须支持配置或使用该定时器：

备选的T3xx定义

因此，在小区中接收禁止定时器是向UE指示小区意识到对转移指示消息的使用。如果由于确定了在延长的持续时间内没有更多PS域数据而导致由RRC或上层发起，则UE可以确定使用原因值来发信号通知转移指示。当网络接收到具有该原因值的转移指示消息(不论是什么形式的，如本文档中捕获的)时，网络可以确定向UE发信号通知向更有效利用电池的RRC状态的状态转移改变。

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

如果UE确定了省略禁止定时器，则基于更高层确定其不具有更多PS数据要发送，UE可以从转移指示消息中省略原因值并仅发送转移指示消息。

在备选实施例中，当UE确定了省略禁止定时器时，基于更高层确定其不具有更多PS数据要发送，UE将不发起转移指示。

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

因此，在第一备选实施例中，在小区中接收禁止定时器是指示小区意识到对转移指示消息的使用。在当没有将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.40 RRC连接建立；

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可以接收或确定禁止定时器的新值。在切换之前禁止定时器是除了无穷大以外的某个值的其他情况下，继续使用该其他值，直到UE能够将定时器值更新为在新小区中指示的定时器值为止。

对于第五实施例来说，利用过程图21来确保在移动性期间更新禁止定时器值，并确保不会不必要地从UE发送转移指示消息。

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

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

在网络侧，与下面参照图18所述的方式类似地处理该过程。

再一次参照图1，在一些情况下，与空闲模式110相比，可能更希望处于已连接模式120中的诸如URA_PCH状态128之类的状态。例如，如果需要对CELL_DCH状态122或CELL_FACH状态124的连接的延迟更低，则优选地处于已连接模式120 PCH状态。存在多种方式来完成这一点，例如通过修改标准以允许UE请求UTRAN将该UE移动至特定状态(例如在这种情况下，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的示例中，这在大约二到四秒中实现并由步骤420来示出。

在步骤420中交换了数据之后，不交换除了所需要的间断RLC信令PDU以外的数据，从而在大约十秒之后，无线资源被网络重新配置为移动至更低数据速率DCH配置。这在步骤422和424中示出。

在更低数据速率DCH配置中，大约十七秒钟没有接收到任何东西，此时，在步骤428中网络释放RRC连接。

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

同样如图4A所示，示出了在RRC处于CELL_DCH状态122的时间段内UE电流消耗。可见，在CELL_DCH状态的整个持续时间内，电流消耗大约是200到300毫安。在断开和空闲期间利用大约3毫安，假定DRX周期是1.28秒。然而，35秒的200到300毫安的电流消耗将使电池耗尽。

现在参照图4B。图4B利用了上述相同示例基础结构“四”，现在仅实现信令连接释放。

如图4B所示，进行相同的建立步骤310、312、314和316，并且当在RRC空闲状态110和RRC CELL_DCH状态122之间移动时，这花费相同的时间量。

此外，在图4B也进行图4A的步骤420处的示例电子邮件的RRC数据PDU交换，并且这大约花费二到四秒。

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

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

现在参照图5。图5示出了使用以上示为基础结构“三”的基础结构的第二示例。如图4A和4B那样，进行连接建立，这花费大约两秒。这需要RRC连接建立310、信令连接建立312、加密和完整性建立314以及无线承载建立316。

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

如图4A那样，在图5A中，在步骤420进行RLC数据PDU交换，并且在图5A的示例中花费二到四秒。

根据基础结构“三”，RLC信令PDU交换不接收除了所需要的间断的RLC信令PDU以外的数据，从而在步骤422中空闲五秒的时段，此时，无线资源将UE重新配置为从CELL_DCH状态122移动至CELL_FACH状态124。这在步骤450中进行。

在CELL_FACH状态124中，RLC信令PDU交换发现在预定时间量(在这种情况下，三十秒)内不存在除了所需要的间断的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已连接模式状态持续大约四十秒。

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

如图4B那样，在步骤440中，UE应用检测特定的不活动超时，此时，UE发送转移指示(例如信令连接释放指示442)，并且作为结果，在步骤448中网络释放RRC连接。

如在图5B中进一步可见，RRC在空闲模式110中开始，移动至CELL_DCH状态122而不进入CELL_FACH状态。

如在图5B中进一步可见，在RRC阶段处于CELL_DCH状态122的时间内电流消耗是大约200到300毫安，根据图5的示例，该时间是大约八秒。

因此，图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)。

PS用户平面630中的接入层616包括分组数据汇聚协议(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是具有至少语音和数据通信能力的双向无线通信设备。优选地，移动设备700具有在因特网上与其他计算机系统进行通信的能力。依赖于所提供的精确功能，无线设备可以被称作例如数据消息收发设备、双向寻呼机、无线电子邮件设备、具有数据消息收发能力的蜂窝电话、无线因特网装置或数据通信设备。

在针对双向通信启用UE 700时，UE 700将并入通信子系统711，移动子系统711包括：接收机712和发射机714以及关联的组件，例如，一个或多个优选地嵌入的或内部的天线元件716和718、本地振荡器(LOs)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接口744通常与可以像磁盘或PCMCIA卡一样将卡插入和弹出的卡槽类似。UIM卡可以具有大约64K内存，并拥有许多关键配置751以及诸如标识和订户相关信息等其他信息753。

当完成了所需的网络注册或激活过程时，UE 700可以在网络719上发送和接收通信信号。天线716通过通信网络719接收到的信号输入至接收机712，接收机712可以执行如下常见接收机功能：信号放大、频率下转换、滤波、信道选择等，以及在图7所示的示例系统中的模数(A/D)转换。对接收到的信号的A/D转换允许在DSP 720中执行更复杂的通信功能，例如，解调和解码。采用类似的方式，DSP 720对要发射的信号进行处理(包括例如调制和编码)，该信号输入至发射机714以用于数模转换、频率上转换、滤波、放大以及经由天线718在通信网络719上发射。DSP 720不仅处理通信信号，还提供接收机和发射机控制。例如，可以通过在DSP 720中实现的自动增益控制算法，来自适应地控制在接收机712和发射机714中应用于通信信号的增益。

网络719还可以与多个系统通信，包括服务器760和其他元件(未示出)。例如，网络719可以同时与企业系统和网页客户端系统进行通信，以适应具有各个服务级别的各个客户端。

优选地，UE 700包括微处理器738，微处理器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中。此外，优选地，唯一标识符也存储在只读存储器中。

如图所示，闪存724可以被分离为不同的区域，以用于计算机程序758和程序数据存储器750、752、754和756。这些不同的存储类型指示了每个程序可以针对其自身的数据存储需求来分配闪存724的一部分。微处理器738除了执行其操作系统功能外，还优选地执行移动设备上的软件应用程序。在制造期间，在UE 700上通常将安装控制基本操作的预定应用程序集，例如包括至少数据和语音通信应用程序。优选的软件应用程序可以是：个人信息管理器(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是与显示器722相结合并可能与辅助I/O设备728相结合的完整字母数字键盘或电话型键区。然后，可以通过通信子系统711在通信网络上发送这种所编写的项目。

对于语音通信，UE 700的总体操作是相似的，不同之处在于，接收到的信号可能优选地输出至扬声器734，并且要发送的信号可能由麦克风736产生。还可以在UE 700上实现诸如语音消息记录子系统之类的备选语音或音频I/O子系统。尽管主要通过扬声器734来优选地实现语音或音频信号输出，但显示器722也可以用于提供对例如主叫方身份、语音呼叫持续时间或其他与语音呼叫有关的信息的指示。

通常可以在个人数字助理(PDA)型移动设备中实现图7中的串行端口730，对于PDA型移动设备来说，可能希望与用户的台式计算机(未示出)的同步。这种端口730可能使用户可以通过外部设备或软件应用程序来设置偏好，并可能除了通过无线通信网络以外还通过向UE 700提供信息或软件下载，来扩展移动设备700的能力。交替的下载路径可以例如用于通过直接的、因而可靠且可信的连接，将加密密钥加载至设备上，从而实现安全的设备通信。

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

如短距离通信子系统之类的其他通信子系统740是另一可选组件，该组件可以提供UE 700与不同系统或设备(不必是相似的设备)之间的通信。例如，子系统740可以包括红外设备、以及关联电路和组件、或Bluetooth^TM通信模块，以提供与以类似方式启用的系统和设备的通信。

现在参照图8。图8是通信系统800的框图，通信系统800包括通过无线通信网络进行通信的UE 802。

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

图8的通信系统800中所示的无线链路表示一个或多个不同信道(典型地，不同的射频(RF)信道)以及在无线网络和UE 802之间使用的关联协议。在UE 802和Node B 806之间使用Uu空中接口804。

典型地由于总体带宽的限制以及UE 802的有限电池功率，RF信道是必须节约的有限资源。本领域技术人员应当理解，依赖于所期望的总体网络覆盖距离，实际上的无线网络可以包括上百个小区。所有相关组件可以由被多个网络控制器控制的多个交换机和路由器(未示出)相连接。

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

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

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

通用陆地无线接入网络(UTRAN)820包括RNC 810、Node 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(下面更详细地定义)。RANAP协议在3GPP TS 25.413 V3.11.1(2002-09)和TS 25.413V5.7.0(2004-01)中定义。

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

通过服务GPRS支持节点(SGSN)850来路由分组数据。SGSN 850是处于GPRS/UMTS网络中RNC和核心网络之间的网关，并负责在其地理服务区域内从UE以及向UE传送数据分组。在RNC 810和SGSN 850之间使用Iu-PS接口848，并且该Iu-PS接口848是用于在UTRAN 820和核心数据网络之间(典型地)承载数据业务量和信令的分组交换连接。所使用的主要信令协议是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上下文行为或应用层行为。

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

在另一实施方式中，该转移指示包括包含原因的原因字段，例如这里和上面描述的任何恰当的前述原因，或者原因字段标识了UE更希望网络使UE转移至的优选状态。

体现在网络处的设备1128包括检查器1142和批准器1144。当在检查器处接收到转移指示时，检验器检查转移指示。并且，转移批准器1144可选择地操作以如转移指示中所请求的那样转移UE。

在无线资源控制(RRC)层处执行信令的实施方式中，无线网络控制器(RNC)而不是SGSN执行对UE的检查和转移。并且对应地，在RRC层处形成UE处体现的设备，或者该设备使所产生的指示在RRC级发送。

在示例控制流程中，在恰当时，更高层向NAS/RRC层通知不再需要将无线资源分配给特定的PDP上下文。将RRC层指示消息发送至网络。该消息包括RAB ID或RB ID，该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示出了总体在1137处示出的消息序列图，其表示根据与PDP上下文相关联的无线资源释放而产生的示例信令，该PDP上下文例如是在图11所示的图形表示的一部分中以图形示出的。由UE或者在RNC或其他UTRAN实体处发起释放。例如，当在UE处发起时，UE向UTRAN发送无线资源释放指示。

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

图14示出了总体在1147处示出的消息序列图，类似于图13所示的消息序列图，但是在图14中释放最终PDP上下文的资源。在发起时，RNC产生Iu释放请求1150，将其通信给SGSN，并且响应于此，如段1152所指示，SGSN返回Iu释放命令。此后，如段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，执行Iu释放过程，例如图14所示的过程或者例如在3GPP文档的23.060节、子条款9.2.5.1.2中描述的过程。

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

在由框1194所指示开始过程之后，如判决框1196所指示，确定是否有RAB(无线接入承载)要释放。如果否，则取“否”分支到结束框1198。

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

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

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

然后，在框1212，检查无线资源释放指示，然后，在框1214，可选择地批准无线承载的释放。

在另一实施例中，网络可以基于从用户设备或者另一个网络元件接收到指示以及基于该用户设备的无线资源简档来发起转移。

从用户设备或者另一网络元件接收的指示可能是上述不同转移指示中的任一个。该指示可以是被动的，并因此可以仅仅是应当进入不太消耗电池的无线状态的空指示。备选地，该指示可以是从UE发送的、网络可能基于接收指示的时间或数目确定的常规指示的一部分，并可以是应当进入不太消耗电池或无线资源的无线状态的、UE的无线资源简档。备选地，该指示可以是动态的并向网络元件提供与要转移的优选状态或模式相关的信息。与上面一样，该指示可以包含该指示的原因(例如正常或异常)。在另一实施例中，该指示可以提供与无线资源简档相关的其他信息，例如用户设备对于转移至不同状态或模式的能力来说正确的概率，或者与触发了该指示的应用相关的信息。

来自另一个网络元件的指示可以包括例如来自媒体或一键通网络实体的指示。在本示例中，当业务量条件允许时，向负责转移的网络实体(例如UTRAN)发送该指示。该第二网络实体可以在因特网协议(IP)级查看业务量，以确定是否以及何时发送转移指示。

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

因此，该指示可以是任何信号并可以是基于应用的、基于无线资源的、或者是提供与所有用户设备应用和无线资源相关的信息的复合指示。以上并不是指限制在任何具体指示，并且本领域技术人员应当理解，对于本发明和公开来说可以使用任何指示。

现在参照图18。过程开始于步骤1801并进行至步骤1810，在步骤1810中，网络元件接收指示。

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

如本文所使用的术语“无线资源简档”指的是根据网络元件的需求而可以应用于多种情形的宽泛术语。在宽泛的术语中，无线资源简档包括与用户设备所利用的无线资源相关的信息。

无线资源简档可以包括静态简档元素和动态或协商简档元素中的一个或两个。这种元素可以包括“禁止持续时间和/或每时间窗口的最大指示/请求消息”值，该值可以是转移简档内或之外的无线资源简档的一部分，并可以是协商的或者静态的。

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

本领域技术人员应当理解，对于无线资源来说可以存在各个级别的服务质量，并且服务质量的级别可以向网络提供与是否转移至不同状态或模式相关的信息。因此，如果服务质量是背景，则网络元件可以考虑比在服务质量被设置为交互式的情况下更容易地转移至空闲。此外，如果多个无线资源具有相同的服务质量，则这可以向网络提供与是将移动设备转移至更合适的状态或模式还是拆除无线资源相关的指示。在一些实施例中，主和次PDP上下文可以具有不同的服务质量，这还可能影响与是否执行状态/模式转移相关的决定。

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

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

UTRAN可以包括或者接入数据库或表，在该数据库或表中可以将各个APN或QoS参数与特定转移简档相关联。因此，如果UE是始终开启的设备，则这对于APN来说将是显而易见的，并且在UTRAN处可以将该APN的恰当转移简档存储为无线资源简档的一部分，或者UTRAN可以远程接入该恰当转移简档。类似地，如果使用QoS或者QoS参数的一部分，或者与简档一起发送专用消息，则这可以向UTRAN表示基于数据库查询或者表中的查找而期望特定转移简档。另外，可以利用这种手段来指定除了RRC已连接状态转移简档之外的多种行为。这些行为包括但不限于：

速率适应算法(步周期/步长)；

初始的被批准的无线承载；

最大被批准的无线承载；

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

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

此外，如果存在具有不同QoS需求但共享相同APN IP地址的多个PDP上下文，例如主上下文、次上下文等等，则对于每一个上下文来说可以使用不同的转移简档。这可以通过QoS或专用消息而发信号通知给UTRAN。

如果同时利用多个活动的PDP上下文，则可以使用上下文之间的最小公分母。对于RRC状态转移来说，如果一个应用具有第一PDP上下文和第二PDP上下文，该第一PDP上下文与其中系统从CELL_DCH状态快速移动至CELL_PCH或空闲状态的转移简档相关联，该第二PDP上下文与其中系统将停留在CELL_DCH状态中更长时间的转移简档相关联，则维持CELL_DCH状态更长时间的第二简档将超越第一简档。

本领域技术人员应当理解，可以以两种不同的方式来考虑最小公分母。如本文所使用的，最小公分母意味着在转移至不同状态之前所需的最长时间。在第一实施例中，最小公分母可以是最小的激活的PDP。在备选实施例中，最小公分母可以是实际具有活动无线资源的最小的PDP。可以以多种不同的方式来复用无线资源，但是最终结果是相同的。

可以针对始终开启的设备得出这种方法的示例情况。如上所述，可以将各个APN或QoS参数与“始终开启”的特定行为相关联。最初考虑可基于“始终开启”简档而期望的被批准的无线资源。现在，网络具有“知道”以下内容的手段：对于始终开启的应用(例如电子邮件)来说，数据突发是短暂且突然的。对于本领域技术人员来说清楚可见，给定该信息，没有动机针对网络上的中继效率而节约代码空间。从而，可以向始终开启的设备分配最大速率，同时不针对其他用户预留足够代码空间的风险极小。另外，UE受益于更快速地接收数据，还由于更短的“开启时间”而节约了电池寿命。同样地，对于本领域技术人员来说，由于不管数据速率如何，功率放大器都完全偏置，因此高数据速率对电流汲取几乎没有影响。

在上述实施例中，UTRAN可以使用查找表来确定对于UE的给定RRC连接的不同应用而分配的无线资源的资源控制简档。由于RNC将具有更多可用的最新业务量资源(即，可批准的数据速率)，因此该简档可以基于用户预订并可以存储在网络实体(例如HLR或者备选地在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上下文、转移简档等等所有这些。

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

在预定时间段内接收的指示的数目可以向网络指示不应当进行转移。从而，如果用户设备已经在三十秒时间段内发送了例如五个指示，则网络可以考虑其应当忽略指示并不应当执行任何转移。备选地，网络可以确定向UE指示其不应当无限期地或者在某个配置的或预定义的时间段内发送任何其他指示。这可以与UE上的任何“禁止持续时间和/或每时间窗口的最大指示/请求消息”无关

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

业务量模式和历史数据可以向网络提供不应当进行转移的指示。例如，如果用户过去已经在从星期一到星期五的8:30和8:35 a.m.之间接收到大量的数据，则在星期四的8:32 a.m.接收到该指示的情况下，网络可以决定由于在8:35 a.m.之前很可能有更多数据，其不应当转移用户设备。

如果针对用户设备分配了多个无线资源，则网络可能需要考虑用户设备的完整无线资源简档。在这种情况下，可以检查每一个无线资源的无线资源简档，并进行复合转移决定。基于一个或多个无线资源的无线资源简档，网络可以决定是否应当进行转移。

在一个实施例中，对于当网络在步骤1810中已经接收到指示以及可选地在步骤1820中检查了无线资源简档时如何继续进行，网络具有多种选择。

第一选项是什么也不做。网络可以决定不保证转移，从而不接受用户设备要转移的指示。本领域技术人员应当理解，由于状态没有改变，具体地由于没有触发转移，因此什么也不做节约了网络信令。

第二选项是改变设备的状态。例如，在UMTS网络中，设备的状态可以从Cell_DCH改变为Cell_PCH。在非UMTS网络中，该状态转移可以在已连接的状态之间进行。本领域技术人员应当理解，与转移至空闲模式相比，改变状态减少了核心网络信令的量。由于Cell_PCH状态不需要专用信道，因此改变状态还可以节约无线资源。此外，Cell_PCH是不太消耗电池的状态，这使UE能够保持电池功率。

网络的第三选项是将UE保持在相同状态但释放与特定APN或PDP上下文相关联的无线资源。由于在其当前状态中维持连接并且不需要重新建立该连接，因此该方案节约了无线资源和信令。然而，该方案可能不太适合UE电池寿命成问题的情形。

网络的第四选项是将UE转移至空闲模式。具体地，在UMTS和非UMTS中，网络都可以从已连接模式移动至空闲模式。应当理解，由于完全不维持连接，因此这节约了无线资源。这还节约了用户设备的电池寿命。然而，需要更大量的核心网络信令来重新建立连接。

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

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

网络对于利用这五种或更多种选项中的哪些的决定将根据网络而不同。一些过载的网络可能偏向于保持无线资源并从而将选择上述第三、第四或第五选项。其他网络偏向于最小化信令并从而可以选择上述第一或第二选项。

该决定在图18中的步骤1830处示出，并可以基于网络偏好以及用户设备的无线资源简档。该决定由从用户设备接收以下指示的网络来触发：该用户设备想要转移至另一状态，例如转移至不太消耗电池的状态。

现在参照图19。图19示出了适于作出以上图18所示的决定的简化的网络元件。网络元件1910包括适于与用户设备通信的通信子系统1920。本领域技术人员应当理解，通信子系统1920不需要直接与用户设备通信，而是可以是用于去往和来自用户设备的通信的通信路径的一部分。

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

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

本文描述的实施例是具有与本公开的技术的单元相对应的单元的结构、系统或方法的示例。本说明书可以使本领域技术人员能够作出和使用具有备选单元的实施例，该备选单元同样与本公开的单元相对应。因此，本公开的技术的预期范围包括与本文描述的本公开的技术并无不同的其他结构、系统或方法，并且还包括与本文描述的本公开的技术无实质不同的其他结构、系统或方法。