用于控制异构移动通信系统之间的重定向的方法和装置

摘要

本发明是一种用于控制异构移动通信系统之间的重定向的方法，包括步骤：其连接请求被第一通信系统(UTRAN)拒绝的终端从该终端打算连接的第二通信系统接收指示第二通信系统不支持该终端的信息；设置用于防止重定向到第二通信系统的信息；以及向第一通信系统发送包括该信息的用于连接到第一通信系统的请求。

说明书

技术领域

本公开涉及用于控制异构(heterogeneous)移动通信系统之间的用户设 备(UE)的重定向(re-direction)的方法和装置。

背景技术

通常，移动通信系统已经被开发为在保证用户移动性的同时提供通信服 务。由于快速的技术进步，移动通信系统能够不但提供语音通信，而且提供 高速数据通信服务。

近年来，3GPP(第3代伙伴计划)已经开发作为下一代移动通信系统 的长期演进(LTE)的规范。LTE系统，也被称为演进通用地面无线接入网 络(E-UTRAN)，实现支持超过现有数据速率的大约100Mbps的最大数据 速率的基于高速分组的通信，目标在2010年商业化。为此，已经考虑多种 途径，诸如通过简化网络架构来减少通信路径上的节点数量、以及引入尽可 能接近无线信道的无线协议。

其间，不同于语音服务，根据待发送的数据量和信道条件来确定将要分 配给数据服务的资源。因此，在诸如移动通信系统的无线通信系统中，以这 样的方式执行管理以使得调度器基于待发送的资源量、信道条件、和数据量 来分配传输资源。这样的管理也在被认为是下一代移动通信系统之一的LTE 系统中执行，并且位于基站中的调度器管理和分配无线传输资源。

用户设备(UE)可以用诸如无线接入技术(RAT)间切换(HO)、小区 (重新)选择重定向等各种方式连接到可支持的系统，不但包括LTE通信系 统，而且包括其他通信系统，诸如通用移动电信系统(UMTS)，也被称为 UTRAN。因此，为了稳定地支持连接，已经进行标准化和开发。

发明内容

技术问题

根据本公开的一方面，提供一种用于控制异构移动通信系统之间的重定 向的方法，该方法包括：由其连接请求已经被第一通信系统(UTRAN)拒 绝的用户设备(UE)从UE打算重新连接到的第二通信系统接收指示第二通 信系统不支持UE的信息；设置用于防止重定向到第二通信系统的信息；以 及向第一通信系统发送包括该信息的用于连接到第一通信系统的连接请求。

根据本公开的另一方面，提供一种用于控制异构移动通信系统之间的重 定向的方法，该方法包括：从其连接请求已经被第一通信系统(UTRAN) 拒绝的用户设备(UE)打算重新连接到的第二通信系统接收指示第二通信 系统不支持UE的信息；发送用于重新连接到第一通信系统的连接请求并且 接收用于该连接请求的拒绝消息；以及如果该拒绝消息包括用于重定向的指 令，则忽略用于重定向到第二通信系统的指令并且搜索用于重新连接的另一 个合适的小区。

根据本公开的另一方面，提供一种用于控制异构移动通信系统之间的重 定向的方法，该方法包括：从其连接请求已经被第一通信系统(UTRAN) 拒绝的用户设备(UE)打算重新连接到的第二通信系统接收连接释放消息； 确定是否该连接释放消息中包括的频率优先级信息中不包括第二通信系统 的当前频率；如果确定该频率优先级信息中不包括第二通信系统的当前频 率，则将第一通信系统确定为用于重新连接的另一个合适的小区；以及通过 连接请求消息向第一通信系统发送频率优先级信息。

根据本公开的另一方面，提供一种用于控制异构移动通信系统之间的重 定向的方法，该方法包括：从用户设备(UE)接收连接请求；如果用于配 置将要提供给UE的重定向信息的在该连接请求中包括的信息元素的值指示 第二通信系统的频率资源不被支持，则确定是否需要拒绝UE的连接请求； 如果确定需要拒绝该信息元素的值，则通过排除被该信息元素的值指示为不 被支持的第二通信系统的频率资源来设置UE的重定向信息；以及向UE发 送包括所设置的重定向信息的UE的连接拒绝消息。

根据本公开的另一方面，提供一种用于控制异构移动通信系统之间的重 定向的方法，该方法包括：从用户设备(UE)接收连接请求；以及如果包 括在该连接请求中的信息满足三个条件之一，则终止与UE的连接，其中在 三个条件当中，第一条件是当用于配置将要提供给UE的重定向信息的信息 元素的值指示第二通信系统的频率资源不被支持时，第二条件是当该连接请 求中不包括该信息元素的值时，并且第三条件是当指示不可能执行包括用于 重定向到第二移动通信系统的指令的连接拒绝过程的新指示符被包括时。

根据本公开的另一方面，提供一种用于控制异构移动通信设备异常之间 的重定向的用户设备(UE)，该UE包括：接收器，被配置为从其连接请求 已经被第一通信系统(UTRAN)拒绝的UE打算重新连接到的第二通信系统 接收指示第二通信系统不支持UE的信息；消息处理器，被配置为设置用于 防止重定向到第二通信系统的信息；以及发送器，被配置为向第一通信系统 发送包括该信息的用于连接到第一通信系统的连接请求。

根据本公开的另一方面，提供一种用于控制异构移动通信设备异常之间 的重定向的用户设备(UE)，该UE包括：接收器，被配置为从其连接请求 已经被第一通信系统(UTRAN)拒绝的UE打算重新连接到的第二通信系统 接收指示第二通信系统不支持UE的信息；向第一通信系统发送用于重新连 接的连接请求，并且接收用于该连接请求的拒绝消息；以及控制器，被配置 为如果该拒绝消息包括用于重定向的指令，则忽略用于重定向到第二通信系 统的指令并且搜索用于重新连接的另一个合适的小区。

根据本公开的另一方面，提供一种用于控制异构移动通信设备异常之间 的重定向的用户设备(UE)，该UE包括：接收器，被配置为从其连接请求 已经被第一通信系统(UTRAN)拒绝的UE打算重新连接到的第二通信系统 接收连接释放消息；控制器，被配置为确定该连接释放消息中包括的频率优 先级信息中是否不包括第二通信系统的当前频率，并且如果确定该频率优先 级信息中不包括第二通信系统的当前频率，则将第一通信系统确定为用于重 新连接的另一个合适的小区；以及发送器，被配置为通过连接请求消息向第 一通信系统发送频率优先级信息。

根据本公开的另一方面，提供一种用于控制异构移动通信基站之间的重 定向的基站，该基站包括：接收器，被配置为从用户设备(UE)接收连接 请求；控制器，被配置为如果用于配置将要提供给UE的重定向信息的在该 连接请求中包括的信息元素的值指示第二通信系统的频率资源不被支持，则 确定是否需要拒绝UE的连接请求，并且如果确定需要拒绝UE的连接请求， 则通过排除被该信息元素的值指示为不被支持的第二通信系统的频率资源 来设置UE的重定向信息；以及发送器，被配置为向UE发送包括所设置的 重定向信息的UE的连接拒绝消息。

