用于状态/模式转移的方法和设备的制作方法

专利名称：用于状态/模式转移的方法和设备的制作方法
技术领域：
本公开总体涉及用户设备(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必须执行如3GPP 25. 331中概述的动作，其中包括如3GPP TS 25. 304中定义的小区选择过程。CELL_PCH =UE使用非连续接收(DRX)，经由寻呼指示符信道(PICH)来监视广播消 息和寻呼。不可能有上行链路活动。UE必须执行如3GPP 25.331中概述的动作，其中包 括如3GPP TS 25. 304中定义的小区选择过程。UE必须在小区重选择之后执行小区更新 (CELLUPDATE)过程。URA_PCH =UE使用非连续接收(DRX)，经由寻呼指示符信道(PICH)来监视广播消息 和寻呼。不可能有上行链路活动。UE必须执行如3GPP 25.331中概述的动作，其中包括如 3GPP TS 25. 304中定义的小区选择过程。该状态类似于CELL_PCH，只是仅经由UTRAN注册 区域(URA)重选择来触发URA更新(URA UPDATE)过程。由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转移至空闲模式。上述解决方案的问题在于信令释放 指示可能被视为警报。当发生GPRS移动性管理(GMM)服务请求故障、路由区域更新(RAU) 故障或附着故障时，网络典型地仅预期信令释放指示。在UE请求信令释放时发出警报导致 在网络处发出警报，并且当没有异常条件出现时，发出该警报是错误的行为。可在UMTS中操作的UE以及可在根据其他通信标准而构造的无线通信系统中操作 的其他移动节点有时能够提供多个并发的分组数据服务，其中每一个分组数据服务依照于 分组数据通信会话。尽管对由UE发送至UTRAN的信令释放指示的使用将提供一种请求对 针对所有分组数据服务而提供的、与UE的信令连接进行释放的方式，但需要提供对资源的 更精细控制。即，可能存在对下述情况的需要针对分组数据服务中当前活动的一个分组 数据服务提供持续的无线资源，同时释放针对并发分组数据服务中不再需要无线资源的另 一分组数据服务而提供的无线资源。由于不会将处理器功率浪费在对不需要的资源的处理 上，因而这导致了对网络资源的高效利用以及对UE上的处理器的最优利用。备选地，网络 元件可以对资源释放或者状态/模式之间的转移做出决定。

发明内容
下面提供的示例和实施例描述可以用于将用户设备(UE)或者其他移动设备在无 线网络(例如UMTS网络)中的操作的各种状态/模式之间进行转移的各种方法和系统。应 当理解，其他类型的网络中的其他实施方式也是可能的。例如，还可以将相同的教导应用于 码分多址(CDMA)网络(例如 3GPP2IS-2000)、宽带 CDMA(W-CDMA)网络(例如 3GPP UMTS/高速分组接入(HSPA))网络、或者作为概括，将该教导应用于以下任何网络该网络基于利 用网络控制的无线资源的无线接入技术，或者保持不知道设备应用级别数据交换的状态。 下面描述的(尽管为了简明而与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太频繁地发送转移指示消息，还允许网络 通过依赖于仅以给定最大频率而触发的消息来进行确定。该持续时间可以由具有预配置值 的定时器来测量，或者由网络来设置(指示或者发信号通知)。如果该值由网络来设置，则 该值可以在现有的消息(例如RRC连接请求、RRC连接释放、无线承载建立或者系统信息广 播等等)中传送，并且该值可以是这些消息中的信息元素。上述禁止持续时间可以基于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指示的状态的状态转移)，则可以 减少或取消禁止持续时间/功能。可以使用/指定每时间窗口的消息的最大数目(例如“每10分钟不超过15条消 息”)而不使用/指定禁止持续时间，或者除了禁止持续时间以外还使用/指定每时间窗口 的消息的最大数目。上述禁止持续时间/每时间窗口的消息的最大数目的组合是可能的。
因此，本公开可以提供一种用于在用户设备上转移状态或模式的方法，所述方法 包括下列步骤在网络元件处接收转移指示；检验所述用户设备的无线资源简档；以及在 所述网络元件处基于接收到的转移指示以及所述无线资源简档来进行转移决定。本公开还可以提供一种适于进行转移决定的网络元件，所述网络元件包括通信 子系统，适于接收转移指示；存储器；以及处理器，适于检验用户设备的无线资源简档，所 述处理器还适于基于接收到的转移指示以及所述无线资源简档来进行转移决定。本公开还可以提供一种适于发起转移决定的用户设备，所述用户设备包括通信 子系统，适于与网络进行通信；存储器；以及处理器，适于确定是否期望状态/模式转移，还 适于响应于该确定，向所述网络发送转移指示，其中所述用户设备适于基于所述转移指示， 从所述网络接收转移决定。本公开还可以提供一种用于从用户设备发起转移决定的方法，所述方法包括确 定在所述用户设备处是否期望状态/模式转移；以及响应于该确定，向网络发送转移指示， 由此所述用户设备基于所述转移指示，从所述网络接收转移决定。


参照附图，将更好地理解本公开，附图中图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示出了用于发送专用优选状态请求的数据流图。
具体实施例方式现在参照图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. 47 3GPP 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或者其他网络元件接收信令连接释放指示的原因。基于对信令连接释放指示以及UE 的无线资源简档的接收，进而允许在UTRAN处发起RRC连接释放过程。在该示例的一个实施方式中，当从特定CN(核心网络)域的上层接收到针对释放 或中止信令连接的请求时，如果信令连接是在变量中标识的，则UE发起信令连接释放指示 过程。例如，存在利用IE (信息元素)“CN域标识”标识的特定CN域的变量ESTABLISHED, SIGNALING_C0NNECTI0NSo如果该变量未标识任何现有信令连接，则以另一种方式来中止对 该特定CN域的信令连接的任何正在进行的建立。当在Cell_PCH或URA_PCH状态中发起信 令连接释放指示过程时，UE使用原因“上行链路数据发送”来执行小区更新过程。当成功地 完成小区更新过程时，UE继续接下来的信令连接释放指示过程。Bp,UE将信息元素(IE) "CN域标识”设置为由上层逻辑层指示的值。IE的值指示 以下CN域该CN域的关联的信令连接是上层所标记要释放的。如果将CN域标识被设置为 PS域，并且如果上层指示了发起该请求的原因，则相应地设置IE “信令释放指示原因”。UE 还将具有由上层指示的标识的信令连接从变量“ESTABLISHED_SIGNALING_CONNECTIONS”中 移除。UE在例如专用控制信道(DCCH)上使用肯定应答模式的无线链路控制(AMRLC)来发 送信令连接释放指示消息。当RLC确认成功传送了释放指示消息时，该过程结束。根据本公开的实施例，还使用IE“信令释放指示原因”。该释放原因与例如现有的 消息定义对齐。例如，将上层释放原因消息构造为
15 在该示例中，T3310、T330和Τ3340到期与先前标识的对应编号的定时器的到期相 对应。尽管预期结果与由原因值标识的结果相对应，但是在一个实施方式中，原因值可被设 置为“UE请求的PS数据会话结束”而不是“UE请求的空闲转移”，以移除对空闲转移的偏好 的UE指示，并提供UTRAN以决定状态转移。优选地但不是必须地，对信令连接释放指示的 扩展是非临界扩展。现在参照图9。图9是示例UE监视是否发送针对各个域(例如PS或CS)的信令 连接释放指示的流程图。该过程开始于步骤910。UE转移至步骤912，在步骤912中，UE进行检验以查看是否存在异常条件。这种 异常条件可以包括例如如上所述的定时器Τ3310、定时器Τ3320或定时器Τ3340到期。如果 这些定时器到期特定的预定次数或者如果基于这些定时器中任一个的到期而接收到显式 拒绝，则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中，该过程结束。基于UE的无线资源简档，转移指示的接收和检查可以导致网络元件发起分组交 换数据连接终止或者备选地转移至另一个更适合的状态。如上所述，在一些实施方式中，转移指示中原因的缺失还可以用于确定转移指示 是正常条件还是异常条件的结果以及是否必须发出警报。例如，如果添加原因以仅表示正 常条件(即非异常，例如针对PS数据会话结束和/或向空闲模式的转移的请求)，并且网络 元件接收到未添加原因的转移指示，则网络元件可以从原因的缺失推断出转移指示是异常 条件的结果并发出警报。相反，在另一个示例中，如果添加原因以仅表示异常条件，并且网 络元件接收到不具有原因的转移指示，则网络元件可以从原因的缺失推断出转移指示是正 常条件(例如针对PS数据会话结束和/或向空闲模式的转移的请求)的结果并不发出警 报。本领域技术人员应当理解，步骤1020可以用于在各种警报条件之间进一步区分。 例如，T3310超时可以用于保持第一统计数据集合，T3330超时可以用于保持第二统计数据
17集合。步骤1020可以在异常条件的原因之间进行区分，从而允许网络运营商更有效率地跟 踪性能。网络包括功能元件，可由例如通过处理器的操作而执行的应用或算法来实现，或 者可由硬件实现方式来实现，该功能元件形成检查器和警报产生器。检查器被配置为检查 转移指示的转移指示原因字段。检查器检验转移指示原因字段是否指示异常条件。警报产 生器被配置为在检查器的检查确定了信令连接释放指示原因字段指示异常条件的情况下 可选择地产生警报。在一个实施方式中，当接收到信令连接释放指示时，UTRAN转发接收到的原因并从 上层请求释放信令连接。然后，上层能够发起信令连接的释放。IE信令释放指示原因指示 UE的上层原因，以触发UE的RRC发送消息。该原因可能是异常上层过程的结果。通过对 IE的成功接收来确保对消息的原因的区分。可能的场景包括以下场景其中，在RLC确认成功传送了信令连接释放指示消息 之前，在信令无线承载RB2上RLC实体的发送侧发生重新建立。在这种发生的情况下，UE使 用信令无线承载RB2上的AMRLC在例如上行链路DCCH上重传信令连接释放指示消息。在 RLC确认成功传送了信令连接释放指示或请求消息之前发生来自UTRAN过程的RAT (无线接 入技术)间切换的情况下，当处于新的RAT中时，UE中止信令连接。在另一实施例中，不利用“信令连接释放指示或请求”，而是可以利用“优选状态请 求”。与上面图9和10所述的功能类似的功能可以适用于该优选状态请求指示。在一个实施例中，当UE知道它在延长的持续时间内不太可能需要发送任何更多 的PS域数据时，并且在例如没有CS域数据的情况下，该UE使用优选状态请求指示来向 UTRAN给出与优选RRC状态相关的信息。例如，使用AM RLC在DCCH上从UE向UTRAN发送 这样的消息。下面示出了示例消息。 优选RRC状态请求在触发(例如应用触发、数据传输完成、或者本文描述的其他触发)之后，UE使用 优选RRC状态指示原因信息元素来向UTRAN提供与优选RRC状态相关的信息。IE可以看起 来像 现在参照图20。图20示出了实施例，在该实施例中，从UE向UTRAN发送优选状态 请求。该过程开始于步骤2010并进行至步骤2012，在步骤2012中，在UE上检验以确定UE 处的条件是否适于发送改变状态请求。在本公开中以下参照例如图11来描述这种条件，并 且这种条件可以包括UE上的一个或多个应用确定它们完成数据交换。如果在步骤2012中该条件不适于发送改变状态请求，则该过程自身循环并继续 监视直到条件适于发送改变状态请求为止。一旦条件适合，该过程就进行至步骤2020，在步骤2020中，向UTRAN发送优选状态 请求。在上表中示出了示例优选状态请求。然后，该过程进行至步骤2022，在步骤2022中，进行检验以确定优选状态请求是 否成功。本领域技术人员应当理解，这可能意味着UTRAN已经成功地接收到优选状态请求 并已经发起了向由UE指示的状态的状态转移。如果是，则该过程进行至步骤2030并结束。相反，如果在步骤2022中确定了该请求没有成功，则该过程进行至步骤2024并等 待一段时间。可以使用“禁止持续时间”来实现这种等待，这将不允许移动在经过给定持续 时间之前发送另一个优选状态请求消息。备选地，该过程可以限制给定时间段内优选状态 请求消息的数目(例如10分钟内不超过15条消息)。禁止持续时间和限制持续时间内消 息数目的组合也是可能的。该持续时间可以是预定的，例如在标准中定义的值，可以由网络元件设置，例如作 为RRC连接请求、RRC连接释放、无线承载建立或系统信息广播消息的一部分。此外，可以 基于优选状态请求消息内的参数来设置该持续时间。从而，如果UE正在请求转移至Cell_ PCH而不是空闲，则该持续时间可以更长。网络元件发信号通知持续时间可以采用信息元素的形式，例如 禁止优选RRC状态请求一旦在步骤2024中该过程已经等待了预定的时间，该过程就回到步骤2012，以确 定是否仍然存在发送优选状态请求的条件。如果是，则该过程循环回到步骤2020和2022。在备选实施例中，可以移除步骤2022。在这种情况下，该过程可以从步骤2012进 行至步骤2020和步骤2024，此时该过程循环回到步骤2012。在RLC重新建立或者RAT间改变时可能发生例外。如果在RLC已经确认成功传送了优选RRC状态请求消息之前对RLC实体的发送侧进行重新建立，则在一个实施例中，UE使 用AM RLC在上行链路DCCH上重传优选RRC状态请求消息。在一个实施例中，如果在RLC已经确认成功传送了优选RRC状态请求消息之前发 生来自UTRAN过程的RAT间切换，则当在新的RAT中时，UE中止信令连接。在网络侧，与下面参照图18所述的方式类似地处理该过程。再一次参照图1，在一些情况下，与空闲模式110相比，可能更希望处于已连接模 式120中的诸如URA_PCH状态128之类的状态。例如，如果需要对CELL_DCH状态122或 CELL_FACH状态124的连接的延迟更低，则优选地处于已连接模式120PCH状态。存在多种 方式来完成这一点，例如通过改变3GPP规范以允许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)0PS用户平面630中的接入层616包括分组数据汇聚协议(PDCP)632。PDCP 632被 设计为使WCDMA协议适于承载UE与RNC之间(如图8所示)的TCP/IP协议，并可选地用 于IP业务量流协议首部压缩和解压缩。UMTS无线链路控制(RLC) 640和媒体接入控制(MAC)层650形成UMTS无线接口的 数据链路子层，并驻留在RNC节点和用户设备上。层1 (Ll)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以及诸如标识和订户相关信息等其他 fn肩、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)或类似的存储元件(未示出)。 本领域技术人员应当理解，可以将操作系统、专用设备应用程序、或其部件临时加载至诸如 RAM726之类的易失性存储器中。接收到的通信信号也可以被存储在RAM726中。此外，优选 地，唯一标识符也存储在只读存储器中。如图所示，闪存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可能 使用户可以通过外部设备或软件应用程序来设置偏好，并可能除了通过无线通信网络以外 还通过向UE700提供信息或软件下载，来扩展移动设备700的能力。交替的下载路径可以 例如用于通过直接的、因而可靠且可信的连接，将加密密钥加载至设备上，从而实现安全的 设备通信。备选地，串行端口 730可以用于其他通信，并可以包括通用串行总线(USB)端口。 接口与串行端口 730相关联。如短距离通信子系统之类的其他通信子系统740是另一可选组件，该组件可以提 供UE 700与不同系统或设备(不必是相似的设备)之间的通信。例如，子系统740可以包 括红外设备、以及关联电路和组件、或Bluetooth 通信模块，以提供与以类似方式启用的 系统和设备的通信。现在参照图8。图8是通信系统800的框图，通信系统800包括通过无线通信网络 进行通信的UE 802。UE 802与多个Node B 806中的一个进行无线通信。每一个Node B806负责空中 接口处理和一些无线资源管理功能。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。如在 3GPP TS 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.413 V5. 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和SGSN850之间使用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处示出。此处，两个分组数据服务是并发活动的，其每一个分组数据服务与被指定为 PDP1和PDP2的特定PDP上下文相关联。图1104表示对第一分组数据服务激活的PDP上下 文，图1106表示对第一分组数据服务分配的无线资源。并且，图1108表示对第二分组数据 服务激活的PDP上下文，图1112表示对第二分组数据服务分配的无线资源。UE请求由段 1114指示的作为服务请求的无线接入承载分配。并且，UE还请求根据本公开的实施例的由 段1116指示的无线承载服务释放。针对单独服务的服务请求和服务释放是彼此独立的，即 独立地产生的。在图11的示例示意图中，实质上同时分配PDP上下文以及针对关联PDP上 下文的无线资源。并且，如图所示当UE请求时，或者当RNC(无线网络控制器)决定释放无 线资源时，批准无线资源释放。响应于无线资源释放请求，或者响应于释放无线资源的其他决定，网络可选择地 拆除与分组数据服务相关联的无线资源。基于逐个无线接入承载而不基于整个信令连接， 进行无线释放请求，从而允许对资源分配的改进的粒度控制。在示例实施方式中，单一分组数据服务还可被形成为主服务和一个或多个次服 务，例如由标号1118和1122所指示。无线资源释放进一步允许标识一个或多个主和次服 务中的哪些服务的无线资源分配不再被需要或者在被需要的情况下希望被释放。从而提供 了有效率的无线资源分配。另外，由于出于其他目的现在可以更好地利用可能已分配给不 必要的处理的处理器功率，因此提供了对UE上的处理器的最优利用。图12示出了通信系统800的部分，S卩，根据本公开的实施例进行操作的、与多个 邻接分组数据服务会话相关的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)层处执行信令的实施方式中，无线网络控制器而不是SGSN 执行对UE的检查和转移。并且对应地，在RRC层处形成UE处体现的设备，或者该设备使所 产生的指示在RRC级发送。在示例控制流程中，在恰当时，更高层向NAS/RRC层通知不再需要将无线资源分 配给特定的PDP上下文。将RRC层指示消息发送至网络。该消息包括RAB ID或RB ID，该 RAB ID或RB ID例如向无线网络控制器标识分组数据服务。并且，作为响应，无线网络控制 器的操作触发解析过程以结束要返回给UE的无线资源释放、无线资源重配置或无线资源 控制连接释放消息。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，并将域设置为PC(分组交换)。然后，如框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 35a. m.之间接收到大量的数据，则在星期四的 8:32a. m.接收到该指示的情况下，网络可以决定由于在8:35a. 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处没有预期其他数据时)。基于该指示，网络元件检验 用户设备的无线资源简档，该无线资源简档可以同时包括静态和动态简档元素。网络元件 还可以检验安全措施以确保不发生不必要的转移。然后，基于该检验，网络元件可以决定什 么也不做或者转移至不同的模式或状态，或者拆除无线资源。应当理解，这向网络提供了对 其无线资源的更多控制并允许网络基于网络偏好而不是仅基于用户设备偏好来配置转移 决定。此外，在一些情况下，网络比设备具有更多与是否转移相关的信息。例如，用户设备 知道上行流通信并可以基于这一点来决定可以拆除连接。然而，网络可能已经接收到用户 设备的下行流通信，从而意识到其不能拆除连接。在这种情况下，还可以使用延迟定时器来引入延迟，以向网络提供对在不远的将来将不针对用户设备接收数据的更多确定性。
本文描述的实施例是具有与本公开的技术的单元相对应的单元的结构、系统或方 法的示例。本说明书可以使本领域技术人员能够作出和使用具有备选单元的实施例，该备 选单元同样与本公开的单元相对应。因此，本公开的技术的预期范围包括与本文描述的本 公开的技术并无不同的其他结构、系统或方法，并且还包括与本文描述的本公开的技术无 实质不同的其他结构、系统或方法。
权利要求
一种用于在用户设备上转移状态或模式的方法，包括在网络元件处接收转移指示；检验所述用户设备的无线资源简档；以及在所述网络元件处基于接收到的转移指示以及所述无线资源简档，进行转移决定。
2.根据权利要求1所述的网络元件，其中所述转移指示是来自所述用户设备上的应用 的、指示所述应用完成了数据交换的消息。
3.根据权利要求1或2所述的方法，所述转移指示由来自所述用户设备上的应用的、指 示所述应用完成了数据交换的消息来触发。
4.根据权利要求1至3中任一项所述的方法，其中所述转移指示还包括嵌入所述转移 指示中的数据。
5.根据权利要求4所述的方法，其中所述数据包括原因指示、差错概率以及无线资源 简档方面中的一个或多个。
6.根据权利要求1至5中任一项所述的方法，其中所述无线资源简档包括静态简档信肩、ο
7.根据权利要求6所述的方法，其中所述静态简档信息包括接入点名称、服务质量或 者分组数据协议上下文。
8.根据权利要求1至7中任一项所述的方法，其中所述无线资源简档包括转移简档。
9.根据权利要求8所述的方法，其中所述转移简档包括所述用户设备的状态是否应当 进行转移、状态转移偏好、延迟或不活动定时器值、或者用户设备正确请求转移的概率。
10.根据权利要求8所述的方法，其中所述转移简档是应用专用的。
11.根据权利要求8所述的方法，其中所述转移简档是应用转移简档的复合物。
12.根据权利要求1至11中任一项所述的方法，其中所述无线资源简档是所述用户设 备的所有无线接入承载无线资源简档的复合物。
13.根据权利要求1至12中任一项所述的方法，其中所述转移决定是选自以下组的决 定什么也不做；转移至较少消耗电池的状态；转移至空闲模式；以及拆除一个或多个无线 接入承载。
14.一种适于根据前述任一权利要求所述的方法来转移状态或模式的网络元件，所述 网络元件包括通信子系统，适于接收转移指示； 存储器；以及处理器，适于检验所述用户设备的无线资源简档，所述处理器还适于进行转移决定。
15.根据权利要求14所述的网络元件，其中所述存储器适于存储所述无线资源简档。
16.一种用于从用户设备发起转移决定的方法，包括 确定在所述用户设备处是否期望状态/模式转移；响应于该确定，向网络发送转移指示；以及 基于所述转移指示，从网络接收转移决定。
17.根据权利要求16所述的方法，其中所述转移指示由来自所述用户设备上的应用 的、指示所述应用完成了数据交换的消息来触发。
18.根据权利要求17所述的方法，其中所述转移指示是所述用户设备上的所有应用的复合状态。
19.根据权利要求16至18中任一项所述的方法，其中所述转移指示还包括嵌入所述转 移指示中的数据。
20.根据权利要求16至19中任一项所述的方法，其中所嵌入的数据是转移简档。
21.根据权利要求16至20中任一项所述的方法，其中所述转移指示是所述用户设备和 所述网络之间的专用消息。
22.根据权利要求16至21中任一项所述的方法，还包括在发送之后设置定时器。
23.根据权利要求22所述的方法，还包括检验发送是否成功，并响应于该检验，延迟 重新发送所述转移指示，直到所述定时器到期为止。
24.根据权利要求22所述的方法，其中所述定时器的值是从所述网络接收的。
25.根据权利要求22所述的方法，其中所述定时器的值是基于所述转移指示来确定的。
26. 一种适于根据权利要求16至25中任一项所述的方法来发起转移决定的用户设备， 所述用户设备包括通信子系统，适于与网络进行通信； 存储器；以及处理器，适于确定是否期望状态/模式转移，并且还适于响应于该确定来向所述网络 发送所述转移指示，其中所述用户设备适于基于所述转移指示从所述网络接收转移决定。
27.根据权利要求26中任一项所述的用户设备，适于根据权利要求22至25中任一项 所述的方法来发起转移决定，所述用户设备还包括定时器，适于在所述处理器已经发送所 述转移指示之后被设置。
28.根据权利要求27所述的用户设备，其中所述处理器适于检验发送是否成功，并响 应于该检验，延迟重新发送所述转移指示，直到所述定时器到期为止。
29. 一种计算机可读介质，包括指令，当所述指令由用户设备的处理器执行时，所述指 令使所述用户设备适于执行根据权利要求16至25中任一项的所有步骤。
30. 一种计算机可读介质，包括指令，当所述指令由网络元件的处理器执行时，所述指 令使所述网络元件适于执行根据权利要求1至13中任一项的所有步骤。
全文摘要
本发明提供了一种用于在用户设备上转移状态或模式的方法和状态，所述方法具有下列步骤在网络元件处接收转移指示；检验所述用户设备的无线资源简档；以及在所述网络元件处基于接收到的转移指示以及所述无线资源简档，进行转移决定。
文档编号H04W52/02GK101911817SQ200880124457
公开日2010年12月8日 申请日期2008年11月13日 优先权日2007年11月13日
发明者克劳德·阿泽利耶, 戈登·彼得·扬, 杰弗里·威廉·维尔塔宁, 穆罕默德·哈利杜·伊斯兰, 铃木敬 申请人:捷讯研究有限公司