根据本公开的另一方面，提供一种用于控制异构移动通信基站之间的重 定向的基站，该基站包括：接收器，被配置为从用户设备(UE)接收连接 请求；以及控制器，被配置为如果该连接请求中的信息满足三个条件之一， 则终止与UE的连接，其中在三个条件当中，第一条件是当用于配置将要提 供给UE的重定向信息的信息元素的值指示第二通信系统的频率资源不被支 持时，第二条件是当该连接请求中不包括该信息元素的值时，并且第三条件 是当指示不可能执行包括用于重定向到第二移动通信系统的指令的连接拒 绝过程的新指示符被包括时。

根据本公开的另一方面，提供一种用于控制异构移动通信系统之间的重 定向的方法，该方法包括：设置关于对用于用户设备(UE)的每个公共陆 地移动网络(PLMN)允许的无线接入技术(RAT)和不被允许的RAT中的 至少之一的信息；以及通过使用关于RAT的至少之一的信息来确定对于登 记的PLMN将要关闭的RAT。

根据本公开的另一方面，提供一种用于控制异构移动通信系统之间的重 定向的方法，该方法包括：由用户设备(UE)检查在UE的网络登记中的当 前公共陆地移动网络(PLMN)中是否允许驻扎的(camping)RAT的使用； 以及如果作为检查的结果，不允许驻扎的RAT的使用，则向UE递送指示当 前使用的RAT的使用不被允许的信息。

附图说明

图1是用于描述位于一般异构移动通信系统中的UE连续执行重定向、 无法完成到任何系统的连接的情况的图；

图2是用于描述UE与UTRAN之间的一般的连接请求和拒绝过程的图；

图3是用于描述UE与UTRAN之间的一般的TAU过程的图；

图4是示出根据本公开的第一实施例的操作的流程图；

图5是示出根据本公开的第一实施例的UE的操作的流程图；

图6是示出根据本公开的第一实施例的UTRAN的操作的流程图；

图7是示出根据本公开的第一实施例的MME的操作的流程图；

图8是示出根据本公开的第一实施例的E-UTRAN的操作的流程图；

图9是示出根据本公开的第二实施例的操作的流程图；

图10是示出根据本公开的第二实施例的UE的操作的流程图；

图11是示出根据本公开的第二实施例的UTRAN的操作的流程图；

图12是示出根据本公开的第三实施例的操作的流程图；

图13是示出根据本公开的第三实施例的UE的操作的流程图；

图14是示出根据本公开的第四实施例的操作的流程图；

图15是示出根据本公开的第四实施例的UE的操作的流程图；

图16是示出根据本公开的第四实施例的UTRAN的操作的方框图；

图17是示出根据本公开的第五实施例的操作的流程图；

图18是示出根据本公开的第五实施例的UE的操作的流程图；

图19是用于描述本公开的第六实施例中要解决的问题的图；

图20是用于描述本公开的第六实施例中使用为PLMN特定的允许的 RAT设置的信息的过程的图；

图21是用于描述本公开的第六实施例中向UE递送在MME/SGSN中不 允许的RAT处理信息的方法的图；

图22是应用本公开的实施例的UE的框图；以及

图23是根据本公开的实施例的基站的框图。

具体实施方式

下文中将关于附图来描述本公开的各种实施例。在以下的描述中，当在 此合并的已知功能和配置可能模糊本公开的主题内容时，将省略其详细描 述。在此使用的术语是基于本公开中的功能来定义的，并且根据用户、操作 者的意图或通常实践而可以变化。因此，应该基于贯穿说明书的内容来进行 术语的定义。

本发明涉及用于有效地控制在异构移动通信系统之间的重定向的方法 和装置。为了方便起见，在本说明书中，将描述异构移动通信系统中的操作， 并且将描述通用地面无线接入网络(UTRAN)和演进通用地面无线接入网 络(E-UTRAN)作为异构移动通信系统的示例。一般，如果特定的原因发 生，则E-UTRAN(或UTRAN)拒绝UE的连接请求，并且执行促进与另一 方系统(即，UTRAN(或E-UTRAN))的连接的重定向。此时，其RRC连 接请求已经被E-UTRAN(或UTRAN)拒绝的UE基于重定向信息再次尝试 连接到另一方系统，即UTRAN(或E-UTRAN)。然而，取决于环境，UE 可能连续地执行重定向，无法完成到任何系统的连接。

图1是用于描述位于一般异构移动通信系统中的UE连续地执行重定 向、无法完成到任何系统的连接的情况的图。

参照图1，打算连接至UTRAN的UE 105尝试与UTRAN 100的连接建 立。为此，在操作110中，UE 105向UTRAN 100发送无线资源控制(RRC) 连接请求消息。如果UTRAN 100出于特定理由拒绝RRC连接请求消息，则 UTRAN 100在操作115中向UE 115递送RRC连接拒绝消息。RRC连接拒 绝消息可以包括作为可选项的重定向信息。重定向信息可以包括指示UE 105 需要尝试连接至的另一个频率或另一个系统的信息。其RRC连接请求已经 被拒绝的UE 105在操作120中基于所述信息尝试连接至另一频率或另一系 统。例如，UE 105可以被重定向到E-UTRAN。为此，UE 105尝试连接至 E-UTRAN 130，并且在操作125中向E-UTRAN 130发送RRC连接设置完成 消息以向E-UTRAN的移动管理实体(MME)递送跟踪区域更新(TAU)请 求消息。UE 105通过使用TAU请求消息，向E-UTRAN 130通知UE 105的 位置被改变到E-UTRAN。然而，E-UTRAN出于一些理由可能不支持UE 105。 例如，理由之一可能是，例如，因为没有预先商定支持用于漫游的UE的服 务。假定满足前述理由之一，因而E-UTRAN不支持UE 105。接着，在操作 135中，MME通过下行链路(DL)信息传送消息向UE 105递送TAU拒绝 消息。E-UTRAN 130在操作140中向UE 105递送RRC连接释放消息，从 而终止与UE 105的RRC连接模式。该情况下，UTRAN可以仍然很有可能 向UE 105提供非常好的信道。因此，UE 105在操作145中重新尝试到 UTRAN 100的RRC连接。然而，UE 105的RRC连接请求消息被UTRAN 100 拒绝，并且重复上述过程，使得可能继续不连接到任何系统。该情况下，为 了离开不连接到任何系统的状态，需要约束UE重新尝试RRC连接到不支 持用于UE的服务的系统(例如，连接到E-UTRAN)的操作。

在前面的描述中提供的与UTRAN和E-UTRAN的RRC连接与本公开 紧密相关联，从而将进一步被详细描述。

图2是用于描述UE与UTRAN之间的一般连接请求和拒绝过程的图。

参照图2，在操作210中，UE 200向UTRAN 205发送RRC连接请求消 息用于连接到UTRAN，从而请求与UTRAN的连接。该操作被称为连接建 立过程。RRC连接请求消息可以包括关于预重定向信息的信息元素(IE)， 如表1中所示。参照表1，IE显示UE 200可以支持的E-UTRAN频分双工 (FDD)或E-UTRAN时分双工(TDD)。IE可以包括具有布尔型值(‘1’ 或‘0’分别指示真或假)的两个IE。如果UE 200能够支持E-UTRAN FDD， 则‘IE support of E-UTRA FDD’被指示为‘可支持的’，即‘1’。UTRAN 205通过使用IE的值来配置将要提供给UE 200的重定向信息。

[表1]

预重定向信息(参考TS25.331)

如果RRC请求消息被拒绝，则UTRAN 205在操作215中向UE 200发 送RRC连接拒绝消息。RRC连接拒绝消息可以包括IE重定向信息。参考表 2，在IE中，指示UE将要重定向到的另一个频率或另一个系统。

[表2]

重定向信息

图3是用于描述UE与UTRAN之间的一般TAU过程的图。

参照图3，如果UE 300新尝试连接到E-UTRAN，则UE 300必须向MME 310通知UE 300的位置被改变到E-UTRAN，这被称为TAU过程。为此， UE 300需要执行RRC连接建立过程。即，UE 300在操作315中向E-UTRAN 305发送RRC连接请求消息。然后，在操作320中，E-UTRAN 305向UE 300 发送RRC连接设置消息。UE 300在操作325中向E-UTRAN 305递送RRC 连接设置完成消息。RRC连接设置完成消息可以包括将要递送给MME的 NAS容器和TAU请求消息。因而，虽然未示出，但是E-UTRAN 305向MME 310透明地递送从RRC连接设置完成消息获得的NAS容器而不解码NAS 容器。结果，在操作330中，UE 300向MME 310发送TAU请求消息。然 而，如上所述，E-UTRAN出于特定的理由可能不支持UE 300。如果E-UTRAN 不支持UE 300，则MME 310在操作335中针对UE 300声明演进分组系统 移动性管理(EMM)已注销(DEREGISTERED)状态。一旦进入EMM已 注销状态，UE 300就不能被成功地登记在MME 310中，从而被从MME 310 分离(detach)。MME 310在操作340中向UE发送TAU拒绝消息。TAU拒 绝消息包括指示拒绝TAU请求消息的理由的IE EMM原因。下面提供的表 3显示IE EMM原因的示例，并且通过使用总共2字节来指示拒绝的理由。

[表3]

EMM原因信息元素

E-UTRAN 305在操作345中使用DL信息传送消息向UE 300递送TAU 拒绝消息。MME 310在操作350中向E-UTRAN 305递送UE上下文释放命 令消息，从而向E-UTRAN 305指示UE 300的RRC连接模式的终止。接着， 已经接收到UE上下文释放命令消息的E-UTRAN 305在操作355中向UE 300递送RRC连接释放消息，从而向UE 300指示RRC连接模式的终止。 RRC连接释放消息可以包括作为可选项的频率优先级信息IE  idleModeMobilityControlInfo id。IE指示当UE执行到另一个频率的小区重新 选择时的系统特定的频率优先级。这里，可以从包括在频率优先级信息IE  idleModeMobilityControlInfo中的优先级中排除作为已经拒绝UE的系统的示 例的图3的已经拒绝UE 300的E-UTRAN的当前频率。

下文中，本公开将提出用于防止在TAU过程上被E-UTRAN拒绝的UE 在RRC连接到UTRAN失败之后重新尝试连接到E-UTRAN的方法。

<第一实施例>

在本公开的第一实施例中，基于从MME接收的TAU拒绝消息的IE EMM原因值、或从E-UTRAN接收的RRC连接释放消息的频率优先级信息， UE设置将要发送到UTRAN的RRC连接请求消息的IE预重定向信息。即， 为了防止UTRAN指示到已经拒绝RRC连接请求请求的E-UTRAN的重定 向，UE将IE预重定向信息中包括的值设置为指示与拒绝之的E-UTRAN对 应的E-UTRA FDD或E-UTRA TDD不被支持。

图4是示出根据本公开的第一实施例的操作的流程图。

参照图4，操作410和415与图2的操作210和215相同，从而将不再 详细描述。同样地，操作430至470对应于图3的描述，从而将不再详细描 述。然而，在操作455中，由MME发送给UE 400的TAU拒绝消息的IE EMM 原因通过常规定义的值当中的特定值来指示，或者通过根据本公开的第一实 施例的新定义的值来指示。例如，参照表3，当IE EMM原因具有常规定义 的原因的各种值当中的‘跟踪区域不被允许’值时，将执行在本公开的第一 实施例中提出的操作。替换地，除了常规定义的原因的各种值之外，可以定 义新的EMM原因值。

假定在操作455中TAU拒绝消息的IE EMM原因指示‘跟踪区域不被 允许’或包括新定义的EMM原因值。然后，在操作475中，其RRC连接 请求已经被E-UTRAN拒绝的UE 400搜索作为用于重新连接的合适的小区 的UTRAN。这里，为了方便起见，描述的是所找到的UTRAN与已经拒绝 RRC连接的UTRAN相同的示例，但是所找到的UTRAN可以与拒绝的 UTRAN不相同。

在操作485中，UE 400将预重定向信息的IE的值设置为指示先前拒绝 之的E-UTRAN不是可支持的。更具体地，UE 400将预重定向信息的IE(即， “IE Support of E-UTRA FDD”和“Support of E-UTRA TDD”)设置为指示 E-UTRAN不是可支持的。用另一种方式，代替考虑EMM原因值，可以使 用RRC连接释放消息的频率优先级信息IE idleModeMobilityControlInfo。即， 从频率优先级信息IE idleModeMobilityControlInfo中排除已经拒绝RRC连接 的E-UTRAN的当前频率。因而，UE 400在将与从频率优先级信息IE idleModeMobilityControlInfo中排除的E-UTRAN对应的值设置为指示IE  Support of E-UTRA FDD或Support of E-UTRA TDD中‘不可支持’。UE 400 在操作490中向UTRAN 405发送包括所设置的IE的RRC连接请求消息。

图5是示出根据本公开的第一实施例的UE的操作的流程图。

参照图5，在操作500中，UE从UTRAN接收RRC连接拒绝消息。在 操作505中，UE通过使用在所接收的RRC连接拒绝消息中包括的重定向信 息，搜索用于重新连接的合适的小区，即，E-UTRAN。在操作510中，UE 针对E-UTRAN执行RRC连接建立。在操作515中，UE向MME递送TAU 请求消息。在操作520中，如上面参照图4所述，UE确定是否满足两个条 件之一，并且UE基于所述确定结果来设置RRC连接请求消息的IE  Pre-redirection info。第一条件是当TAU拒绝消息的IE EMM原因值指示预 定的值(即，‘跟踪区域不被允许’)时。第二条件是当从RRC连接释放消 息的频率优先级信息，即，从频率优先级信息idleModeMobilityControlInfo 中的优先级中排除E-UTRAN的当前频率信息时。在操作520中，如果满足 两个条件中的至少一个，则UE确定是否执行随后的过程，即，操作525至 535。预定义的值可以使用常规定义的值当中的特定值或者根据本公开的第 一实施例新定义的值。

如果UE确定两个条件的任何一个都不被满足，则不应用本公开的第一 实施例。即，如果UE没有接收到TAU拒绝消息，则该条件对应于这样的 情况：UE没能获得预定义的值或者新定义的IE EMM原因或者接收到不包 括频率优先级信息的RRC连接释放消息。在操作525中，UE搜索用于重新 连接的UTRAN。在操作530中，UE将Pre-redirection info的值设置为指示 已经拒绝RRC连接的E-UTRAN的当前频率不是可支持的。更具体地，UE 将Pre-redirection info(即，“IE Support of E-UTRA FDD”或“Support of  E-UTRA TDD”)的值设置为指示当前频率不是可支持的。在操作535中， UE向UTRAN发送包括如上述设置的IE值的RRC连接请求消息。

图6是示出根据本公开的第一实施例的UTRAN的操作的流程图。

参照图6，在操作600中，UTRAN从UE接收RRC连接请求消息。在 操作605中，UTRAN确定RRC连接请求消息中的Pre-redirection info的IE 的值(即，‘IE Support of E-UTRA FDD’和‘Support of E-UTRA TDD’的 值)是‘真’还是‘假’。如果‘IE Support of E-UTRA FDD’和‘Support of  E-UTRA TDD’的值全都为‘真’，则它们指示E-UTRA FDD和E-UTRA TDD 都是可支持的。如果‘IE Support of E-UTRA FDD’和‘Support of E-UTRA  TDD’的值全都是‘假’，则它们指示E-UTRA FDD或E-UTRA TDD在UE 中都不是可支持的。从而，当指示UE的重新定向时，可以排除被指示为‘假’ 的E-UTRA FDD或E-UTRA TDD。因此，在操作610中，UTRAN确定是否 需要对于UE的RRC连接拒绝。在操作615中，UTRAN设置重定向信息使 得从重定向信息中排除被指示为‘假’的E-UTRA FDD或E-UTRA TDD。 如果拒绝UE的RRC连接请求消息，则UTRAN在操作620中向UE发送包 括以上设置的重定向信息的RRC连接拒绝消息。

图7是示出根据本公开的第一实施例的MME的操作的流程图。

参照图7，在操作705中，MME从UE接收TAU请求消息。然后，在 操作707中，MME根据预定的要求确定在E-UTRAN中是否支持UE。作为 预定要求的示例，使用UE的漫游。例如，假定在E-UTRAN中不支持漫游 的UE。

如果确定在E-UTRAN中支持UE，则MME在操作720中向UE发送 TAU接受消息。另一方面，如果确定在E-UTRAN中不支持UE，则MME 在操作710中将EMM原因值设置为预定义的值，指示在E-UTRAN中不支 持UE。在操作715中，MME向UE发送包括所设置的EMM原因值的TAU 拒绝消息。

图8是示出根据本公开的第一实施例的E-UTRAN的操作的流程图。

参照图8，在操作800中，E-UTRAN从UE接收RRC连接设置完成消 息。在操作805中，E-UTRAN确定是否从MME接收到UE上下文释放命 令或者用于UE的RRC连接释放定时器已经期满。如果确定E-UTRAN从 MME接收到UE上下文释放命令或者用于UE的RRC连接释放定时器已经 期满，则E-UTRAN在操作810中向UE发送包括频率优先级信息IE  idleModeMobilityInfo的RRC连接释放消息。如果确定E-UTRAN没有从 MME接收到UE上下文释放命令并且用于UE的RRC连接释放定时器尚未 期满，则E-UTRAN停止操作。

<第二实施例>

在本公开的第二实施例中，基于从MME接收到的TAU拒绝消息的IE EMM原因值或者从E-UTRAN接收到的RRC连接释放消息的频率优先级信 息，UE确定指令UTRAN不执行包括用于重定向到E-UTRAN的指令的RRC 连接拒绝过程，并且明确或隐含地向UTRAN指示所述确定。用于明确地指 示所述确定的方法包括定义指令UTRAN不要执行包括用于重定向到 E-UTRAN的指令的RRC连接拒绝过程的新指示符，并且通过RRC连接请 求消息向UTRAN递送该新指示符。作为定义指示符的替换方式，UTRAN 可以被指令为不执行用于UE的任何重定向，或者可以在RRC连接请求消 息中包括不应该对其执行重定的RAT列表。用于隐含地指示所述确定的方 法包括将在常规的Pre-redirection info中包括的IE(即，‘IE Support of  E-UTRA FDD’和‘Support of E-UTRA TDD’两者)设置为‘假’，并且向 UTRAN发送包括所设置的IE的全部或者不包括所设置的IE的RRC连接请 求消息。用这种方式，UE指令UTRAN不执行包括用于重定向到E-UTRAN 的指令的RRC连接拒绝过程。

图9是示出根据本公开的第二实施例的操作的流程图。

参照图9，操作910和915与图2的操作210和215相同，从而将不再 详细描述。同样地，操作930至970对应参照图3进行的描述，从而将不再 详细描述。在操作955中，从MME 925向UE 900发送的TAU拒绝消息的 IE EMM原因具有常规定义的值当中的值或者根据本公开的第二实施例新定 义的值。例如，参照表3，当IE EMM原因具有常规定义的原因的各种值中 的‘跟踪区域不被允许’时，将执行在本公开的第二实施例中提出的操作。 替换地，除了常规定义的原因的各种值之外，可以定义新的EMM原因值。 在操作975中，其RRC连接请求消息已经被E-UTRAN拒绝的UE 900搜索 作为用于重新连接的合适的小区的UTRAN。在此，为了方便起见，描述的 是所找到的UTRAN与已经拒绝RRC连接的UTRAN相同的示例，但是所 找到的UTRAN可以不与拒绝的UTRAN相同。在操作985中，UE 900用两 种方式之一来指令UTRAN 900不执行包括用于重定向到E-UTRAN的指令 的RRC连接拒绝过程。在第一方式中，UE 900将指示指令的新定义的指示 符合并到RRC连接请求消息中。在第二方式中，UE 900将Pre-redirection info 中的IE(即，‘IE Support of E-UTRA FDD’和‘Support of E-UTRA TDD’ 两者)的值设置为指示不可支持，并且将IE合并或不合并在RRC连接请求 消息中。在操作990中，UE 900向UTRAN 980发送包括新指示符或IE或 者不包括Pre-redirection info的RRC连接请求消息。

图10是示出根据本公开的第二实施例的UE的操作的流程图。

参照图10，在操作1000中，UE从UTRAN接收RRC连接拒绝消息。 在操作1005中，UE通过使用在RRC连接拒绝消息中包括的重定向信息， 搜索用于重新连接的合适的小区，即，E-UTRAN。在操作1010中，UE针 对E-UTRAN执行RRC连接建立。在操作1015中，UE向MME递送TAU 请求消息。在操作1020中，如先前参照图9所述，UE确定是否满足两个条 件之一，并且确定是否指令UTRAN不执行包括用于重定向到E-UTRAN的 指令的RRC连接拒绝过程。第一条件是当TAU拒绝消息的IE EMM原因值 指示预定义的值，即‘跟踪区域不被允许’时。第二条件是当已经从RRC 连接释放消息中的频率优先级信息idleModeMobilityControlInfo中排除 E-UTRAN的当前频率信息时。在操作1020中，UE确定是否满足两个条件 中的至少一个，从而确定是否指令UTRAN不执行包括用于重定向到 E-UTRAN的指令的RRC连接拒绝过程。如果确定满足两个条件的至少一个， 则UE根据本公开的第二实施例执行随后的操作，即操作1025至1035。

如果两个条件都不满足，则不应用本公开的第二实施例。例如，该情况 可以对应于当UE没有接收到TAU拒绝消息时，当UE没能获得预定义的值 或新定义的IE EMM原因值、或者UE接收到不包括频率优先级信息的RRC 连接释放消息时。在操作1025中，UE搜索用于重新连接的UTRAN。在操 作1030中，UE用两种方式之一来设置RRC连接请求消息中的‘用于UTRAN 不执行包括用于重定向到E-UTRAN的指令的RRC连接拒绝过程的指令’。

在第一方式中，UE定义指示该指令的新指示符并且将新指示符合并到 RRC连接请求消息中。在第二方式中，UE将Pre-redirection info中的IE(即， ‘IE Support of E-UTRA FDD’和‘Support of E-UTRA TDD’两者)的值设 置为不可支持，或者不将Pre-redirection info包括在RRC连接请求消息中。 在操作1035中，UE向UTRAN发送包括新指示符或IE或者不包括IE的 RRC连接请求消息。

图11是示出根据本公开的第二实施例的UTRAN的操作的流程图。

参照图11，在操作1100中，UTRAN从UE接收RRC连接请求消息。 在操作1105中，UTRAN检查RRC连接请求消息中的信息。更具体地， UTRAN确定在RRC连接请求消息中是否包括新指示符或Pre-redirection  info、或者是否Pre-redirection info没有包括在RRC连接请求消息中。如果 Pre-redirection info被包括，则UTRAN进一步确定Pre-redirection info的IE (即，‘IE Support of E-UTRA FDD’和‘Support of E-UTRA TDD’两者) 是否为‘假’。

如果确定在RRC连接请求消息中包括新指示符或者被指示为‘假’的 ‘IE Supoort of E-UTRA FDD’和‘Support of E-UTRA TDD’或者在RRC 连接请求消息中不包括Pre-redirection info，则UTRAN识别出用于UE的包 括用于重定向到E-UTRAN的指令的RRC连接拒绝过程不可能，并且进行 到操作1110。在操作1110中，UTRAN确定对于UE不执行包括重定向到 E-UTRAN的RRC连接拒绝过程。UTRAN通过RRC连接释放过程终止UE 的RRC连接。

如果确定新指示符和Pre-redirection info都未被包括在RRC连接请求消 息中、或者Pre-redirection info中的‘IE Support of E-UTRA FDD’和‘Support  of E-UTRA TDD’两者都没有被指示为‘假’，则UTRAN执行根据UE的连 接请求需要的一般过程。

根据本公开的第二实施例的MME和E-UTRAN的操作的流程与图7和 8中所示的根据本公开的第一实施例的MME和E-UTRAN的流程相同，从 而将不再详细描述。

<第三实施例>

在本公开的第三实施例中，基于从MME接收的TAU拒绝消息的IE EMM原因值、或者从E-UTRAN接收的RRC连接释放消息的频率优先级信 息，UE忽略从UTRAN发送的指示重定向到E-UTRAN的RRC连接拒绝消 息，并且搜索另一合适的小区用于重新连接。

图12是示出根据本公开的第三实施例的操作的流程图。

参照图12，操作1210和1215与图2的操作210和215相同，从而将不 再详细描述。同样地，操作1230至1270对应参照图3进行的描述，从而将 不再详细描述。然而，在操作1255中，从MME 1225向UE 200发送的TAU 拒绝消息的IE EMM原因具有常规定义的值当中的值、或者根据本公开的第 三实施例新定义的值。例如，参照表3，当IE EMM原因具有常规定义的原 因的各种值当中的‘跟踪区域不被允许’时，执行在本公开的第三实施例中 提出的操作。替换地，除了常规定义的原因的各种值之外，可以定义新的的 EMM原因值。在操作1275中，其RRC连接请求已经被E-UTRAN拒绝的 UE 1200搜索作为用于重新连接的合适的小区的UTRAN。在此，为了方便 起见，描述的是所找到的UTRAN与已经拒绝RRC连接的UTRAN相同的 示例，但是所找到的UTRAN可以不与拒绝的UTRAN相同。在操作1285 中，UE 1200向UTRAN发送RRC连接请求消息。在操作1290中，UTRAN 1205向UE 1200递送包括重定向信息的RRC连接拒绝消息。这里，重定向 信息指示UE要被重定向到的系统。在操作1295中，如果确定UE 1200已 经尝试RRC连接到如重定向信息所指示的要向其执行重定向的E-UTRAN， 并且已经RRC连接失败(操作1230至1270)，则UE 1200忽略重定向指令。 在操作1299中，UE 1200搜索另一个合适的小区用于重新连接。

图13是示出根据本公开的第三实施例的UE的操作的流程图。

参照图13，在操作1300中，UE从UTRAN接收RRC连接拒绝消息。 在操作1305中，UE通过使用在RRC连接拒绝消息中包括的重定向信息， 搜索用于重新连接的合适的小区，即，E-UTRAN。在操作1310中，UE针 对E-UTRAN执行RRC连接建立。在操作1315中，UE向MME递送TAU 请求消息。在操作1320中，如先前所述，UE确定是否满足两个条件之一， 并且基于所述确定结果确定是否忽略关于在RRC连接拒绝消息中包括的重 定向信息的重定向指令。即，第一条件是当TAU拒绝消息的IE EMM原因 值指示预定义的值，即‘跟踪区域不被允许’时。第二条件是当已经从RRC 连接释放消息中的频率优先级信息idleModeMobilityControlInfo中排除 E-UTRAN的当前频率信息时。如果确定满足两个条件的至少一个，则UE 根据本公开的第三实施例执行操作1325至1345。如果两个条件都不满足， 则不应用本公开的第三实施例。

在操作1325中，UE 1200搜索用于重新连接的合适的小区，即，UTRAN。 在此，为了方便起见，描述的是所找到的UTRAN与已经拒绝RRC连接的 UTRAN相同的示例，但是所找到的UTRAN可以不与拒绝的UTRAN相同。

接着，在操作1330中，为了连接至UTRAN，UE向UTRAN发送RRC 连接请求消息。在操作1335中，UE从UTRAN接收包括重定向信息的RRC 连接拒绝消息。在操作1340中，UE确定重定向信息是否包括用于重定向到 UE已经尝试向其RRC连接的E-UTRAN的指令。如果确定重定向信息包括 用于重定向到E-UTRAN的指令，则UE在操作1345中忽略重定向指令并且 搜索另一个合适的小区用于重新连接。如果确定重定向信息不包括用于重定 向到E-UTRAN的指令，则UE执行用于重定向到E-UTRAN的一般过程。

在本公开的第三实施例中，如果用于重定向到E-UTRAN的指令被忽略， 则网络特定的操作不必要，从而将不详细描述与常规技术相同的UTRAN、 MME和E-UTRAN的操作。

<第四实施例>

本公开的第四实施例使用以下特征：从RRC连接释放消息的频率优先 级信息中排除已经拒绝UE的RRC连接的E-UTRAN的当前频率。即，将从 E-UTRAN接收到的RRC连接释放的频率优先级信息合并到发送到UTRAN 的RRC连接请求消息中。用此方式，从频率优先级信息中排除已经拒绝RRC 连接的E-UTRAN的当前频率，使得防止UTRAN指令将UE重定向到 E-UTRAN。

图14是示出根据本公开的第四实施例的操作的流程图。

参照图14，操作1410和1415与图2的操作210和215相同，从而将不 再详细描述。同样地，操作1430至1470对应参照图3进行的描述，从而将 不再详细描述。然后，在操作1475中，其RRC连接请求已经被包括E-UTRAN 1420的E-UTRAN拒绝的UE 1400搜索作为用于重新连接的合适的小区的 UTRAN。在此，为了方便起见，描述的是所找到的UTRAN与已经拒绝RRC 连接的UTRAN相同的示例，但是所找到的UTRAN可以不与拒绝的UTRAN 相同。

在操作1485中，UE将从E-UTRAN 1420接收到的RRC连接释放消息 的频率优先级信息IE idleModeMobilityControlInfo合并到RRC连接请求消息 中。频率优先级信息IE idleModeMobilityControlInfo不包括E-UTRAN的当 前频率。

在操作1490中，UE向UTRAN 1405发送包括频率优先级信息IE  idleModeMobilityControlInfo的RRC连接请求消息。

图15是示出根据本公开的第四实施例的UE的操作的流程图。

参照图15，在操作1500，UE从UTRAN接收RRC连接拒绝消息。在 操作1505中，UE通过使用在所接收的RRC连接拒绝消息中包括的重定向 信息，搜索用于重新连接的合适的小区，即，E-UTRAN。在操作1510，UE 针对E-UTRAN执行RRC连接建立。在操作1515，UE向MME递送TAU 请求消息。之后，如图14所示，假定MME进入EMM已注销状态，使得由 UE请求的RRC连接已经被E-UTRAN拒绝，并且UE已经接收到RRC连 接释放消息。然后，在操作1520，UE确定从E-UTRAN接收到的RRC连接 释放消息是否包括将E-UTRAN的当前频率从中排除的频率优先级信息IE  idleModeMobilityControlInfo。如果确定包括频率优先级信息IE  idleModeMobilityControlInfo，则UE在操作1525中搜索用于重新连接的合 适的小区，即，UTRAN。在操作1530中，UE将RRC连接释放消息的频率 优先级信息IE idleModeMobilityControlInfo合并到RRC连接请求消息中。在 操作1535中，UE向UTRAN发送包括频率优先级信息IE  idleModeMobilityControlInfo的RRC连接请求消息。

图16是示出根据本公开的第四实施例的UTRAN的操作的流程图。

参照图16，在操作1600中，UTRAN从UE接收RRC连接请求消息。 在操作1605中，UTRAN确定在RRC连接请求消息中是否包括频率优先级 信息IE idleModeMobilityControlInfo。如果确定包括频率优先级信息IE  ideleModeMobilityControlInfo，则UTRAN根据预定的条件确定对于UE是否 需要RRC连接请求拒绝。该条件可以包括UE是漫游UE的情况。该条件与 本公开中提出的方案不是密切相关，从而将不详细描述。

如果确定对于UE需要RRC连接请求拒绝，则UTRAN在操作1615产 生重定向信息，其中从UE的重定向目标中排除具有未被包括在频率优先级 信息idleModeMobilityControlInfo中的当前频率的E-UTRAN的E-UTRAN。 在操作1620中，UTRAN通过RRC连接拒绝消息向UE发送重定向信息。

根据本公开的第四实施例的MME和E-UTRAN的操作的流程与图7和 8的流程相同，从而将不详细描述。

<第五实施例>

本公开的第二实施例提出用于隐含地指令UTRAN不执行包括用于重定 向到E-UTRAN的指令的RRC连接拒绝过程的方法。更具体地，包括在常 规的Pre-redirection info中的IE(即，‘IE Support of E-UTRA FDD’和‘Support  of E-UTRA TDD’两者)被设置为‘假’，并且包括全部被设置为‘假’的 IE或不包括所述IE的RRC连接请求消息被发送到UTRAN的基站。本公开 的第二实施例已经提出考虑从E-UTRAN中的MME接收的EMM原因值， 或者当UE配置RRC连接请求消息的Pre-redirection info时使用RRC连接释 放消息的频率优先级信息IE idleModeMobilityControlInfo。本公开的第五实 施例提出UE考虑另一条件来配置RRC连接请求消息的Pre-redirection info 的方法。

更具体地，当UTRAN的RNC指令重定向而不识别UE是否可能在 E-UTRAN中被登记时，E-UTRAN和UTRAN之间的重定向的乒乓现象发生。 即，被重定向到E-UTRAN的UE未能在E-UTRAN中登记，因而返回 UTRAN。然而，UTRAN可能将UE重定向到E-UTRAN，使得发生乒乓现 象。通常，当UTRAN和E-UTRAN由不同的运营商管理时，网络可能不知 道UE是否可能在其中被登记。换言之，当UTRAN和E-UTRAN由不同的 运营商管理时，UTRAN和E-UTRAN具有不同的公共陆地移动网络 (PLMN)。换言之，如果UTRAN和E-UTRAN由相同的运营商管理，则 UTRAN和E-UTRAN可以由相同的PLMN指示，或者即使当UTRAN和 E-UTRAN由不同的PLMN指示时，可以使用等效的PLMN(ePLMN)列表 来指示另一方网络的PLMN。因而，如上所述，在UTRAN和E-UTRAN中 经历乒乓现象的UE对于登记不成功并且具有不包括在ePLMN列表中的 PLMN的E-UTRAN网络，将Pre-redirection info中的‘IE Support of E-UTRA  FDD’和‘Support of E-UTRA TDD’两者设置为‘假’，从而防止UE被重 定向到E-UTRAN网络。

图17是示出根据本公开的第五实施例的操作的流程图。

参照图17，操作1710和1715与图2的操作210和215相同，从而将不 再详细描述。操作1730和1770与常规的操作相同，从而将不详细描述。因 而，在说明书中，将仅描述根据本公开的第五实施例改变的部分。

如前所述，如果UTRAN和E-UTRAN由不同的运营商管理，则在重定 向中发生乒乓现象。该情况下，UE 1700不会在E-UTRAN网络中被登记。 因而，在操作1755中，UE 1700从MME 1725接收TAU拒绝消息。为此理 由，UE 1700从未在E-UTRAN中被登记。在操作1775中，其RRC连接请 求已经被E-UTRAN拒绝的UE 1700搜索作为用于重新连接的合适的小区的 UTRAN。在操作1785中，如果在具有包括在其ePLMN列表中的一个PLMN 的E-UTRAN中从未登记UE 1700，则UE 1700将Pre-redirection info的IE (即，‘IE Support of E-UTRA FDD’和‘Support of E-UTRA TDD’两者) 的值指示为不可支持的(‘假’)。UE 1700将全部IE合并到RRC连接拒绝消 息中或不合并IE。在操作1790中，UE 1700向UTRAN 1705发送包括全部 IE或不包括Pre-redirection info的RRC连接请求消息。

图18是示出根据本公开的第五实施例的UE的操作的流程图。

参照图18，在操作1800中，UE从UTRAN接收RRC连接拒绝消息。 在操作1805中，UE通过使用在RRC连接拒绝消息中包括的重定向信息， 搜索用于重新连接的合适的小区，即，E-UTRAN。在操作1810，UE针对 E-UTRAN执行RRC连接建立。在操作1815中，UE向MME递送TAU请 求消息。在操作1820中，UE确定是否从MME接收到TAU拒绝消息。如 果UE没有接收到TAU拒绝消息，则UE认为自身在E-UTRAN网络中被成 功登记，并且终止图18的操作。然而，如果接收到TAU拒绝消息，则UE 在操作1825中搜索用于重新连接的UTRAN。在操作1830中，UE在RRC 连接请求消息中设置‘用于UTRAN不执行包括用于重定向到E-UTRAN的 指令的RRC连接拒绝过程的指令’。更具体地，如果UE从未在具有包括在 其ePLMN列表中的一个PLMN的E-UTRAN网络中被登记，则UE将 Pre-redirection info的IE(即，‘IE Suppport of E-UTRA FDD’和‘Support of  E-UTRA TDD’)设置为指示不可支持，或者不将Pre-redirection info合并到 RRC连接请求消息中。在操作1835中，UE向UTRAN发送包括IE或不包 括IE的RRC连接请求消息。

<第六实施例>

目前，UE的漫游协议被制定为对于数据服务可能/不可能，或者对于语 音服务可能/不可能。因而，在归属网络中，已经使用数据服务的UE确定在 漫游网络中是否为数据进行漫游。假定LTE为新的系统，则可以制定在归属 网络中可用但是在漫游网络中不可用的漫游协议。

图19是用于描述本公开的第六实施例中要解决的问题的图。

参照图19，在具有E-UTRAN 1950和UTRAN 1955两者的归属PLMN 中，能够支持E-UTRAN和GSM-EDGE无线接入网络(GERAN)/UTRAN 两者的UE 1930可以使用两种无线接入技术，使得UE 1930被允许在控制实 体MME 1945中登记以使用E-UTRAN 1950并且在控制实体SGSN 1940中 登记以使用UTRAN 1955。然而，当UE 1930通过改变PLMN移动到拜访 PLMN从而进入漫游状态时，在归属网络和拜访网络之间对一些RAT制定 漫游协议，使得在归属网络中使用的无线接入技术的一部分可能不可用。图 19中，仅对于3G制定漫游协议，使得UE 1930可以在拜访PLMN中没有 任何问题地使用UTRAN 1925，但是当UE 1930使用E-UTRAN 1920时，包 括TAU的网络登记请求或附接请求可以被作为拜访PLMN中的控制实体的 MME 1910拒绝。

被拒绝的UE 1930可以移动到漫游网络中的UTRAN 1925以在UTRAN 的控制实体SGSN 1915中被登记并使用网络，并且可以执行切换/重定向/小 区(重新)选择/快速重定向到E-UTRAN。这是因为已经进行优先级调整， 使得UE优选地使用归属PLMN中的E-UTRAN，从而UE优选地选择处于 空闲状态的E-UTRAN，并且因为没有关于某种RAT约束的信息指示UE不 能使用漫游网络的UTRAN基站1915中的E-UTRAN。

如此，如果UE执行切换/重定向/小区(重新)选择到不允许漫游的RAT， 则RAT中的网络使用登记被拒绝，并且UE移动到允许漫游的RAT并且再 次执行切换/重定向/小区(重新)选择到不允许漫游的RAT，并且网络使用 登记被再次拒绝。这样的现象可以被本公开防止。

本公开的第六实施例提出用于使用PLMN特定的允许的RAT列表的方 法以及用于向UE递送MME中关于不允许的RAT的RAT处理信息的方法。

图20是用于描述本公开的第六实施例中使用为PLMN特定的允许的 RAT设置的信息的过程的图。

参照图20，在操作2000中，归属PLMN使用OMA-DM向UE发送根 据漫游协议在漫游网络中允许的RAT的列表。该列表包括具有漫游协议的 PLMN的PLMN id和在PLMN中允许的RAT的信息。PLPLMN id和信息的 示例可以用如下的列表的形式提供。

-PLMN-A:允许的RAT(例如:UMTS,LTE..等等),

-PLMN-B:允许的RAT,

……………….

在操作2010中，UE根据传播状态确定是否需要小区选择/重新选择。 在操作2030中，基于所述确定，当UE不执行小区选择/重新选择并且当前 网络使用被登记时，UE周期性地操作定时器T用于寻找HPLMN、EHPLMN 和更高优先级PLMN。如果T定时器尚未期满，则UE终止其操作。如果T 定时器已经期满，则UE开启因为在当前登记的网络的PLMN中不被允许而 被关闭的RAT，并且在操作2050中执行小区选择/重新选择和PLMN选择。 在操作2060中，UE确定作为小区选择/重新选择和PLMN选择的结果，是 否选择了不同于当前登记的PLMN的HPLMN、EHPLMN和更高优先级 PLMN。如果所选择的HPLMN、EHPLMN和更高优先级PLMN与当前登记 的PLMN没有不同，则UE返回到操作2010。如果选择了不同的HPLMN、 EHPLMN和更高优先级PLMN，则UE在操作2070中检查在漫游网络中允 许的RAT的列表以检查在新选择的PLMN中允许的RAT。如果在新选择的 PLMN中存在包括当前驻扎的(camping)RAT的不允许的RAT，则将该信 息合并到因为不被允许而被关闭的RAT的列表中，并且列表中包括的RAT 全部被关闭。如果基于关闭结果小区选择是必要的，则UE再次执行操作2010 及其随后的操作。如果在操作2010之后在操作2020中改变PLMN，则UE 再次执行操作2060及其随后的操作。

图21是用于描述用于向UE递送关于MME/SGSN中不允许的RAT的 RAT处理信息的方法的梯图(ladder diagram)。

为了解决图21中的问题，当发送对于在漫游网络中的网络中的UE登 记的附接请求或TAU请求的响应时，通过响应向UE递送指示当前驻扎的 RAT不可用从而需要关闭RAT的信息。

在操作2101中，在漫游网络中，UE 2100发送附接/TAU请求给网络控 制实体MME 2130以登记网络使用。在操作2103中，已经接收到来自UE  2100的请求的MME 2130向HSS 2140发送位置更新请求以登记UE的当前 位置并且获得预订信息。在操作2105中，HSS 2140检查MME 2130的PLMN 以及UE 2100的预订，并且通过将要提供给MME 2130的预订信息递送UE 相对于RAT的接入权限信息。代替执行操作2103、2104和2105，MME 2130 可以通过使用在UE的上下文信息中包括的IMSI来获得UE的归属PLMN， 从而基于在MME 2130中设置的关于对于UE是否允许当前在MME 2130的 PLMN和UE的归属PLMN之间使用的RAT(如果在MME 2130中进行检 查，则为E-UTRAN)的使用的信息，来确定对于UE是否允许当前由UE 使用的无线接入技术。

在操作2108中，基于从HSS 2140提供的关于无线接入技术对UE可用 的信息、或者在UE的IMSI中包括的MME和归属PLMN的设置信息，MME 2130确定当前在UE中使用的无线接入技术是否被允许。如果无线接入技术 被允许，则MME 2130接受操作2101中从UE 2100发送的附接/TAU请求。 如果无线接入技术不被允许，则MME 2130拒绝从UE 2100发送的附接/TAU 请求，并且在操作2108中递送指示当前使用的无线接入技术的使用对于UE 2100不被允许的信息以及附接/TAU拒绝消息。

在操作2109中，通过消息已经接收到指示无线接入技术的使用不被允 许的信息的UE 2100关闭当前使用的无线接入技术，并且在PLMN特定的 不可用RAT列表或RAT特定的不可用PLMN列表中存储关于已经尝试对其 的登记的RAT和PLMN的信息。从PLMN和RAT选择中排除其信息被存 储的PLMN的RAT。在操作2110中，UE 2100尝试关于没有被关闭的RAT 的网络使用登记。即，UE 2100向SGSN 2120发送附接/路由区域更新(RAU) 请求。

虽然未显示，但是UE可以在以下情况中开启被关闭的RAT：

-当发生PLMN改变时

-当UE的USIM被移除然后插入时

-当UE被断电然后加电时

-当用于搜索HPLMN、HEPLMN和高优先级PLMN的定时器期满时

作为已经在操作2108中接收到来自MME 2130的附接/TAU拒绝消息的 UE的操作的另一示例，已经在操作2108中通过附接/TAU拒绝消息接收到 指示无线接入技术的使用不被允许的信息的UE 2100将当UE 2100向MME 2130发送跟踪区域/服务请求时选择的MME 2130的PLMN信息添加到当无 线接入技术被使用时禁止对其接入的PLMN的列表。对于当无线接入技术被 使用时禁止对其接入的PLMN，不发送附接/TAU/服务请求。例如，在 E-UTRAN的情况下，将与指示无线接入技术的使用不被允许的信息的传输 对应的信息存储在用于E-UTRAN的禁止PLMN列表中，并且之后，当 E-UTRAN被使用时，当使用网络时不选择在用于E-UTRAN的禁止PLMN 列表中包括的PLMN，并且UE不向那些PLMN发送请求。在更新当使用无 线接入技术时禁止对其接入的PLMN的列表之后，UE可以选择能够使用无 线电技术的另一PLMN或者选择所拒绝的PLMN的另一无线电技术。例如， 如果通过TAU拒绝消息接收到指示由于PLMN A而不允许E-UTRAN的使 用的信息，则UE可以通过向作为PLMN A的另一RAT的UTRAN/GERAN 发送附接请求的操作、或者通过向不同于PLMN A的PLMN B的E-UTRAN 发送附接请求的操作来尝试登记。可以基于在UE中设置的PLMN和RAT 的优先级列表来确定要执行哪一个操作。在以下情况中重置并初始化当无线 电技术被使用时禁止对其接入的PLMN的列表：

-当UE的USIM被移除然后插入时

-当UE被断电然后加电时

图22是应用本公开的实施例的UE的框图。

参照图22，UE可以包括收发器2200、复用器和解复用器2205、上层 设备2210、控制消息处理器2215、以及控制器2220。

UE向和从上层设备2210发送和接收数据，并且通过控制消息处理器 2215发送和接收控制消息。当向基站发送控制消息或数据时，UE在控制器 2220的控制下在通过复用器和解复用器2205复用数据之后通过收发器2200 发送数据。UE在控制器2220的控制下通过收发器2200接收物理信号，通 过复用器和解复用器2205解复用所接收的信号，并且基于消息信息将信号 递送给上层设备2210或控制消息处理器2215。

特别地，控制消息处理器2215根据本公开的第一至第四实施例设置用 于防止UE不必要地重新连接至对其的RRC连接请求已经被拒绝的系统的 指示符，并且通过相应的消息向基站发送指示符。在各自的实施例中已经详 细描述了指示符，因而此时将不再描述。

图23是根据本公开的实施例的基站的框图。这里，基站可以作为关于 图1至22提及的UTRAN或E-UTRAN工作。

参照图23，基站可以包括收发器2305、控制器2310、调度器2315、复 用器和解复用器2320、控制消息处理器2335、以及上层处理器2325和2030。

收发器2305通过前向载波发送数据和预定控制信号，并且通过后向载 波接收数据和预定控制信号。如果多个载波被设置，则收发器2305使用多 个载波来执行数据发送和接收以及控制信号发送和接收。

复用器和解复用器2320复用在上层处理器2325和2330、或在控制消息 处理器2335中产生的数据，或者解复用从收发器2305接收的数据，以递送 复用或解复用的数据到上层处理器2325和2330、控制消息处理器2335、或 控制器2310。控制消息处理器2335处理从UE发送的控制消息以执行必要 的操作，或者产生将要发送到UE的控制消息并且向下层递送所产生的控制 消息。

上层处理器2325和2330的每一个可以针对每个UE或每个服务来配置， 并且处理在诸如文件传输协议(FTP)或互联网协议语音(VoIP)的用户服 务中产生的数据以将数据递送给复用器和解复用器2320，或者处理从复用器 或解复用器2320递送的数据以将经处理的数据递送给上层服务应用。

控制器2310确定UE何时发送数据，从而控制收发器2305。

考虑UE的缓冲器状态、信道状态、和UE的活跃时间，调度器2315在 合适的时间点向UE分配传输资源，并且控制收发器处理从UE发送的信号 或者向UE发送信号。

特别地，控制消息处理器2335根据本公开的第一至第四实施例接收包 括用于防止UE不必要地重新连接至对其的RRC连接请求已经被拒绝的系 统的指示符的消息，并且基于指示符的指令停止UE的不必要的重新连接。 同样地，在各自的实施例中已经详细描述了指示符，因而此时将不再描述。

虽然已经参照其示范性实施例示出和描述本公开，但是这里可以进行形 式和细节上的各种改变而不脱离由所附权利要求限定的本公开的精神和范 围。因此，本公开的范围将由所附权利要求及其等价物限定。