CN102934487A - 家庭小区中紧急服务的选择性支持和建立 - Google Patents

Abstract

一种UE，包括一个或多个处理器，被配置为响应于当UE在毫微微小区中或当UE在毫微微小区中驻留时进行紧急呼叫，使UE重选到宏小区。

Description

家庭小区中紧急服务的选择性支持和建立

背景技术

在此使用的术语“用户设备”(“UE”)、“移动台”(“MS”)和“用户代理”(“UA”)在一些情况下可以指移动设备，例如移动电话、个人数字助理、手持或膝上型计算机以及具有通信能力的类似设备。同样地，在此可以将术语“MS”、“UE”、“UA”、“用户设备”和“用户节点”进行同义使用。UE可以包括允许UE与其他设备通信的组件，以及还可以包括一个或多个相关联的可拆卸式存储模块，例如但不限于通用集成电路卡(UICC)，UICC包括订户识别模块(SIM)应用、通用订户识别模块(USIM)应用或者可拆卸式用户识别模块(R-UIM)应用。备选地，这种UE可以由设备在自身没有这种模块的情况下组成。在其他情况下，术语“UE”可以指具有类似能力但是不便携的设备，例如，桌上型计算机、机顶盒或者网络设备。术语“UE”还可以指代可以端接用户的通信会话的任何硬件或软件组件。

随着电信技术演进，已经引入了可提供之前不可能的业务的更高级的网络接入设备。该网络接入设备可以包括作为传统无线电信***中的等同设备的改进的***和设备。这种高级的或者下一代的设备可以包括在正在演进的无线通信标准(例如长期演进(LTE)和高级LTE(LTE-A))中。例如，LTE或LTE-A***和设备可以包括演进的通用陆地无线接入网(E-UTRAN)，E-UTRAN可以包括E-UTRAN节点B(或eNB)、家庭E-UTRAN节点B(HeNB)、中继节点或者类似的组件，而不是传统的基站。可以将这些组件称为接入节点。例如在UTRAN、WLAN或WiMAX中可被称为接入节点的其他组件可以包括节点B(NB)、家庭节点B(HNB)或无线接入点。术语“(e)NB”可以预期是NB和eNB。

(e)NB支持紧急呼叫。H(e)NB也可以支持针对CSG和非CSG成员的紧急呼叫。相对于(e)NB的容量，H(e)NB可以向数目非常有限的用户提供紧急服务。此外，在经由H(e)NB的其他CSG或非CSG成员的紧急呼叫期间，H(e)NB与IP回程的连接可能有意或无意地丢失。此外，希望在用户体验上没有差异地支持经由H(e)NB或经由(e)NB的紧急服务。

附图说明

为了更完整地理解本公开，现在结合附图和详细描述来参考以下简要描述，其中相似的附图标记表示相似的部分。

图1是示出根据本公开的实施例的HNB接入网络的逻辑结构的框图。

图2是示出根据本公开的实施例的具有专用网关的H(e)NB接入网络的逻辑结构的框图。

图3是示出根据本公开的实施例的没有专用网关的H(e)NB接入网络的逻辑结构的框图。

图4是示出根据本公开的实施例的具有针对C平面的网关的H(e)NB接入网络的逻辑结构的框图。

图5是根据本公开的实施例的非漫游架构的框图。

图6是根据本公开的实施例，在UE中发起紧急呼叫的过程的流程图。

图7是根据本公开的实施例，准备重选到宏小区的过程的流程图。

图8是根据本公开的实施例，指示对紧急呼叫的支持的过程的流程图。

图9是根据本公开的实施例，指示紧急呼叫支持的过程的流程图。

图10是根据本公开的实施例，确定是否进行紧急呼叫的过程的流程图。

图11示出了适于实现本公开的若干实施例的处理器和相关组件。

具体实施方式

一开始应该知道的是，虽然以下提供了本公开的一个或更多实施例的示意性实现，但可用任意数目的技术来实现所公开的***和/或方法，而不管其是当前已知的还是已存在的。本公开不应以任何方式受限于以下示出的示意性实现、附图和技术，包括在此示意和描述的示例性设计和实现，但在所附权利要求的范围以及其等同的全部范围内，可以进行修改。

在整个说明书、权利要求书和图中使用的以下缩写具有以下的定义。以下标识的一些术语由第三代伙伴计划(3GPP)技术规范所阐述的标准来定义，或者遵循3GPP技术规范所阐述的标准。在3GPP技术规范使用的术语使用了与以下所呈现的缩写和用语相同的缩写和用语的情况下，3GPP技术规范描述对应术语的定义和功能。然而，本文中描述的实施例根据本文中描述的创造性的技术来使用这些组件和/或功能。3GPP规范中描述了以下术语中的很多，但不是全部。

“AS”被定义为“接入层”。

“APN”被定义为“接入点名称”。

“BSS”被定义为“基站子***”。

“CC”被定义为“呼叫控制”。

“CGI”被定义为“小区全球标识”。

“CM”被定义为“连接管理”。

“CN”被定义为“核心网”。

“CS”被定义为“电路交换”。

“CSG”被定义为“闭合订户组”。

“CSR”被定义为“电路交换资源”。

“DM”被定义为“设备管理”。

“DSL”被定义为“数字订户线路”。

“ECCN”被定义为“显式小区拥塞通知”。

“ECRI”被定义为“紧急呼叫要求指示符”。

“ECSI”被定义为“紧急呼叫支持指示符”。

“EDGE”被定义为“针对GSM演进的增强型数据速率”。

“EF”被定义为“基本文件”。

“EHPLMN”被定义为“等价家庭公共陆地移动网”。

“EMM”被定义为“EPS移动性管理”。

“eNB”被定义为“E-UTRAN节点B”。

“EPC”被定义为“演进的分组核心”。

“EPS”被定义为“演进的分组***”。

“ESM”被定义为“EPS会话管理”。

“E-UTRA”被定义为“演进的通用陆地无线接入”。

“E-UTRAN”被定义为“E-UTRA网络”。

“GA”被定义为“通用接入”。

“GERAN”被定义为“GSM EDGE无线接入网”。

“GMM”被定义为“GPRS移动性管理”。

“GPRS”被定义为“通用分组无线服务”。

“GSM”被定义为“全球移动通信***”。

“HNB”被定义为“家庭节点B”。

“HNBAP”被定义为“家庭节点B应用协议”。

“HNB GW”被定义为“HNB网关”。

“HeNB”被定义为“家庭节点B”。

“H(e)NB”被定义为包括“家庭节点B”或“HNB”中的任一者或二者的术语。

“HLR”被定义为“归属位置寄存器”。

“HOSF”被定义为“切换选择功能”。

“HPLMN”被定义为“家庭公共陆地移动网”。

“HLR”被定义为“归属位置寄存器”。

“ID”被定义为“标识符”或“标识”。

“IE”被定义为“信息单元”。

“IMS”被定义为“互联网协议多媒体子***”。

“IMSI”被定义为“互联网移动订户标识”。

“IP”被定义为“互联网协议”。

“LA”被定义为“位置区”。

“LAI”被定义为“位置区标识”。

“LAU”被定义为“位置区更新”。

“LTE”被定义为“长期演进”。

“MIB”被定义为“主信息块”。

“MCC”被定义为“移动国家代码”。

“MM”被定义为“移动性管理”。

“MME”被定义为“移动性管理实体”。

“MNC”被定义为“移动网络代码”。

“MO”被定义为“管理对象”。

“MSC”被定义为“移动交换中心”。

“NAS”被定义为“非接入层”。

“NNSF”被定义为“NAS节点选择功能”。

“OMA”被定义为“开放移动联盟”。

“OTA”被定义为“空中”。

“P-GW”被定义为“PDN网关”。

“PCI”被定义为“物理小区标识”。

“PCRF”被定义为“策略计费规则功能”。

“PDN”被定义为“分组数据网络”。

“PDP”被定义为“分组数据协议”。

“PLMN”被定义为“公共陆地移动网”。

“PS”被定义为“分组交换”。

“PSAP”被定义为“公共安全响应点”。

“PSC”被定义为“主扰码”。

“RA”被定义为“路由区”。

“RAB”被定义为“无线接入承载”。

“RAT”被定义为“无线接入技术”。

“RAU”被定义为“路由区更新”。

“RNC”被定义为“无线网络控制器”。

“RPLMN”被定义为“已注册的公共陆地移动网”。

“RRC”被定义为“无线资源控制”。

“RSRP”被定义为“参考信号接收功率”。

“RSRQ”被定义为“参考信号接收质量”。

“S-GW”被定义为“服务网关”。

“SeGW”被定义为“安全网关”。

“SI”被定义为“***信息”。

“SIB”被定义为“***信息块”。

“SGSN”被定义为“服务GPRS支持节点”。

“SRVCC”被定义为“单无线语音呼叫连续性”。

“TA”被定义为“跟踪区”。

“TAU”被定义为“跟踪区更新”。

“TS”被定义为“技术规范”或“多个技术规范”。

“UE”被定义为“用户设备”。

“USIM”被定义为“通用订户标识模块”。

“UTRAN”被定义为“通用陆地无线接入网络”。

“VANC”被定义为“VoLGA接入网控制器”。

“VLR”被定义为“访问位置寄存器”。

“VoIMS”被定义为“基于IMS的语音”。

“VoIP”被定义为“基于互联网协议的语音”。

“VoLGA”被定义为“经由通用接入的基于LTE的语音”。

“WLAN”被定义为“无线局域网”。

本文中使用的以下术语具有以下的定义。

CSG列表

“允许CSG列表”被定义为UE中存储的列表，该列表包含订户所属于的CSG的CSG标识和相关的PLMN标识。在本文的描述的上下文中，该列表可以来自于AS的视角，并且可以包括以下列表的一个或多个组合：NAS UE的允许CSG列表和运营商CSG列表，以及潜在地针对NAS定义的其他类型的CSG列表。

“不允许CSG”被定义为不在UE的允许CSG列表中的CSG。

UE附着

如本文中使用的，可以参考至小区或多个小区的UE附着。可以在非限定性的示例中使用术语“附着”来指示UE在空闲模式下执行NAS附着过程的场景，或者在另一非限制性示例中，指示在小区上建立已连接模式RRC连接的场景。选择小区来作为服务小区的其他含义也在“UE附着”的定义的范围之内，例如，将会根据要求或希望来建立任何连接的小区，和/或监视下行链路寻呼信道的小区，包括与“驻留”在小区上相关联的任何过程。术语“附着”可以包括3GPP含义“NAS附着”，可以包括IMS附着，以及还可以包括驻留在小区上、选择小区和附着、驻留或连接到小区的其他形式。

HNB、H(e)NB和毫微微小区

术语“H(e)NB”可以预期是HNB和HeNB(家庭节点B)。术语“HNB”可以指代在UTRAN无线空中接口上使用宽带IP回程将3GPP UE连接到移动运营商的网络的内部(on-premises)客户设备。术语“H(e)NB”可以指代在E-UTRAN无线空中接口上使用宽带IP回程将3GPP UE连接到移动运营商的网络的内部客户设备。因此，在一些实施例中，HeNB可以使用E-UTRAN无线接入技术，而HNB可以使用UTRAN无线接入技术。具体的H(e)NB和HNB可以具有不同的接入模式。可以使用术语HeNB和HNB来指示由HeNB或HNB产生的具体小区可以是CSG小区或者混合小区。除非以其他方式指定，在本文中可交换使用术语HeNB和HNB，以及由术语“H(e)NB”来指代这两个术语。

也可以将术语HNB小区，HeNB小区和CSG小区称为“毫微微小区”。从而，本文中使用的术语“毫微微小区”可以预期是HNB小区、HeNB小区或CSG小区中的任何小区，并且可以包括毫微微小区。可以在3GPP规范之外使用术语“毫微微小区”来指具有非常小的覆盖的任何小区，虽然通常不是必然安装在私有的或公司房屋中。术语“毫微微小区运营商”可以指代通过H(e)NB主机方提供服务的PLMN运营商，一般性地指代主机方(为用户操作H(e)NB付款的第三方)，指代H(e)NB所有者，或指代其组合。

宏小区

相比而言，虽然在3GPP规范中不是必然有意义，术语“宏小区”可被使用来指除了毫微微小区之外的小区。贯穿本文使用的“宏小区”可以是已知支持紧急服务的小区。

下面提供宏小区和毫微微小区之间的差异的一些示例。首先，H(e)NB的小区控制器可以由订户拥有，而不是由PLMN运营商拥有，并且可以位于订户的房屋上。第二，可以由实质上与用于宏小区的连接相比较不可靠的连接来实现从家庭小区控制器到PLMN核心网的连接。第三，这种连接可以经由与PLMN运营商的网络不是一体的订户的DSL连接或IP连接。第四，可以将对毫微微小区的接入限制在用户或设备的子集；要注意到，订户可以是私人、公司和教育机构或者其他一些实体。此外，毫微微小区可以指代针对UMTS(UTRAN)和LTE(E-UTRAN)引入的用于改进室内小区覆盖和微小区覆盖的概念，以及到订户针对H(e)NB选择的位置的泄漏线缆回程。

H(e)NB中的接入模式

可以存在用于H(e)NB的多个接入模式。在一个实施例中，在H(e)NB中存在三个接入模式：闭合接入模式、混合接入模式和开放接入模式。在闭合接入模式下，H(e)NB可以仅向其相关联的CSG成员提供服务。在混合接入模式下，H(e)NB可以仅向其相关联的CSG成员和非CSG成员提供服务。在开放模式下，H(e)NB可以作为正常的节点B或e节点B操作。下面呈现混合接入模式和开放接入模式的使用情况的非限制性示例。

以下是混合接入模式的示例。为了改善商场中的覆盖，可以部署H(e)NB。网络运营商可能已经向商场所有者提供了特价，其中，当经由这些H(e)NB接入服务时，商场的雇员将接收到优惠的费率和优先接入。商场所有者可以允许公众使用H(e)NB来接入正常的网络运营商服务。与涉及经由一个或多个H(e)NB提供对运营商网络的接入的运营商有合同关系的H(e)NB主机方(例如，家庭中的“主导”用户或企业中的公司IT管理者)可以不需要管理公共接入，并且公众可以不需要采取特殊的动作来在H(e)NB上接收服务。

以下是开放接入模式的示例。开放接入模式可以允许所有用户使用H(e)NB。开放接入模式可以增强运营商的公共网络的覆盖或容量。例如，开放接入模式H(e)NB可以存在于在火车站、机场、体育场和其他公共位置处。

闭合订户组(CSG)

H(e)NB功能的一方面可以是限制具体用户接入其他H(e)NB功能的能力。例如，可以将接入限制为在其点部署了H(e)NB的公司的雇员，具体的咖啡连锁店的客户，或者在将H(e)NB部署在私人家中的情况下，限制为具体的个人。

为了实现该功能，可以部署CSG。可以使用CSG指示符来通过***信息中广播的1个比特对所产生的小区是CSG小区进行指示。此外，CSG小区还可以在***信息中广播该CSG小区所属于的CSG ID和PLMN ID。然而，小区可以不指示CSG ID，例如在宏小区或使用开放接入模式的情况下。多个小区可以共享CSG ID。可以将UE预订到多个CSG。这种预订自然可以是临时的。针对非限制性示例，咖啡店可以允许订户接入商店的CSG1个小时。

现在可以将关注转向本文中描述的实施例的非限制性概述。具体地，本文中描述的实施例提供了技术，该技术用于解决与在毫微微小区中或靠近毫微微小区进行紧急呼叫有关的问题以及用于解决其他问题。在一个实施例中，当移动设备尝试在驻留在毫微微小区上或者在毫微微小区的活跃连接中时建立紧急呼叫的情况下，可以通过设备首先重选到覆盖区内的宏覆盖并在然后在该宏小区上建立呼叫来确保紧急呼叫的可靠性。在第二实施例中，在UE尝试毫微微小区上的紧急呼叫的情况下，UE准备当该呼叫在毫微微小区中掉话的情况下重选到宏网络。在第三实施例中，可以提供紧急服务(例如，为了进行紧急呼叫而建立连接的可能性)，然而向UE提供对以下情况的指示：不保证这些服务的可靠性，或者与在由另一小区或网络提供时的等效服务相比，这些服务实质上较不可靠。在第四实施例中，在毫微微小区拥塞的情况下，UE可以能够在不需要网络进行切换的情况下重选到宏小区，以及UE可以知道现有的小区发生拥塞。下面进一步描述这些以及其他的实施例。

图1是示出根据本公开的实施例的HNB接入网络的逻辑结构的框图。具体地，图1描述了HNB CSG小区的架构。在描述该架构之前，首先关注HNB和H(e)NBs、CSG以及H(e)NB中的接入节点的概念。

返回图1，架构100示出了HNB接入网的示例性架构。HNB 102可以使用Iuh接口104提供RAN连接。HNB 102可以支持NB和大部分RNC功能以及Iuh接口104上的HNB验证、HNB GW 106探索、HNB注册和UE 108a，108b注册。HNB 102可以保证到HNB GW 106以及来自于HNB GW 106的通信的安全。

HNB GW 106可以担当RNC，该RNC将其自身作为HNB连接的集线器服务向CN呈现。HNB GW 106可以提供用于控制平面的集线器功能，以及可以提供用于用户平面的集线器功能。HNB GW 106可以支持NNSF。

在图1中示出的架构100中，各种参考点被示出。Uu接口110可以是UE(108a和108b)与HNB 102之间的标准Uu接口。Iuh接口104可以是HNB 102和HNB GW 106之间的接口。对于控制平面，Iuh接口104可以使用HNBAP协议来支持HNB注册、UE注册和错误处理功能。对于用户平面，Iuh接口104可以支持用户平面传输承载处理。

Iu-CS112接口可以是HNB GW 106和CS核心网络之间的标准接口。Iu-PS接口114可以是HNB GW 106和PS核心网络之间的标准接口。D接口116可以是MC/VLR 118和HLR/HSS 120之间的标准D接口。Gr接口122可以是SGSN 124和HLR/HSS 120之间的标准Gr接口。C1接口126可以是CSG列表Srv 128和具有CSG能力的UE的108a之间的可选接口。OTA通信可以被用于更新具有版本8USIM的UE上的允许CSG列表。OMA DM可以被用于更新具有版本8之前的USIM的UE上的允许CSG列表。

图1中示出的架构100可以具有多个机制中的一个或多个。所有支持CSG功能的Rel-8UE和后Rel-8UE可以或应当包含允许的CSG标识的列表。在UE不属于任何CSG或者没有被预订到任何CSG的情况下，该列表为空。

在一个实施例中，H(e)NB中的每一个小区可以属于一个CSG的最大化(maximum)(即与其关联，以及因此允许访问其订户)。

H(e)NB的小区属于不同CSG可以或应当是可能的，并且因此具有不同的CSG ID。

允许CSG列表可以或应当作为CSG订户预订数据的一部分向MME提供。可以在UE中根据附着、TAU、服务请求和去附着过程的结果或通过例如OMADM过程的应用级机制来更新允许CSG列表。

在一个实施例中，针对在附着、组合附着、去附着、服务请求和TAU过程中通过毫微微小区接入的UE，MME可以或应当执行访问控制。如果UE不被允许访问毫微微小区，则可以或应当由网络向UE通知拒绝原因。

在一个实施例中，当由用户手动选择未被包括在UE的允许CSG列表中的CSG ID时，可以或应当由UE立即触发经由所选择的毫微微小区的TAU过程。该TAU过程可以允许MME执行CSG访问控制。

在一个实施例中，TAI列表同样可以应用于毫微微小区。TAI列表可以包括涉及毫微微小区的TAI以及涉及非毫微微小区的TAI。UE可以不区分在TAI列表中的这些TAI。对于H(e)NB GW部署的情况，H(e)NBGW中支持的TAI可以是在H(e)NB GW下的毫微微小区支持的TAI的集合。

图2、图3和图4描述了相对于图1中示出的毫微微小区的HNB架构100的H(e)NB毫微微小区架构变化。特别地，图2是示出了根据本发明一个实施例，具有专用网关的HNB接入网络的逻辑架构的框图。图3是示出了根据本发明的一个实施例，没有专用网关的HNB接入网络的逻辑架构的框图。图4是示出了根据本发明的一个实施例，具有针对C平面的网关的HNB接入网络的逻辑架构的框图。在图1到图4中示出的实施例中，对应于彼此的附图标记对应于相似的设备或部件，以及可以类似地操作。

在图2到图4中，H(e)NB 200支持的功能可以或应当与eNB支持的功能相同，可能的例外是NNSF。在H(e)NB 200和EPC之间运行的过程可以或应当与在eNB和EPC之间运行的过程相同。取决于实现，UE(108a或108b)可以具有UMTS能力或E-UTRAN能力，或两者都具有。取决于实现，UE可以具有CSG能力或非CSG能力。

H(e)NB GW 204可以作为集线器服务于C平面，特别是S1-MME接口206。H(e)NB GW 204可以可选地端接到H(e)NB 200以及到S-GW202的用户平面，并且可以提供用于在H(e)NB 200和S-GW 202之间中继用户平面数据的中继功能。H(e)NB GW204可以支持NNSF。

现在描述参考点。LTE-Uu接口208可以是UE 108和H(e)NB 200之间的标准LTE-Uu接口。如果不使用H(e)NB GW 204，则可以在H(e)NB200和MME 210之间定义S1-MME 206接口。如果H(e)NB GW 204存在，则可以或应当使用去往H(e)NB 200和MME 210的标准S1-MME接口206。

可以在H(e)NB 200、H(e)NB GW 204和SeGW之间定义S1-U接口212数据平面。来自于H(e)NB 200的S1-U接口212可以在H(e)NB GW204处终止，或者可以使用H(e)NB和S-GW 202之间的直接逻辑U平面连接。

S11接口214可以是MME 210和S-GW 202之间的标准接口。S6a216接口可以是MME 210和HSS 120之间的标准接口。S1接口218可以是H(e)NB 200和H(e)NB GW 204之间的标准接口。

传统设备

UMTS毫微微小区可以不在非毫微微小区的相相邻小区列表中列出。因此，传统的UMTS设备(可以是版本7或更早的设备)可以不搜索这样的小区。如果传统设备尝试访问毫微微小区，注册尝试可被拒绝。

E-UTRAN首先在版本8中规定。基于该原因，所有具有E-UTRAN能力的设备可以是“知道CSG的”设备，即使它们没有CSG预订。

来自或去往毫微微小区的空闲模式移动

一般而言，与非毫微微小区相比，网络运营商更希望具有对毫微微小区的预订的设备驻留该小区。然而，设备对搜索毫微微小区的确定可以是实现所特定的，并且可以手动触发。设备可以存储与其能够访问的小区的位置相对应的一些信息。这些信息的示例包括GPS坐标或检测到的宏小区的列表。该信息可被用于加速后续的网络访问。可以将存储这种类型的信息称为采指纹。

对驻留哪个小区的决定也可以取决于针对UTRAN和E-UTRAN定义的小区选择和重选规则。在版本8中，仅当小区是使用其特定载频的所有小区中最好的小区时，UE才可以重选到该小区。可以将最好的小区考虑为具有最强信号强度的小区。毫微微小区不需要是针对特定频率的最好小区。当UE驻留在合适的毫微微小区上时，UE可以或应当总是将当前频率视为最高优先级频率。离开毫微微小区去往非毫微微小区的空闲模式重选可以遵循用于重选到这样的小区的传统方式。

来自或去往毫微微小区的连接模式移动

关于宏eNB和H(e)NB之间以及H(e)NB之间的移动性，在版本8中很可能仅支持外出移动。外出移动可以是UE从H(e)NB向宏eNB切换。在版本9中，一项增强可以支持进入移动。进入移动可以是UE从宏eNB向H(e)NB切换。

混合小区

在版本9中引入的混合小区可以是属于CSG并且具有CSG ID的小区。然而，混合小区可以允许访问其CSG成员和非CSG成员。非CSG成员可以是没有向混合小区所属于的CSG预订的UE。在版本8中，可以通过混合小区广播的CSG ID，并通过将CSG指示符比特(E-UTRAN)或CSG指示比特(UMTS)设置为与非毫微微小区相对应的值来识别该混合小区。还可以通过广播信令来发送CSG指示比特。

“PCI/PSC分离”

在E-UTRAN中，相邻小区列表可以不是显式的。换而言之，相邻小区列表不需要明确标识相邻小区。而是，相邻小区列表可以指示频率，以及可选地，移动设备不应当尝试访问的“不允许”的列表或黑名单小区。可以期望UE通过盲搜索在频率上检测小区。然而，盲搜索在许多被检测的小区是毫微微小区的情况下可能会导致困难。为了将不具有CSG预订的设备对这种小区的不必要处理最小化，网络可以可选地指示可向毫微微小区应用PCI分离，即为毫微微小区保留的物理小区标识的集合。当运营商在相邻小区列表中的确列出毫微微小区的情况下，PSC分离可以是用于UMTS小区的类似指示。可能地，PCI/PSC分离可以被用于区别混合小区和非混合小区。

测量目标和测量标识

在UTRAN和E-UTRAN中，eNB可以为UE设置测量目标和测量标识以触发来自UE的测量报告。测量目标可以与具体的载频相关联。该具体的载频可以和服务小区的频率相同，或在频率间测量的情况下与服务小区的频率不同。eNB可以为UE配置一个或更多测量目标。

为了触发来自UE的测量报告，eNB可以为UE配置一个或更多测量标识。每个测量标识可以与测量目标和报告配置相关联。报告配置可以定义基于其来触发来自于UE的测量报告的准则，例如RSRP和/或RSRQ阈值。

基于优先级的重选算法

作为E-UTRAN介绍的一部分，可以将重选算法规定为：当考虑到作为自主重选的候选者的不同小区之间的优先级时，针对单个用户，在不同小区的相对优先级上给予运营商更大的灵活性。该算法可以应用于E-UTRAN、UTRAN和GERAN网络，以及可能的其他网络。该重选算法可能在考虑重选至毫微微小区时不能应用。基于优先级的重选算法可以规定：对于被允许执行自主重选并且当前已经驻留在一组中的一个小区上的UE，移动设备是否应当重选至不同组中的小区。

对于UTRAN和E-UTRAN，小区可以根据其操作类型(例如频分复用(FDD)或时分复用(TDD))以及操作频率进行分组。例如，中心频率为2.152GHz的所有TDD小区可以被考虑在一组中。在另一示例中，所有GERAN小区可以被考虑在一组中。

可以向每组小区指派优先级级别，或者可以不指派任何优先级级别。在正常操作中，移动设备可以不考虑重选任何未被分配优先级级别的小区。对于正常操作，需求可以是：移动设备知道其当前驻留的小区的优先级级别。可以不向使用不同技术(例如GERAN、UTRAN或E-UTRAN)操作的两个小区组指派相同的优先级级别。

可以规定用于对应用于服务小区(“S_serving”)和重选候选小区(“S_tgt”)的参量“S”进行评估的度量。这些度量可以是特定于RAT类型的。可以规定用于服务小区的阈值，例如Thresh_serving。可以为目标小区组规定两个阈值，根据其具有比服务小区更高的优先级，阈值为Thresh_tgt(high)，或者具有比服务小区更低的优先级，阈值为Thresh_tgt(low)。如果(1)对于具有比服务小区更高优先级的目标小区，S_tgt＞Thresh_tgt(high)；或者(2)对于具有比服务小区更低优先级的小区，S_serving＜Thresh_serving并且S_tgt＞Thresh_tgt(low)，则可以重选被执行。

其他术语

下面两个术语可以不是特定于CSG移动性的。“切换准备”可以是网络侧过程，包括由服务(源)小区对目标小区的分配用于UE的资源的请求。“SI获取”可以是接收和解码小区中的广播***信息。可以将SI获取用于获得例如切换准备信息。

下面的三个术语可以是特定于CSG移动性的。“初步访问检查”可以是通过检查CSG成员资格来确定是否允许UE访问毫微微小区的过程。换而言之，可以使用初步访问检查来确定小区的CSG ID是否在UE允许CSG列表中。“切换评估”可以是获取小区全球ID和执行初步访问检查的过程，该两个过程都在UE执行。第三个术语，“切换准备信息”可以指代由初步访问检查获得的信息，加上小区全球标识(CGI)和TAI。

图5是根据本发明实施例的非漫游架构的框图。具体地，可以使用图5中示出的非漫游架构来实现VoLGA。可以将VoLGA视为在LTE上经由通用接入来实现UE 108a或108b语音服务的设备和软件(注意，LTE可以是E-UTRAN)。图5中的特定附图标记与图1到图4中的一个或多个图共用；这样的共用附图标记指代相似部件并且具有相似的功能。然而，在图5中所示的实施例中，UE 108a和108b还支持VoLGA协议栈。

在VoLGA中，运营商可以重复使用在E-UTRAN 504创建的E-UTRAN覆盖下控制CS服务的建立的现有CS域实体，例如MSC/VLR502。VANC 506可以使UE 108a或108b使用由EPS提供的一般IP连接访问MSC/VLR 502。可以使用A接口(“VoLGA A模式”)或Iu-CS接口(“VoLGA Iu模式”)将VANC 506连接到MSC/VLR 502。每个接口都在508处示出。从EPS的角度来看，VANC 506被视为UE 108a或108b之间的应用功能和“Z1”接口510，并且VANC 506可以基于3GPP TS43.318中定义的“Up”接口。

基本功能

VANC 506可以与VoLGAA模式中的BSS类似地操作，或者可以类似于VoLGA Iu模式中的RNC，朝向CS核心网络。VANC 506可以包括SeGW 512，其能端接来自于每一个UE 108a或108b的安全远程访问隧道。SeGW 512可以提供对于信令业务的相互验证、加密和完整性保护。下面提供由VANC 506提供的一些功能。

VANC 506可以支持UE-VANC协议。针对寻呼，UE-VANC协议可以用于NAS CS域信令消息的封装，并且针对VoLGA注册过程，向UE提供通常在***信息中广播的CN参数。VANC 506可以支持与HOSF的VANC-UE绑定创建和删除过程。此外，VANC 506可以支持对正在建立的紧急呼叫的检测。

在切换的情形中，HOSF 514可以决定来自于MME 210的切换请求是用于VoLGA还是用于IMS/SRVCC。HOSF还可以因此将该请求寻路至例如服务VANC 506或增强了SRVCC的MSC服务器518。HOSF514可以支持VANC-UE绑定创建和删除过程，以使得HOSF 514可以基于所存储的服务VANC 506的记录来针对UE 108a或108b做出这些决定。HOSF 514可以是根据运营商需求部署的逻辑功能实体。例如，可以将514部署为独立的实体，或者可以嵌入在MME 210或VANC 506中。

可以需要或希望UE 108a或108b的特定功能来支持VoLGA。这些功能的示例包括探索VANC 506和向VANC 506注册、通过VANC 506的针对MM和CM的CS相关的NAS过程、以及用户平面上的VoIP。

VoLGA中的紧急服务

对于具有正在PLMN中获取普通服务的有效USIM的UE，基于运营商偏好，可以经由E-UTRAN中的VoLGA或经由GERAN/UTRAN中的CS域来支持紧急服务。VANC 506可以在VoLGA注册过程中指示进行紧急呼叫的接入网络偏好。VANC 506确保MSC 502接收到正确的小区全球ID(CGI)，以用于向合适的PSAP路由紧急呼叫。

如果访问网络偏好是GERAN或者UTRAN，并且如果从VoLGA订户归属PLMN或者从漫游至PLMN的任何用户，GERAN或UTRAN覆盖都是可用的，则UE可以或应当自主从VoLGA模式切换到GERAN或UTRAN模式并且在GERAN或UTRAN上进行紧急呼叫。在紧急呼叫完成之后，为了回叫，UE可以停留在GERAN或UTRAN中特定的时间量，以影响在GERAN或UTRAN中的位置确定基础架构。然而，该行为并不需要是VoLGA特有的。

如果访问网络偏好是E-UTRAN，并且如果从VoLGA订户归属PLMN或者从漫游至PLMN的任何用户，E-UTRAN覆盖都是可用的，则UE可以经由MSC在VoLGA上进行紧急呼叫。VANC 506可以基于多个因素中的一个或多个来检测紧急呼叫正在建立中。这些因素的示例包括GACSR/RRC请求消息中的建立原因(Establishment Cause)IE，和/或指派请求(Assignment Request)或RAB指派请求(RABAssignment Request)消息中包括的优先级值。可以基于运营商配置来使用优先级值检测紧急呼叫。

在限制服务状态下，具有CS语音能力的VoLGA UE 108a或108b可以或应当一直驻留在很可能支持CS域的RAT上，例如在TS23.221中规定的GERAN或UTRAN。这样的UE可以在GERAN或UTRAN CS域上进行紧急呼叫。

VoLGA***的多个其他组件在图5中示出并且在3GPP TS中描述。这些组件包括HLR/HSS 120、AAA服务器520、PCRF522和S-GW/P-GW524。其他接口在图5中显示并且在3GPP TS中描述。这些接口包括Sv接口526、S1-C接口528、S1-u接口212、LTE Uu接口208、SGi接口530、Gx接口532、Rx接口534、Z3接口536、Wm接口538、D接口116和D’接口540。

现在注意力转移到描述与在使用VoLGA或其他一些***时处理紧急呼叫有关的多个问题。至少存在五个不同的问题。第一个问题是网络可靠性。第二个问题是潜在缓慢的小区重选过程。第三个问题是对紧急服务的支持和对在紧急呼叫期间未能维持可靠网络的责任。第四个问题是小区拥塞。第五个问题是在E-UTRAN毫微微小区上对VoLGA中的紧急呼叫的支持。也存在其他问题。将依次描述这些问题中的每一个。

对紧急服务的支持中的可靠性

在支持紧急呼叫的上下文中可能出现的第一个问题是网络的可靠性，尤其是当使用H(e)NB时。这些设备应当支持紧急呼叫。然而，这些设备与非H(e)NB小区相比可能存在可靠性问题。然而，紧急呼叫的可靠性不应当由于毫微微小区的部署而降低。

3GPP TS22.011(版本8)和TS22.101(版本9)规范阐述了H(e)NB应当支持用于CSG和非CSG成员的紧急呼叫(TS22.011，子条款8.5.1提供了“HNB/HeNB应当支持用于CSG和非CSG成员的紧急呼叫”)。此外在版本9中，服从于网络资源的可用性，当使用PLMN经由H(e)NB或经由NB/eNB提供的服务时，在用户体验上没有区别，注意(与其他小区不同)这些资源可以不在网络运营商的控制下。

H(e)NB由于有限的资源可能不能够支持来自CSG或非CSG成员的所有紧急呼叫，或者不可提供充足的可靠性。然而，当UE驻留在毫微微小区上时，应当存在可靠地支持紧急呼叫的机制。

当考虑到毫微微小区中对语音呼叫的支持时，可以考虑两种类型的资源：将毫微微小区连接到运营商核心网的无线链路上的资源和有线网络上的资源。要支持的有线网络上的资源可以是该架构中的Iuh和S1接口。对这些资源的支持可以通过DSL链路或类似连接的方式。此外，可以通过HNB GW将毫微微小区连接到运营商核心网络。

在毫微微小区中创建的紧急呼叫中可能存在多个失败点，该紧急呼叫可能不如使用宏小区的呼叫重要。例如，到毫微微小区的电源可能被切断，例如由用户无意间绊倒向H(e)NB供电的电源电缆而造成，或者通过在工作日结束时关闭H(e)NB。在另一个示例中，支持H(e)NB连接的DSL连接可能丢失，例如当Iuh和S2接口在用户归属网络和H(e)NB GW所驻留的的运营商网络之间传输时。其他H(e)NB/HNB所特有的问题也可能存在。

当部署毫微微小区时需要避免紧急呼叫的低可靠性，尤其是对于正驻留在毫微微小区中UE。同样希望确保由这样的UE创建的紧急呼叫具有合适的可靠性。

缓慢的重选过程

上面引入的第二个问题是潜在缓慢的小区重选过程。连接到毫微微小区并涉及紧急呼叫，或者在毫微微小区中驻留并尝试紧急呼叫的UE可能需要重选到另一个小区。重选可以是希望的或者必须的，因为毫微微小区不支持紧急呼叫(临时地或永久地)。如果小区不支持紧急呼叫，则UE使用相同或不同的RAT执行到另一个毫微微小区的重选，或者执行到宏小区的重选。作为重选过程的一部分，UE执行对可用小区的扫描。

重选过程可以是所不期望地耗时的。在UE能够在新小区上建立或重建紧急呼叫之前，或在UE对于来自PSAP的回呼是可及的之前，可能使用大量的时间。。

紧急服务的支持和责任

上面提及的第三个问题涉及可能性。每一个区域、国家和/或管辖区可以具有与紧急服务的可靠性相关的其自身的规则和规定。当用户通过宏小区的方式执行紧急呼叫时，宏小区的运营商可以对传送保证紧急呼叫负责。换而言之，可以由法律来要求该运营商保证特定程度的可靠性。该运营商可以对未能连接或维持紧急呼叫负有法律责任。

运营商可以限制或管理其在这点上的风险，因为运营商不仅拥有并控制基站，还拥有并控制无线接入网络和核心网络。当基站、无线接入网络和核心网络被另一方(例如第三方运营商)拥有时，则在进行提供的运营商和第三方运营商之间存在着协议，该协议涉及哪一方承担紧急呼叫失败或掉话的责任。

随着H(e)NB的引入，这些情况可能变化。例如，H(e)NB可以位于用户家中。在另一个示例中，H(e)NB可能位于企业或校园。无论哪种情况，毫微微运营商可以部署H(e)NB来提高覆盖或提供增值服务，例如在覆盖范围内的本地IP接入。这些个人或组织不希望对于紧急呼叫承担责任。

作为通过H(e)NB建立的紧急呼叫可能由于毫微微运营商控制困难的原因而失败的事实所导致的结果，紧急呼叫责任的问题可能加剧。一个有疑问的场景是，由于H(e)NB所位于的场所的拥有者不知道正在进行紧急呼叫，不知情地或无意地将H(e)NB的电源切断，呼叫失败。另一个场景可能发生在当由于房屋IP连接中的故障而导致H(e)NB到运营商核心网络的连接中断时，这是H(e)NB运营商所不能控制的因素。

在例如上述的场景中，确定哪一个个人或组织为紧急呼叫失败或掉话负责可能是困难的。运营商对于家庭或企业网络如何操作的控制是有限的，无论是操作时间有限、电源或回程的可靠性等等。H(e)NB所位于的场所的拥有者可能不希望对于失败的紧急呼叫负责。

毫微微小区拥塞

上面引入的第四个问题是毫微微小区拥塞的可能性。在特定的场景中，可能不保证紧急呼叫的可靠性，因为毫微微小区可能拥塞。拥塞可能由于一个或多个因素而出现，包括但不限于无线条件、当前用户的数量、用户正在传送的数据量。

正常来说，UE对于无线小区是否拥塞不太或根本不知道。在毫微微小区的情况中，拥塞可能由于非无线条件引起，例如在毫微微小区和运营商核心网络之间的网络链路上的拥塞。因此，UE没有办法决定UE是否应当在毫微微小区上尝试紧急呼叫。

E-UTRAN毫微微小区上对VoLGA中紧急呼叫的支持

上面引入的第五个问题是E-UTRAN毫微微小区上对VoLGA中紧急呼叫的支持。VoLGA标准描述了当UE被连接到宏E-UTRAN小区时UE如何操作紧急呼叫。然而，VoLGA规范没解决与毫微微小区上对VoLGA紧急呼叫的支持有关的问题并且没解决上面描述的问题。

解决上述问题的多个实施例

这里描述的实施例提供了解决上述问题，以及解决其他问题的技术。在一个实施例中，紧急呼叫的可靠性可以通过确保当移动设备在驻留或处于毫微微小区的激活连接期间尝试建立紧急呼叫时，设备首先重选到覆盖区域内的宏覆盖并然后在宏小区上建立呼叫来保证。该技术可以被称为绕开毫微微小区。该技术可以解决以上任意问题。

在第二个实施例中，在UE尝试毫微微小区上的紧急呼叫的情形中，当呼叫在毫微微小区中掉话的情况下，UE可以准备重选到宏覆盖。此外，该技术可以结合这里描述的其他实施例使用。

在第三个实施例中，可以提供紧急服务，然而可提供对这些服务的可靠性未被保证的指示。例如，网络可以向UE发送紧急呼叫支持指示符(ECSI)，指示所支持的紧急服务的类型。而UE可以向网络发送紧急呼叫要指示符(ECRI)，指示UE请求的紧急服务的类型。网络可以通过向UE提供具有对仅支持受限制的紧急服务进行指示的值的ECSI，指示对受限制的紧急服务的支持。UE可以通过向网络提供ECRI来要求紧急服务的特定集合。例如如果毫微微小区的所有者不希望在毫微微小区上创建的紧急呼叫失败的情况下承担责任，则该所有者可以决定发送ECSI以指示仅支持受限制的紧急服务。该实施例解决了上述第三个问题，虽然该实施例还可以与这里描述的其他实施例一起使用以解决上述其他问题。

在第四个实施例中，在毫微微小区拥塞的情况下，UE能够重选到宏小区，而无需由网络进行切换。UE可以处于空闲模式或激活模式。该实施例提供了UE知道毫微微小区拥塞的一套机制，如下面将要进一步描述的。该实施例解决了上述第四个问题，还可以与这里描述的其他实施例一起使用，解决上述其他问题。

下面的段落描述了上述四个实施例的详细实施例和变形。下面单独提出上述四个实施例中的每一个。

I.宏小区有利情况下绕开H(e)NB

现在将注意力转向上述实施例，其中，当进行紧急呼叫时，UE将尝试直接连接到宏小区，即使毫微微小区或其他宏/毫微微小区是可用的。该技术将通过以下方式来保证紧急呼叫的可靠性：确保当移动设备尝试在毫微微小区中建立紧急呼叫时，UE首先重选到覆盖区域内的宏小区，然后建立呼叫。该实施例中的大部分行为在AS层，而不是在NAS层。重选可以在RRC协议层，以及RRC协议层知道正在因为紧急情况而建立呼叫。由于该原因，NAS不需要知道这里描述的技术，然而在其他实施例中可以知道。

在宏小区有利的情况下绕开H(e)NB的情况1：适用于在允许自主重选的状态下驻留在UTRAN HNB中的UE

针对UE在允许自主重选的状态下驻留在UTRAN H(e)NB中的情况，可以执行下面的步骤来实现在宏小区有利的情况下绕开H(e)NB。首先，CC实体可以发起移动起始呼叫。作为该呼叫的结果，如果RRC连接当前不可用，UE中的MM层可以将该请求传递到RRC层，并且可以为了进行紧急呼叫而请求RRC连接。在任意情况中，RRC层可以知道紧急呼叫将由设备发起。

在第二步骤中，RRC层确定：第一，该请求用于紧急呼叫，以及第二，UE当前驻留在HNB小区中。UE驻留在HNB小区中的事实可以通过CSG指示符来指示，该CSG指示符可以在当前服务小区的SIB1中发送。

在可选的第一附加步骤中，UE可以向服务小区指示其正在执行小区重选，并且还可以指示小区重选的目的是建立紧急呼叫。UE还可以提供所选目标小区的标识符或标识特征。在可选的第二附加步骤中，可能根据第一附加步骤，UE可以接收由服务H(e)NB指示的一个或多个目标小区和适用于目标小区的***信息。在该方法中，可以向网络告知小区重选的原因。

在第三步骤中，RRC层可以发起到备选的非H(e)NB小区的重选，该非H(e)NB小区可以是宏小区。在第四步骤中，RRC层可以为了发起紧急呼叫而执行RRC连接建立。很可能地，可以将RRC连接建立与其他移动性管理过程协同执行，例如但不限于LAU或RAU过程。

对于上述过程，可以根据方便来规定MM、CC和/或RRC层之间的区分和功能分离。区别和功能分离在给出的实现中不是必须的，无论是在现有的TS中或关于这里描述的实施例。在一个实施例中，该提示适用于参考协议层的所有实施例。

在上述过程的另一个实施例中，关于第三个步骤，可以根据基于优先级的小区重选算法执行小区重选过程。一个示例性的重选可以如下。可以认为服务小区的信号质量低于可适用的阈值。这样，不管S_serving的实际值如何，S_serving可以比Thresh_serving小。此外，或备选地，知道在服务小区处于专用于HNB小区的频率上的情况下，UE可以不执行频率内重选，而是就像UE不具有针对该频率或仅有毫微微小区知道的或其他频率的指派的优先级那样进行操作。在任何情况中，无论使用频率内还是频率间小区重选，UE可以使用UE存储的任意PCI/PSC分离信息以避免执行到毫微微小区的重选。

在实现基于优先级重选算法的情况中，上述方法可导致最小限度的复杂性增加。进一步地，该方法最大化UE将执行至具有最强信号质量并且不是另一个毫微微小区的小区的重选的可能性。

上述第三个步骤可能进一步需要重选到属于不同PLMN的小区，例如在仅有可用于服务PLMN的小区是毫微微小区的情况中。在该情况下，可以应用由3GPP TS23.122和3GPP22.011提供的PLMN选择规则。

在宏小区有利的情况下绕开H(e)NB的情形2：适用于在不允许自主重选的状态下驻留在UTRAN HNB中的UE

针对UE在不允许自主重选的状态下驻留在UTRAN H(e)NB中的情况，可以执行下面的步骤来实现在宏小区有利的情况下绕开H(e)NB。情况2与情况1类似，除了在执行重选之前可以释放正在进行的RRC连接。情况2有一些备选的子实施例。

在第一个子实施例中，可以使用切换过程。在该情况中，UE在测量报告中或通过其他方式来指示目标小区。UE还指示测量报告以及对请求将切换用于紧急情况的指示。

在第二个子实施例中，也可以使用切换过程。在上述第一子实施例之外，UE可以解码非服务小区的广播信道。然后UE接收广播***信息(MIB/SIB)中的一些或全部。如果非服务小区不是毫微微小区，或指示其以被UE支持的方式可靠地支持紧急呼叫(例如，小区和UE都支持基于IMS的紧急呼叫)，则UE可以向服务小区发送指示一个或多个因素的消息。因素的一个示例可以是非服务小区的允许服务小区发起到非服务小区的切换准备过程的充分标识信息。该指示假定服务小区不知道非服务小区的存在。因素的另一个示例可以是测量信息，例如信号强度、信号质量以及其他测量信息。因素的另一个示例还可以是对请求将切换用于紧急情况的指示。要指示的其他因素也同样存在。

参考上述情形1和2描述的用于切换的实施例将比普通的小区重选过程更快速地完成。进一步地，毫微微小区控制器不需要知道适用于目标小区的路由信息。更进一步地，MIB/SIB读取可以是为了将已连接的移动性内部绑定到例如毫微微小区的UE中所需要的功能。该功能可以很可能已经是到毫微微小区的切换所需要的，并且因此该实施例需要较少的附加复杂性。

以其他术语来描述，作为NAS的示例，UE可以知道CSG连接性，意味着UE可以在小区中驻留或连接，例如UTRAN毫微微小区。在用户在毫微微小区中尝试CS紧急呼叫时，UE的NAS需要建立CS承载并且UE可以决定在进行紧急呼叫之前触发到宏小区的重选。如果UE处于空闲模式中，到目标宏小区的小区重选可以由UE自主执行。如果UE处于连接模式中，由于在UTRAN或E-UTRAN中不支持UE发起的切换，则UE可以释放毫微微小区中现有的RRC连接并且在目标宏小区上建立新呼叫和RRC连接。

该重选可以不作为切换被执行。相反，基于重选结果，UE可以简单地自主重新选择到相同RAT类型或不同RAT类型的宏小区。在该切换期间，可以丢弃或暂停在重选之前已经激活的其他服务。这样服务的一个示例是PS数据服务，然而可以是任何类型的服务。在一个示例中，如果UE在重选后已经具有到分组核心的连接，则UE可以使用GPRS和EPC过程来暂停承载。一旦UE已经选择了宏UTRAN或GERAN小区或可能用于UE建立紧急呼叫的其他小区，UE可以建立紧急呼叫。

在上述情况2的变形中，触发是IMS紧急呼叫会话的建立。当具有IMS功能的UE尝试建立紧急呼叫时，在IMS应用请求紧急承载时，UE一般可以尝试建立紧急承载，例如PDN连接或PDP上下文或执行紧急附着以支持IMS紧急呼叫的IP业务。然而，由于UE知道服务小区是毫微微小区，当IMS应用请求紧急承载时，UE可以不尝试在毫微微小区上建立紧急承载。而是，UE可以触发到具有相同RAT的宏小区或到不同RAT(例如UTRAN或GERAN(如果服务小区曾是E-UTRAN))或到非3GPP接入技术(例如WLAN)的重选。在这种情况下，UE可以在目标小区中继续紧急呼叫建立。如果UE处于空闲模式，则到目标宏小区的小区重选可以由UE自主执行。如果UE处于连接模式，并且由于在UTRAN或E-UTRAN中不支持UE发起的切换，则UE可以释放在毫微微小区中现有的RRC连接并在目标宏小区上建立新呼叫和RRC连接。

在切换期间，可以丢弃或暂停在重选前已经激活的其他服务，例如PS数据服务。可以使用IMS或使用CS域来执行在UE已经重选到的RAT上建立紧急呼叫。

在实施例中，在重选到不支持CS域服务的小区(例如E-UTRAN)之后，如果新小区支持VoIMS(在具有VoIMS指示的NAS信令中向UE指示)，则UE可以通过建立紧急承载来继续IMS紧急呼叫的建立，。

在另一个实施例中，UE可以重选到CS域服务和IMS都支持的小区(例如UTRAN小区)。在这种情形中，UE可以继续IMS紧急呼叫的建立或UE可以建立CS紧急呼叫。如果小区支持VoIMS(在具有VoIMS指示的NAS信令中向UE指示)，则UE可以继续IMS紧急呼叫的建立。UE可以被配置为关于CS域的使用，偏好使用VoIMS。

在另一个实施例中，UE可以重选到支持CS域服务而不支持IMS的小区(例如GERAN小区)。在这种情况中，UE可以建立CS紧急呼叫。

在上述情形2的变形中，核心网络实体(例如MME或SGSN)可以知道H(e)NB连接性。在这种情况下，当IMS UE尝试生成紧急呼叫时，UE可以尝试建立紧急承载，例如PDN连接或PDP上下文，以支持用于IMS紧急呼叫的IP业务。

E-UTRAN毫微微小区的MME，或UTRAN HNB小区的SGSN或MSC可以知道在UE处于连接模式期间，UE经由H(e)NB小区连接。网络可以拒绝紧急承载建立。在该情况下，两个事件中的一个可能发生。首先，UE可以通过触发重选进行反应，如上述情形2的第一变形。其次，网络(例如UE的服务H(e)NB与MME一起，或H(e)NB与SGSN或MSC一起)可以触发UE切换到宏小区。在一个实施例中，MME可以信号通知服务H(e)NB以指示其开始UE的切换目标小区选择和切换准备机制。在切换期间，可以丢弃或暂停在重选前已经激活的其他服务，例如PS数据服务。

在一个实施例中，UE可以重选到支持IMS、CS域服务，或二者都支持的小区。将进一步参考如上所述情况2的第一变形描述该实施例。

在宏小区有利的情况下绕开H(e)NB的情况3：当UE知道H(e)NB连接性，例如UE中的VoLGA CS栈时。

关于在宏小区有利的情况下忽略H(e)NB的技术的第三个情形可应用于当UE知道H(e)NB连接性，例如UE中的VoLGA CS栈时。在这种情况下，UE可以驻留例如UTRAN毫微微小区的小区上。由于在E-UTRAN PS承载之上提供VoLGA CS连接性，E-UTRAN NAS栈可以向VoLGA CS栈提供UE在毫微微小区中驻留的指示。

在该情形中，当在毫微微小区中尝试CS紧急呼叫时，UE中的VoLGA CC机可以向UE的NAS中VoLGA CS栈请求建立CS承载。UE(例如UE中的VoLGA CS栈)可以知道UE正在毫微微小区中驻留或连接到毫微微小区。基于这样的认识，UE可以决定在处理紧急呼叫之前触发到宏覆盖的重选。

重选可以不作为切换来执行，而是UE基于重选的结果，可以简单地重选到具有相同RAT类型或不同RAT类型的宏覆盖。如果UE处于空闲模式，则UE可以自主执行到目标宏小区的小区重选以驻留。如果UE处于连接模式，并且由于UE发起的切换在UTRAN或E-UTRAN中可能不支持，UE可以释放毫微微小区中现有的RRC连接并在目标宏小区上建立新呼叫和RRC连接。

在切换期间，可以丢弃或暂停在重选前已经激活的其他服务，例如PS数据服务。如果UE重选到UTRAN或GERAN宏小区，则UE可以附着到CS域并建立CS紧急呼叫。如果UE重选到E-UTRAN宏小区，UE可以使用VoLGA CS栈在非紧急E-UTRAN承载上建立CS紧急呼叫，或者UE可以使用VoLGA CS栈在紧急E-UTRAN承载上建立CS紧急呼叫。

在宏小区有利的情况下绕开H(e)NB的情况4：当通过网络或服务网络配置UE并且UE可以被配置为移动针对紧急呼叫的宏接入时。

关于在宏小区有利的情况下绕开H(e)NB的技术的第四种情形可应于当通过网络或服务网络配置UE并且UE被配置为基于HPLMN提供的特定列表移动针对紧急呼叫的宏接入时。网络可以是家庭网络，例如HPLMN或EHPLMN或一些其他家庭网络。服务网络可以是RPLMN或其他服务网络可以使用OMA DM和特定管理对象，或者通过一些其他手段配置UE。该第四种情况可以与上述第1至3种情况相结合。

在情况4的实施例中，网络可以将UE配置为具有有紧急能力的毫微微小区的列表。可以使用该列表来提供对可在其上建立紧急呼叫的毫微微小区进行标识的标识符。该列表可以包括一些选项，包括但不限于下列。

列表的一个选项可以是对UE可以在其中在毫微微小区中建立紧急呼叫的小区集合进行指示的表征标识符的集合。这些标识符可以指示例如，MCC、MNC、LAI以及可能的其他ID。在该选项中，例如该列表可以包括PLMN ID(各自包括MCC和MNC)集合，并且在仅当毫微微小区属于其PLMN ID在有紧急能力的毫微微小区列表中的PLMN时，UE才可以在毫微微小区中建立紧急呼叫。UE可以仅使用由HPLMN或EHPLMN发送的列表。当这样的列表被接收时，UE覆盖之前由HPLMN或EHPLMN发送的任意先前列表。可以存储该列表，作为USIM中、或压缩闪存、微SD、UICC、R-UIM或任何其他存储设备中的基本文件。备选地，该列表可以在一些其他过程期间(例如RAU、LAU、附着过程或一些其他过程中)由网络提供给UE。该列表可以本地存储在UE中。在这种情况下，如果这样的列表由不是HPLMN或EHPLMN的RPLMN接收，则UE可以不覆盖存储的列表。

如果网络仅知道H(e)NB在其自身网络中的能力时，可以应用有紧急能力的毫微微小区的列表的另一个选项。在这种情况中，网络发送单独的指示，指示这样的H(e)NB是否支持紧急呼叫。UE可以使用来自从RPLMN聚集的指示的这些信息，以建立对哪些PLMN具有CSG紧急支持以及哪些不具有CSG紧急支持进行跟踪的本地列表。例如，UE可以存储从一个PLMN接收的指示并且在另一个PLMN上驻留期间利用该指示，以例如确定UE能够检测到但当前未驻留的小区可以提供紧急服务。该支持可以扩展到等同的PLMN或者可以专用于每一个PLMN。如果支持扩展到等同的PLMN，则UE可以通过将来自RPLMN的单独指示与由RPLMN在过程(例如RAU、LAU、TAU、附着过程或一些其他过程)期间发送的EPLMN列表相结合来扩展UE的CSG紧急支持信息。

有紧急能力的毫微微小区列表的另一个选项是表征一个或多个毫微微小区的特定ID集合。在该情况中，可能仅当毫微微小区的H(e)NB ID在有紧急能力的毫微微小区列表中时，UE才可以在毫微微小区中建立紧急呼叫。该列表可以在过程(例如RAU、LAU、TAU、附着过程或一些其他过程)期间向UE发送。可以将列表的有效性限制在使用的过程中。在改变区域时，可以用新列表整体替代该列表。备选地，当接收新列表时，可以向存储在UE中的先前列表添加或更新新的信息。该列表可以本地存储在UE中。

有紧急能力的毫微微小区列表的另一个选项是PLMN ID集合以及针对每一个PLMN ID的H(e)NB集合。在这种情况中，很可能仅当有紧急能力的毫微微小区列表中包含具有当前毫微微小区的PLMN ID和H(e)NB ID二者的条目时，UE才可以在毫微微小区中建立紧急呼叫。如果在一些点H(e)NB ID对于PLMN是独特的，如果UE当在给定PLMN中时需要或想要分割非常大的H(e)NB列表以减少搜索时间，该过程可能是重要的，或者由于一些其他原因，该过程是重要的。该列表存储在USIM的EF中，或可以本地存储在UE中。

上述选项并不是穷尽的。其他选项也可以存在。此外也可以使用这些选项的结合，并且其他参数可以被添加或与上述技术结合。

无论选择什么选项，当UE需要或想要在驻留或连接到(例如在连接模式中)毫微微小区期间建立紧急呼叫时，UE可以将当前毫微微小区信息与有紧急能力的毫微微小区列表的内容进行验证。该过程可以应用于家庭和漫游场景中。在可选的实施例中，服务PLMN可以提供允许UE用于H(e)NB紧急呼叫的有紧急能力的毫微微小区列表。该列表可以在MO中提供。

II.紧急呼叫期间的重选准备

上述实施例描述了绕开毫微微小区，或使用允许的毫微微小区的技术。注意力现在被转移到用于解决上述在H(e)NB上进行紧急呼叫的问题。具体地，下面的实施例提供了在紧急呼叫期间或之前准备小区重选。

具体地，这些实施例可以提供在毫微微小区中的紧急呼叫期间执行背景搜索。在UE尝试在毫微微小区上紧急呼叫的情况中，UE可以在毫微微小区中掉话时准备重选到宏小区。该实施例可以与上述实施例结合。例如，如上所述，UE可以在与毫微微小区连接之前尝试连接到宏小区，并且还可以执行背景搜索，以在用于第一紧急呼叫的连接由于各种原因失败的情况下能够重选到另一个小区。

基于UE知道其连接到毫微微小区，UE可以在紧急呼叫期间执行背景搜素以探索如果到当前服务毫微微小区的连接丢失，应当重选到哪一个目标小区来重建呼叫。目标小区可以是相同RAT类型的另一个毫微微小区，可以是不同的RAT类型，可以是相同RAT类型的宏小区，可以是不同RAT类型的宏小区，或者可以是任意其他合适的小区。

UE可以在上述涉及绕开毫微微小区的一个场景中，在该情况中，UE可以基于在背景搜索期间获取的信息重选到所选择的目标小区。备选地，UE可以驻留或连接到毫微微小区，并且UE正在毫微微小区中发起紧急呼叫并执行用于紧急呼叫的通话或RRC建立。UE能够执行切换或执行自主的小区重选。

UE的背景搜索可以由一个或多个不同的触发触发。在一个实施例中，可以根据UE特定的实现和参数来由UE自身触发UE执行背景搜索。在另一个实施例中，可以在确定其驻留的小区或其处于激活模式的小区满足具体标准来触发UE执行背景搜索。标准例如可以包括：小区是毫微微小区，或小区是E-UTRAN小区，或小区广播有限的相邻小区列表(例如仅包含具有单独RAT类型的小区)或者标准可以基于小区中支持的协议和/或紧急服务。在另一个实施例中，可以通过从H(e)NB到UE的指示来触发UE执行背景搜索。在该情况中，H(e)NB可以向UE发送执行背景搜索的显式指示或对H(e)NB的剩余资源的级别的指示。例如，H(e)NB可能用完资源，这样，所请求的通话或正在进行的连接可能不能保证。当UE接收该指示时，如果且当需要或想要切换时，UE可以执行背景搜索并准备切换到备选小区。

在另一个实施例中，一旦发起呼叫，在紧急呼叫发起之前发起的背景扫描可被停止。此外，仅当连接正在进行且设备被连接到相同小区期间，背景扫描可以保持去激活。

在上述实施例中，背景扫描可以包括扫描不在服务小区相邻小区列表中的小区。背景扫描还可以包括扫描在语音通话期间一般不期望被监视的小区。小区不期望被监视，因为可能不将H(e)NB配置为广播完整的相邻小区列表，因为H(e)NB可能不支持一些或全部类型的服务切换到一些或全部类型的小区，和/或因为相邻小区列表不包括属于不同PLMN的小区。

可以对不同的PLMN执行空闲模式小区重选。该场景可以使UE寻找在其上能发起紧急呼叫的一些小区。然而如果UE选择了可用的备选择小区，则UE可以选择相同PLMN的小区。类似地，如果背景扫描显示一些备选地小区是可能的且可接受的，则在相同RA、LA或TA中的小区比在不同PLMN、RA、LA或TA上的小区更加优先。

在一个实施例中，UE可以使得MIB或SIB在紧急呼叫期间禁止读取和报告已知或不可信毫微微小区的能力。作为对该禁止规则的可能的例外，如果所讨论的的H(e)NB清楚地指示H(e)NB支持紧急呼叫，则UE可以不执行这样的禁止。另一个可能的例外是UE已经存储了对所讨论的H(e)NB支持紧急呼叫进行指示的信息，例如指纹信息。作为这样的禁止规定的另一个可能的例外，如果没有能够在测量报告中报告的备选切换候选小区，则UE可以不执行这样的禁止。

在紧急呼叫期间或之前的小区重选准备减少了对于正在进行的紧急呼叫的服务中断。虽然仍存在对UE的影响，然而该技术还避免了网络尝试发起到不支持紧急服务的毫微微小区的切换。

III.受限制的紧急服务

上述实施例描述了绕开HeNB小区或使用允许的HeNB的技术，并提供了在紧急呼叫期间或之前准备小区重选。注意力现在被转移到用于解决上述在HNB/HeNB上进行紧急呼叫提出的问题的第三个技术。特别地，下面的实施例提供了对可靠性不被保证的紧急呼叫支持进行限制，或至少提供对不保证可靠性的指示。

关于限制紧急服务支持的概念，下面提供了三个实施例。在第一实施例中，HeNB小区可以向UE提供紧急呼叫支持可用性的指示。在第二实施例中，仅有未保证的紧急服务可能被允许。在第三实施例中，UE可以被重定向。这些实施例将在下面被进一步描述。

首先注意力被转移到第一实施例，用于受限制的紧急服务支持，HeNB小区向UE提供紧急呼叫可用性的指示。该第一实施例包括四个或更多子实施例。

在第一子实施例中，该指示可以在AS级别提供。当选择驻留哪儿时，UE可以考虑该指示。UE选择UE是否在空闲模式中保持在该小区(即接收到指示的小区)中，或者UE可以确定UE是否应当执行远离该小区的重选。UE可以由毫微微小区运营商、用户或其他的实体配置为知道在紧急呼叫上驻留，尝试用于紧急呼叫的RRC连接建立，和/或如果已知紧急服务在毫微微小区中不可用时尝试用于紧急服务的RRC连接建立。

在该第一子实施例中，下面将会进一步描述的ECSI，可以在H(e)NB发送的广播AS级别的***信息中向UE提供ECSI。ECSI可以指示在毫微微小区中是否支持紧急呼叫。

一旦UE接收ECSI，UE可以选择是继续驻留在当前的服务小区中，还是执行远离到另一个小区的重选，和/或以一些其他方式附着另一个小区。重选到哪个小区的决定可以基于UE配置和ECSI。该决定还可以基于现有的信息和机制，例如可用H(e)NB信息，现有的PLMN和小区选择机制以及现有的小区重选机制。

下面的步骤是涉及该第一子实施例，在UE确定其应当不保留在当前服务小区的情况下的决定树的一个示例。首先，UE可以执行PLMN选择。然后UE执行小区选择或重选。确定小区是否可用且合适。在确定负面的情况下，该过程回到执行PLMN选择的第一步骤。在确定正面的情况下，进行服务小区是否是H(e)NB，以及小区是否支持紧急服务的第二确定。如果ECSI指示负面的第二确定，则该过程终止。然而，如果ECSI指示正面的第二确定，则作出UE配置是否指示UE被允许驻留在不支持紧急服务的H(e)NB上的第三确定。负面的第三确定导致过程回到执行小区选择和重选的步骤。正面的第三确定导致过程终止。如果在过程中的任意点处，UE选择多个小区来考虑，则一个或多个小区作为服务小区优先用于维持相同的PLMN、RA、TA或LA。

用于提供紧急服务支持的第二子实施例(可以与第一子实施例结合)可以是UE在AS级别接收ECSI指示符并可能随后选择如何建立紧急呼叫。在该子实施例中，当UE在H(e)NB上驻留并且用户尝试建立紧急呼叫时，UE决定是否重选到宏小区并使用宏覆盖的RAT特有的机制来建立紧急呼叫。执行重选的该决定可以基于UE配置和ECSI。

用于提供紧急服务支持的第三子实施例可以是在NAS信令中提供ECSI指示并在然后允许UE选择附着到哪里(例如，类似于第一子实施例)或者允许UE选择在哪里进行紧急呼叫(例如，类似于第二子实施例)。在初始附着时或在执行针对GERAN或UTRAN的RAU过程时，或在执行针对LTE的TAU过程时，可以向UE提供ECSI。

在实施例中，当UE选择毫微微小区时，可以不执行RAU和TAU过程，因为毫微微小区相对于宏覆盖可以不在独立的RA或TA中。在这种情况下，ECSI对于UE可能不可用。

在任意情况下，UE可以选择保留附着到毫微微小区或者基于UE配置信息和/或ECSI重选到宏覆盖RAT。该选择还可以基于现有的信息和机制，例如可用H(e)NB信息，现有PLMN和小区选择机制，以及现有的小区重选机制。

用于提供紧急服务支持的第四子实施例可以是提供ECSI指示和NAS信令并且允许UE决定如何使用不同的技术来建立紧急呼叫。在该第四子实施例中，UE可以由毫微微小区运营商、用户或一些其他实体配置为知道当紧急服务在毫微微小区中不可用时是否附着到毫微微小区。在初始附着时或在针对GERAN或UTRAN的RAU过程时，或在针对LTE的TAU过程时，可以向UE提供ECSI。ECSI可以指示在毫微微小区中是否支持紧急呼叫。

在一个实施例中，当UE选择毫微微小区时，可以不执行RAU和TAU过程，因为毫微微小区相对于宏覆盖可能不在独立的RA或TA中。在该情况中，ECSI对于UE可能不可用。

然后UE可以选择毫微微小区以附着到网络。当用户尝试建立紧急呼叫时，UE决定是否重选到另一个小区，并使用所选择的小区的RAT特有的机制来建立紧急呼叫。该选择可以基于UE配置和/或ECSI。

上述在AS级别向UE提供ECSI的实施例描述了限制紧急服务支持的概念。在该实施例中，毫微微小区向UE提供对紧急呼叫支持可用性的指示。

在一个实施例中，可以使用用户选择选项来指示选择是在当前小区和仅有的小区(如果没有其他小区被检测)之间。这样，用户可以对UE行为进行一些控制测量。

注意力现在被转移到涉及提供不保证的紧急服务的限制紧急服务支持的概念的第二实施例。该实施例将在下面进一步被描述。

在提供受限制的紧急服务(即可靠性不被保证的)情况中，毫微微小区通过向UE提供ECSI指示对受限制的紧急服务的支持，ECSI具有指示仅支持受限制的紧急服务的值。如果所有者不想对在毫微微小区上建立的紧急呼叫失败的情况下承担责任，则毫微微小区的所有者或运营商决定设置ECSI以指示仅支持受限制的紧急服务。

涉及受限制紧急服务的该第二实施例体现了至少两个子实施例。第一子实施例是可以在AS级别向UE提供ECSI。第二子实施例是可以在NAS信令中向UE提供ECSI。

在第一子实施例中，在AS级别向UE提供ECSI，解决了四个子问题。这些子问题包括UE选择附着到哪里，UE决定如何建立紧急呼叫，用户选择附着到哪里，以及用户决定如何建立紧急呼叫。

这些子问题中的第一个是UE选择附着到哪里的实施例。UE可以由毫微微小区运营商、用户或一些其他实体配置为当在毫微微小区中仅有受限制的紧急服务可用时知道是否附着到毫微微小区。UE可以基于UE配置和ECSI值选择是附着到毫微微小区还是附着到宏小区。该选择还可以基于现有信息和机制，例如可用H(e)NB信息、现有PLMN和小区选择机制，以及现在小区重选机制。

这些子问题中的第二个是UE决定如何建立紧急呼叫的实施例。在该实施例中，如果在初始附着中，UE可以选择毫微微小区来附着到网络。备选地，UE可以基于现有信息和机制，例如可用H(e)NB信息、现有PLMN和小区选择机制，以及现在小区重选机制决定移动到毫微微小区中。

UE可以由毫微微小区运营商、用户或一些其他实体配置为当在毫微微小区中仅有受限制的紧急服务可用时知道是否附着到毫微微小区。当用户尝试建立紧急呼叫时，UE可以决定是否使用宏覆盖的RAT特有的机制移动到宏覆盖并建立紧急呼叫。备选地，UE可以基于UE配置和ECSI决定继续在毫微微小区中。

这些子问题中的第三个是用户选择附着到哪里的实施例。在第一场景中，UE可以在选择附着到毫微微小区之前向用户提供指示。该指示可通过显示指示、声音、震动或任何其他合适的方式提供。该指示传达了在给定的H(e)NB中仅有受限制的紧急服务可用，并对现有的受限制紧急服务的确定基于从AS获取的ECSI值。

对于在当前UE位置中可用的所有H(e)NB，或仅对于允许UE访问的H(e)NB，UE可以由网络或用户配置来向UE指示这样的信息。用户可以选择能够仅访问受限制的紧急服务是否是可接受的，用户可以由此向UE指示用于接受的接受或拒绝。可以通过在菜单中选择合适的选项、按下特定的按钮或任何其他合适的方式来执行该指示。UE然后可以基于用户指示选择是附着到毫微微小区还是附着到宏覆盖RAT。是否进行选择的决定还可以基于现有信息和机制，例如可用H(e)NB信息、现有PLMN和小区选择机制，以及现在小区重选机制。

在涉及用户选择附着到哪里的第二场景中，UE检测毫微微小区并基于现有信息和机制，例如可用H(e)NB信息、现有PLMN和小区选择机制，以及现在小区重选机制确定附着到毫微微小区。此外，或替代地，UE考虑其是否接收到ECSI。ECSI可以未被接收到，例如因为在决定附着到毫微微之前没有执行TAU或RAU，或者UE没有读取来自于毫微微小区的携带了ECSI的AS SIB广播。

如果UE附着到毫微微小区并且随后接收ECSI，并且如果H(e)NBECSI指示仅支持受限制的紧急服务，则UE向用户提供在当前毫微微小区中仅有受限制的紧急服务可用的指示。该指示可以通过显示指示、声音、震动或任何其他合适的指示。

用户然后可以选择能够仅访问受限制的紧急服务是否是可接受的。用户然后可以通过在菜单中选择合适的选项、按下特定的按钮或任何其他合适的方式来向UE指示接受或拒绝。基于这样的指示，UE可以选择是继续附着具有受限制紧急服务的当前毫微微小区，还是重选到宏小区。如果没有宏小区可用，则即使仅有受限制的紧急服务可用，UE可以仍保持在当前小区。

注意力现在转移到涉及在AS级别向UE提供ECSI的第四个子问题。该第四个子问题是用户决定如何建立紧急呼叫。

在该实施例中，UE可以在初始附着中选择UE将附着的毫微微小区，或者UE基于现有信息和机制决定移动到毫微微小区中。这些机制包括可用H(e)NB信息、现有PLMN和小区选择机制，现在小区重选机制，以及其他机制。

在第一场景中，如果毫微微小区提供对仅支持受限制的紧急服务进行指示的ECSI，则UE可以向用户提供该指示。该指示可通过显示指示、声音、震动或任何其他合适的方式提供。该指示传达在当前毫微微小区中仅有受限制的紧急服务可用。用户然后可以选择能够仅访问受限制的紧急服务是否是可接受的。用户还可以向UE指示接受或拒绝。该对接受或拒绝的指示可以是通过在菜单中选择合适的选项、按下特定的按钮或任何其他合适的方式。当用户尝试建立紧急呼叫时，UE可以决定是使用宏覆盖的RAT特有的机制重选到宏小区并建立紧急呼叫，还是保留在毫微微小区。该决定基于用户指示。

在第二场景中，当用户尝试在毫微微小区中建立紧急呼叫时，如果毫微微小区提供对仅支持受限制的紧急服务进行指示的ECSI，则UE向用户提供该指示。该指示可通过显示指示、声音、震动或任何其他合适的方式提供。该指示可以传达仅有受限制的紧急服务在当前毫微微小区中可用。用户可以选择能够仅访问受限制的紧急服务是否是可接受的。用户还可以向UE指示接受或拒绝。该接受或拒绝指示可以是通过在菜单中选择合适的选项、按下特定的按钮或任何其他合适的方式进行的。基于这样的指示，UE决定是使用宏覆盖的RAT特有的机制移动到宏小区并建立紧急呼叫，还是保留在毫微微小区。该决定还基于先前的用户指示。

可以在AS级别向UE提供ECSI的第一子实施例已经被描述。注意力现在转移到涉及受限制紧急服务的第二子实施例，其中可以在NAS信令中向UE提供ECSI。

在该第二子实施例中，在初始附着时或在执行针对GERAN或UTRAN的RAU过程时，或在执行针对LTE的TAU过程时，向UE提供ECSI。如果UE在向毫微微小区移动时执行RAU或TAU过程，则无论UE处于空闲模式或UE正处于切换过程中，都可以提供ECSI。在一个实施例中，当UE选择毫微微小区时可以不执行RAU和TAU过程，因为毫微微小区相对于先前的服务小区可能不在独立的RA或TA中。

该涉及在NAS信令中提供ECSI的第二子实施例体现了四个子问题。这些子问题是UE选择附着到哪里，UE决定如何建立紧急呼叫，用户选择附着到哪里，以及用户决定如何建立紧急呼叫。

涉及在NAS信令中提供ECSI的第一子问题是UE选择附着到哪里。在该实施例中，UE可以配置为当仅有受限制的紧急服务在毫微微小区中可用时知道是否在毫微微小区中建立紧急呼叫。该配置可由毫微微小区运营商或用户实现。

UE可以选择继续附着到毫微微小区或重选到宏覆盖RAT。该选择可以基于UE配置和ECSI值。该选择还可以基于现有信息和机制，例如可用H(e)NB信息、现有PLMN和小区选择机制，现有小区重选机制以及其他机制

涉及在NAS信令中提供ECSI的第二子问题是UE决定如何建立紧急呼叫的实施例。在该实施例中，如果在初始附着中，UE可以选择毫微微小区附着到网络，或者，UE可以基于如上所述的现有信息和机制决定移动进入毫微微小区。

UE可以由毫微微小区运营商、用户或一些其他实体配置为当仅有受限制的紧急服务在毫微微小区中可用时知道是否建立紧急呼叫。当用户尝试建立紧急呼叫时，UE可以决定是使用宏覆盖的RAT特有的机制移动到宏覆盖并建立紧急呼叫，还是保留在毫微微小区中。该决定基于UE配置。如果UE以内部空闲移动性或切换到毫微微小区中来执行TAU或RAU过程，则该决定还可以基于ECSI，其中ECSI由UE接收。

涉及在NAS信令中提供ECSI的第三个子问题是用户选择附着到哪里。在第一场景中，UE可以在选择在附着到毫微微小区之前向用户提供指示。该指示可通过显示指示、声音、震动或任何其他合适的方式提供。该指示传达仅有受限制的紧急服务在给定的H(e)NB中可用，并对受限制的紧急服务的存在性的确定基于从AS获取的ECSI值。

对于在当前UE位置中可用的所有H(e)NB，或仅对于UE允许访问的H(e)NB，UE可以由网络或用户配置以向UE指示这样的信息。无论用户指示接受或拒绝接受UE，用户可以选择能够仅访问受限制的紧急服务是否是可接受的。该指示通过在菜单中选择合适的选项、按下特定的按钮或任何其他合适的方式来执行。UE然后基于用户指示选择附着到毫微微小区还是宏覆盖RAT。是否选择的决定还可以基于现有信息和机制，例如可用H(e)NB信息、现有PLMN和小区选择机制，以及现有小区重选机制。

在涉及用户选择附着到哪里的第二场景中，UE可以检测毫微微小区并确定附着到毫微微小区还是宏覆盖RAT。附着到哪里的决定可以基于现有信息和机制，例如可用H(e)NB信息、现有PLMN和小区选择机制，以及现有小区重选机制。例如，UE可以考虑是否向UE提供NASECSI。当没有执行TAU或RAU过程时，或者当在决定附着到毫微微之前UE没有读取来自于毫微微小区的携带了的ECSIAS SIB广播时，可能出现该提供的缺乏。

涉及在NAS信令中提供ECSI的第四个子问题是用户决定如何建立紧急呼叫。在该实施例中，UE可以在初始附着时选择毫微微小区以附着网络，或者基于如上所述的现有信息和机制决定移动到毫微微小区。

在第一场景中，当UE在向毫微微小区移动时可能已经执行了到毫微微小区的附着过程或TAU或RAU过程。在任一情况中，如果UE从毫微微小区接收到对仅支持受限制的紧急服务进行指示的ECSI，则UE可以向用户提供该指示。该指示可通过显示指示、声音、震动或任何其他合适的方式提供。用户然后可以选择能够仅访问受限制的紧急服务是否是可接受的。用户还可以通过在菜单中选择合适的选项、按下特定的按钮或任何其他合适的机制，向UE指示接受或拒绝。

当用户尝试建立紧急呼叫时，UE决定是使用宏覆盖的RAT特有的机制重选到宏小区并建立紧急呼叫，还是保留在毫微微小区。该决定基于用户指示。

在第二场景中，用户可以尝试在毫微微小区中建立紧急呼叫。在该情况中，如果UE从毫微微小区接收对仅支持受限制的紧急服务进行指示的ECSI，则UE可以向用户提供该指示。该指示可通过显示指示、声音、震动或任何其他合适的机制提供。该指示传达仅有受限制的紧急服务在当前毫微微小区中可用。用户然后可以选择能够仅访问受限制的紧急服务是否是可接受的。用户还可以是通过在菜单中选择合适的选项、按下特定的按钮或任何其他合适的机制，向UE指示接受或拒绝。

基于这样的指示，UE决定是使用宏覆盖的RAT特有的机制移动到宏小区并建立紧急呼叫，还是保留在毫微微小区。该决定基于先前的用户指示

已经描述提供不保证的紧急服务的用于限制紧急服务的第二实施例。注意力现在转移到第三实施例：重定向UE。

在该实施例中，UE可以由毫微微小区运营商、用户或其他实体配置为当紧急服务在毫微微小区中不可用时或仅支持受限制的紧急服务时知道是否在毫微微小区中建立紧急呼叫。即使在毫微微小区中不支持紧急服务，UE也可以被配置为当不存在宏覆盖时知道是否附着到毫微微小区。

当UE附着到毫微微小区或执行毫微微小区的RAU或TAU过程时，UE可以在附着请求消息中或在RA请求或TA请求消息中指示对紧急呼叫支持的需求。下面的两个技术被用于提供对紧急服务的需求的这种指示。首先提供在下面进一步定义的ECRI。ECRI具有以下的值，该值指示需要紧急服务，以及如果在网络中定义了受限制或不被保证的紧急服务，这样的服务对于UE是不充分的。在第二种技术中，如果在网络中定义不被保证的紧急服务，则提供ECRI，ECRI具有以下的值，该值指示至少需要受限制或不被保证的紧急服务，并且常规的紧急服务同样是可接受的。

在一个实施例中，如果毫微微小区支持不被保证的或受限制的紧急服务，并且UE向毫微微小区提供具有指示需要紧急服务的值的ECRI，则毫微微小区返回具有下面任意参数的附着拒绝消息或RA更新/TA更新拒绝消息。第一参数是向UE指示不支持紧急服务的错误代码。例如，可以提供具有指示没有紧急服务可用的值的ECSI。第二参数是向UE指示仅支持受限制的或不被保证的紧急服务的错误代码。例如，可以提供具有指示仅有“受限制紧急服务”的值的ECSI，。其他参数也可以被使用。

如果毫微微小区不支持紧急服务并且UE向毫微微小区提供具有指示紧急服务的值或者具有对至少需要受限制的紧急服务进行指示的值ECRI，则还可以将上述返回的拒绝消息与相关参数一起提供。基于H(e)NB特定信息或其他信息，当UE不提供ECRI时，也可以由eNB发送上述返回的拒绝消息和相关参数。

当从网络接收到不支持紧急服务、受限制紧急服务，或不被保证的紧急服务的响应时，UE可以重选到宏小区。如果在覆盖区域内没有可用的宏小区，则UE可以通过提供对不需要紧急服务进行指示的ECRI，或者通过不提供任何有关紧急服务的特殊指示，重新尝试到毫微微小区的注册。在任一情况中，毫微微小区可以知道UE将接受缺乏有保证的紧急服务。

当从网络接收到不支持紧急服务、受限制紧急服务，或不被保证的紧急服务的响应时，UE检测宏小区并在如果其可用于支持紧急呼叫时进行标识。在一些情况中，即使没有与HPLMN的漫游协议存在，漫游UE可以在PLMN上发起紧急呼叫。如果没有可以支持针对该UE的紧急呼叫的宏小区可用，则UE可以通过提供指示不需要紧急服务的ECRI，或者通过不提供任何有关紧急服务的特殊指示，重新尝试到毫微微小区的注册。

在一个实施例中，UE可以向用户指示或不指示紧急服务的缺乏。用户还可以提供对UE是否应当在宏小区可用时重选到该宏小区的指示，例如在用户建立紧急呼叫时或当宏小区在覆盖区域内被检测时。

当用户尝试建立紧急呼叫时，UE可以决定是否使用宏覆盖的RAT特有的机制重选到宏小区并建立紧急呼叫。该决定可以基于UE配置、用户指示，或一些其他输入。

在上述实施例中呈现了ECSI和ECRI的功能。这些功能可以通过设置一个或多个比特的一个或多个值实现。在一个实施例中，ECSI可以具有4个不同的值和/或消息，虽然其他值或消息也是可能的。ECSI可以指示“不支持紧急服务”，意味着可以在毫微微小区中不支持紧急服务。ECSI可以指示“支持紧急服务”，意味着可以在毫微微小区中支持全部的紧急服务。ECSI还可以指示“仅支持受限制紧急服务”，意味着支持受限制或不被保证的紧急服务。如下面进一步描述的，ECSI还可以指示毫微微小区对于可靠的紧急呼叫过于拥塞。

同样，ECRI可以具有两个不同的值，虽然其他值或消息同样可能。ECRI可以指示“需要紧急服务”，意味着UE可需要不仅是受限制的紧急服务，而是完整的紧急服务。ECRI还可以指示“需要受限制的紧急服务”，意味着UE可至少需要受限制的或不被保证的紧急服务。

上述实施例描述了ECSI的功能。下面是添加到RRC协议规范的SIB1上的ECSI实现的示例。

下面的表格是上述典型的SIB1的SIB1字段描述的示例性集合。不同的SIB和字段描述是可能的，在不同的实施例中，作为强制的或具有特定值的一些参数可以不同。

IV.解决H(e)NB/HNB小区拥塞

已经描述用于解决涉及在H(e)NB/HNB上进行紧急呼叫问题的第三实施例。注意力现在被转移到用于解决涉及H(e)NB/HNB小区拥塞的这些问题的第四种技术上。在毫微微小区拥塞的情况下，UE能够重选到宏小区，不需要通过网络的切换。该重选到宏小区可以在空闲模式或连接模式中执行，并且不需要网络的切换协作。这些实施例可以与之前的紧急服务不可用的实施例结合。

UE可以使用一个或多个不同的技术检测小区拥塞。下面呈现用于检测小区拥塞的五个不同技术，虽然其他也是可以的。这些技术的一个或多个可以在整个或部分中彼此结合。

在第一实施例中，使用上述对应的技术，毫微微小区可以使用对紧急呼叫可用的指示来向UE通知小区拥塞。这样，毫微微小区可以使用隐式指示向UE发送对小区拥塞的指示。

例如，毫微微小区通过向UE提供在毫微微小区中不支持紧急服务的指示来指示拥塞。备选地，UE可以由运营商配置为知道UE是应当驻留具有受限制紧急服务的小区，还是UE应当重选到另一个小区。UE可以由运营商在MO中提供配置信息来配置，和/或UE可以由用户通过用户接口配置。

在涉及小区拥塞检测的第二实施例中，可以由毫微微小区使用上述对应的技术，通过提供对受限制或不被保证的紧急服务的隐式指示来向UE通知小区拥塞。实际指示可以以类似于先前实施例中呈现的方式发送。

在涉及小区拥塞检测的第三实施例中，可以由毫微微小区使用上述对应的技术，通过使用对受限制或不被保证的紧急服务的隐式指示来向UE通知小区拥塞。在该情况中，毫微微小区向UE提供具有指示小区拥塞的特定值的ECSI。UE可以由运营商配置为知道UE是应当驻留在紧急呼叫可能不成功的拥塞毫微微小区中，还是UE应当重选到另一个小区。UE可以由运营商通过在MO中提供配置信息，和/或由用户通过用户接口来配置。

在涉及小区拥塞检测的第四实施例中，以由毫微微小区通过提供对受限制或不被保证的紧急服务的隐式指示来向UE通知小区拥塞。该指示可以由毫微微小区直接在AS级别上被提供，或由SGSN或MME在NAS级别上提供，如果这些组件知道毫微微小区拥塞。该指示可以采用引入到***信息广播中的新字段的形式，以指示毫微微小区的负载级别。

在涉及小区拥塞检测的第五实施例中，UE可以隐式地检测当在毫微微小区上建立的紧急呼叫掉话时的小区拥塞。在该情况中，UE可以自主地重选到另一个小区中，其可以是另一个毫微微小区或相同或不同RAT的宏小区。该实施例可以结合在紧急呼叫期间执行背景搜索使用。这些技术的结合可以被用于优化重选到另一个小区。

现在将阐述隐式小区拥塞通知的特定细节。在一个实施例中，毫微微小区可以使用***信息(例如SIB1)广播来广播小区的负载级别。在E-UTRAN的情况中，SIB可以被使用。被称为“负载级别”的字段可以添加到现有的SIB1或SIB2中以指示负载级别。该字段可以具有任何其他名称，只要该字段指示负载级别级别。可以将示例性的负载级别表述为负载与全部可用资源比的百分比，例如10％、20％、90％、100％或任意其他值。

在另一个实施例中，毫微微小区可以广播指示小区是否拥塞的旗标。该旗标可以在SIB1或SIB2中广播。被称为“拥塞”的一比特字段可以被添加到现有的SIB1和SIB2中，虽然该资源可以具有任意合适的名称。

上述两个实施例中的任一个还可以适用于常规宏小区。上述两个实施例中的任一个还可以适用于其他类型的小区。

上述实施例描述了小区拥塞通知的一些功能和实施例。下面是添加到RRC协议规范中的SIB1的ECCN的实现的示例。

下面的表格式用于上述典型SIB1的SIB1字段描述的示例性集合。

不同的SIB和字段描述是可能的，在不同的实施例中，作为强制或具有特定值被指示的一些参数可以不同。

一些实施例的概述

上述的一些，但不是所有的实施例涉及用于处理当UE进行紧急呼叫时H(e)NB中可靠性问题的四种不同技术。在一个实施例中，紧急呼叫的可靠性由UE在宏小区有利的情况下绕开H(e)NB/HNB小区来保证。在另一个实施例中，UE可以通过H(e)NB/HNB建立紧急呼叫；然而UE可以在通话期间执行背景重选到另一个小区，从而在涉及H(e)NB/HNB故障的情况下可以快速执行呼叫的切换或重建。在另一个实施例中，ECRI可以由UE向网络发送或ECSI可以由网络向UE发送，从而UE可以决定是否使用H(e)NB/HNB建立紧急呼叫。在另一个实施例中，UE可以被通知H(e)NB/HNB中的可能拥塞从而UE可以决定是否使用H(e)NB/HNB建立紧急呼叫。

在所有四个这些实施例中，以及在这里描述的其他实施例中，可以实现特定的新UE附着过程。其他的新过程，例如RAU或TAU过程，也可以实现。注意力现在转移到这些过程。

UE附着过程

当UE发起附着过程时，UE可以或应当包括对UE需要或想要的紧急服务的类型的指示，其可以被提供给网络的上层。该类型指示有保证的服务、不被保证的服务、优先级级别、切换服务请求、针对宏小区的要求，或任何其他如上所述的类型。反过来，网络可以或应当在“附着接受”中包括对支持的紧急服务类型的指示。UE可以或应当向上层提供对支持的紧急服务类型的指示。在一个实施例中，UE可以或应当基于对支持的紧急服务类型的网络指示来选择小区，和/或决定是保持附着到现有小区还是重选到另一个小区。

上述过程还可以参考其他正常的周期性过程实现，无论是附加地、可选择地或者是与上述附着过程结合。例如，当UE发起RAU时，UE可以或应当包括对UE需要的紧急服务类型的指示。网络可以或应当在“RAU更新接受”中包括对支持的紧急服务类型的指示。UE可以或应当向网络组件的上层提供对支持的紧急服务类型的指示。

附着失败

如果由于在毫微微小区中缺乏对紧急服务的支持、或者由于在毫微微小区中缺乏对UE请求的紧急服务支持、或者由于小区对于可靠的紧急服务而言过于拥塞而导致附着过程失败，则拒绝原因可以或应当被设置为对应于“紧急服务在CSG中不可用”的值。在另一个实施例中，如果这些条件满足，则MME可以或应当将附着拒绝消息与ESM消息包含器IE中包含的PDN连接拒绝消息组合。在该情况中，在附着拒绝消息中的EMM原因值可以或应当被设置为例如“紧急服务在CSG中不可用”的值。

如果接收到附着拒绝，UE可以或应当进入“GMM注销”状态。在一个实施例中，如果向UE请求受限制的紧急服务，或者如果UE不请求紧急服务，或者如果小区对于可靠的紧急服务过于拥塞，则UE可以或应当根据3GPP TS43.022和/或3GPP TS25.304搜索合适的小区。UE可以或应当通知上层紧急服务的不可用。如果UE请求完全的紧急服务，则UE可以或应当尝试附着请求受限制的紧急服务。

在另一个实施例中，如果接收到附着拒绝消息，UE可以或应当重设附着尝试计数器并且可以或应当进入EMM注销(deregistered)状态。如果UE请求受限制的紧急服务、不请求紧急服务，或如果小区对于可靠的紧急服务过于拥塞，则UE可以或应当根据3GPP TS36.304搜索合适的小区。UE可以或应当通知上层紧急服务的不可用。如果UE请求完全的紧急服务，则UE可以或应当尝试附着请求受限制的紧急服务。

如果由于在毫微微小区中缺乏对紧急服务的支持、或者由于在毫微微小区中缺乏对UE请求的紧急服务支持、或者由于小区对于可靠地紧急服务而言过于拥塞导致附着请求不能被接受，则拒绝原因可以或应当被设置为指示#XX“紧急服务在CSG中不可用”的值。在该情况中，UE可以或应当根据3GPP TS43.022和/或3GPP TS25.304执行小区选择，并且可以或应当选择合适的子状态。在一个实施例中，UE可以或应当不选择相同的小区。

UE可以或应当随后基于拒绝理由采取下面的行动之一。UE可以或应当进入状态“GMM注销”。如果UE请求受限制的紧急服务、不请求紧急服务，或如果小区对于可靠的紧急服务过于拥塞，则UE可以或应当根据3GPP TS43.022和/或3GPP TS25.304搜索合适的小区。UE可以或应当通知上层紧急服务的不可用。如果UE请求完全的紧急服务，则UE可以或应当尝试附着请求受限制的紧急服务。如果UE因为UE已经在附着过程或路由区过程中接收到对没有紧急服务可用、受限制的紧急服务可用但是受限制的紧急服务不被接受、或小区对于可靠的紧急服务过于拥塞的指示而回到状态“GMM注销”，则UE子状态可以或应当是无紧急服务可用或受限制紧急服务可用之一。如果缺乏紧急服务或紧急服务的受限特性被接受，UE可以或应当进行到“正常服务”。

附着请求消息内容

附着请求消息可以由UE发送给网络以执行GPRS或组合GPRS附着。根据这里描述的附着请求消息的一个示例在下面的表格中被提供。下面呈现的表格中最后的IE可以是紧急服务请求指示。该实施例可以或应当被包括在消息中以指示UE需要或想要的紧急服务类型。

附着请求的另一个示例如下被示出：

最后的IE可以是所请求紧急服务指示。该IE可以或应当被包含在消息中以指示UE需要的紧急服务的类型。

附着接受消息可以由UE发送到网络，以指示已经被接受的对应附着请求。根据这里描述的实施例的附着接受消息的一个示例在下面的表格中被提供。下面呈现的表格中的最后IE可以是紧急服务支持指示。该实施例可以或应当被包括在消息中以指示UE可能需要或想要的紧急服务的类型。

附着接受消息的另一个示例如下：

最后的IE可以是紧急服务支持指示。该IE可以或应当被包括在消息中以指示网络支持的紧急服务的类型。

会话管理过程

可以关于其他正常的周期性会话管理过程来实现类似于上述这些的过程。这样的过程的一个示例可以是请求PDP上下文激活。

例如，在一个实施例中，当UE发起UE请求的PDP上下文激活时，UE可以或应当包括指示UE需要或想要的紧急服务的类型。继而，网络可以或应当在激活PDP上下文接受中包括对支持的紧急服务类型的指示。UE可以或应当向上层提供对支持的紧急服务类型的指示。

如果由于在毫微微小区中缺乏对紧急服务的支持、由于在毫微微小区中缺乏对UE请求的紧急服务的支持，或者由于小区对于可靠的紧急呼叫过于拥塞导致PDP上下文激活过程失败，则激活PDP上下文拒绝消息中GMM原因值可以或应当被设置为对应于“CSG中紧急服务不可用”的值。该消息可以或应当包含指示下列原因的原因代码。UE可以或应当重设附着尝试计数器并且可以或应当进入GMM注销状态。如果UE请求受限制的紧急服务、不请求紧急服务、或小区对于可靠的紧急呼叫过于拥塞，则UE可以或应当根据3GPP TS36.304搜索在相同PLMN中的合适小区。

UE可以或应当通知上层紧急服务的不可用性。如果UE请求完全的紧急服务，则UE可以或应当通过请求受限制的紧急服务来尝试TAU过程。

激活PDP上下文请求消息可以由UE发送给网络以请求PDP上下文的激活。根据这里描述的实施例的PDP上下文请求消息的一个示例在下面的表格中被提供。下面呈现的表格中最后IE可以是所请求紧急服务指示。该实施例可以或应当被包括在消息中以指示UE需要的紧急服务类型。

激活的PDP上下文接受消息可以由网络发送给UE以对PDP上下文的激活进行肯定应答。根据这里描述的实施例的PDP上下文请求消息的一个示例在下面的表格中被提供。下面呈现的表格中最后的IE可以是所支持紧急服务指示。该实施例可以或应当被包括在消息中以指示PDP上下文支持的紧急服务类型。

正常的周期性会话管理过程的另一个示例是UE请求的PDN连接性过程。如果这样的过程被网络接受，则在接收PDN连接性请求消息时，MME可以检查是否包括ESM信息传送旗标。网络可以或应当在激活缺省EPS承载上下文请求中包括对支持的紧急服务类型的指示。UE可以或应当向上层提供对支持的紧急服务类型的指示。

如果所请求的PDN的连接性不被网络接受，则MME可以或应当向UE发送PDN连接性拒绝消息。如果由于在毫微微小区中缺乏对紧急服务的支持、由于在毫微微小区中缺乏对UE请求的紧急服务的支持，或者由于小区对于可靠的紧急呼叫过于拥塞导致所请求的PDN连接性过程失败，则PDN连接性拒绝消息中的EMM原因值可以或应当被设置为指示#XX“CSG中紧急服务不可用”的值。

在一个实施例中，UE可以或应当进入ESM状态“承载上下文激活”。如果UE请求受限制的紧急服务、不请求紧急服务或小区对于可靠的紧急呼叫过于拥塞，则UE可以或应当根据3GPP TS36.304搜索在相同PLMN中的合适小区。UE可以或应当通知上层紧急服务的不可用性。如果UE请求完全的紧急服务，则UE可以或应当通过请求受限制紧急服务来尝试与所请求的PDN的连接性。

PDN连接性请求的一个示例在下面的表格中被呈现。该消息可以由UE发送给网络以发起PDN连接的建立。

最后IE可以是所请求紧急服务指示的示例。该IE可以或应当被包括在消息中以指示UE需要的紧急服务类型。

激活专用EPS承载上下文请求消息的示例在下面的表格中被提供。该消息可以由网络向UE发送，以请求激活与相同PDN地址相关联的专用EPS承载上下文的激活以及请求作为已经激活的缺省EPS承载上下文的APN。

最后的IE可以是所支持紧急服务指示。该IE可以或应当被包括在消息中以指示PDN连接支持的紧急服务类型。

正常的周期性会话管理过程的另一个示例是RAU过程。RAU请求消息可以由UE发送给网络，以请求UE位置文件的更新或请求用于非GPRS服务的IMSI附着。根据这里描述的实施例RAU请求消息的一个示例在下面的表格中被提供。下面呈现的表格中最后的IE可以是所请求紧急服务指示。该IE可以或应当被包括在消息中以指示UE需要的紧急服务类型。

响应于RAU请求消息，可以由网络向UE发送RAU接受消息，以向UE提供GPRS移动性管理有关的数据。根据这里描述的实施例的RAU接受请求消息的示例在下面的表格中被提供。下面呈现的表格中最后的IE是所支持紧急服务指示。该实施例可以或应当被包括在消息中以指示支持的紧急服务类型。

正常的周期性会话管理过程的另一个示例是TAU。如果TAU请求已经被网络接受，则MME可以或应当向UE发送跟踪区更新接受消息。在一个实施例中，网络可以或应当在跟踪区更新接受消息中包括对支持的紧急服务类型的指示。UE可以或应当向上层提供对支持的紧急服务类型的指示。

如果TAU过程，或组合TAU过程不被网络接受，则MME可以或应当向UE发送跟踪区更新拒绝消息，其中包括合适的EMM原因值。如果由于在毫微微小区中缺乏对紧急服务的支持、由于在毫微微小区中缺乏对UE请求的紧急服务的支持，或者由于小区对于可靠的紧急呼叫过于拥塞导致跟踪区更新失败，则跟踪区更新拒绝消息中的EMM原因值可以或应当被设置为指示#XX“CSG中紧急服务不可用”的值。

在该情况中，UE可以或应当重设附着尝试计数器并且可以或应当进入EMM注销状态。如果UE请求受限制的紧急服务、不请求紧急服务或小区对于可靠的紧急呼叫过于拥塞，则UE可以或应当根据3GPPTS36.304搜索在相同PLMN中的合适小区。UE可以或应当通知上层紧急服务的不可用性。如果UE请求完全的紧急服务，则UE可以或应当通过请求受限制紧急服务来尝试TAU过程。

TAU请求消息的一个示例如下：

最后的IE可以是所请求紧急服务指示。该IE可以或应当被包括在消息中以指示UE需要的紧急服务类型。

另一个被发送的消息是TAU接受消息。响应于跟踪区更新请求消息，该消息可以由网络向UE发送，以向UE提供EPS移动性管理相关数据。下面的表格显示出TAU接受消息的示例。

最后IE可以是所支持紧急服务指示。该IE可以或应当被包括在消息中以指示UE需要的紧急服务类型。

支持的紧急服务类型

上述关于附着和会话管理过程的实施例提供具有不同的支持的紧急服务类型IE。现在描述一些不同的所支持的紧急服务类型。

在一个实施例中，上述的所需要紧急服务类型信息单元可以向网络提供与用户设备请求的服务有关的信息。所需紧急服务类型信息单元可以如下面的表格所示进行编码。

所需紧急服务类型可以是具有最小长度为3个八位字节的类型4信息单元。下面的表格显示了典型的D.E.F.所需紧急服务类型实施例。

下面的表格显示了示例性的G.H.I.所需紧急服务类型实施例。

下面提供了示例性的、非限制性的A.B.C.E所支持紧急服务类型。所支持紧急服务类型信息单元可以如下面的表格中所示被编码。所支持紧急服务类型可以是具有最小长度为三个八位字节的类型4信息单元。下面显示的第一个表格式D.E.F.支持的紧急服务类型IE的一个非限制性的示例。

下面的表格是G.H.I.所支持紧急服务类型IE的非限制性的示例。

UE状态

上述关于附着和会话管理过程的实施例提及了不同的状态，例如GMM注销状态。下面的实施例描述GMM注销子状态。

在一个实施例中，GMM注销子状态可以是“GMM注销.无可用紧急服务”状态。如果UE知道其所选择的小区不能够提供紧急服务，则UE可以或应当进入该子状态。例如，在GMM注销状态中的UE可能已经在附着过程或路由区过程中接收对没有紧急服务可用、受限制的紧急服务可用但受限制的紧急服务不被接受或小区对于可靠的紧急呼叫过于拥塞的指示。UE可以在MS搜索其他小区期间进入上述子状态。

除了GMM注销状态，UE还可以进入GMM注册状态。下面是GMM注册状态的示例。这些子状态可以属于整个UE，如果没有SIM/USIM***则仅属于ME，或者属于加上SIM/USIM的ME。

第一典型的子状态可以是“GMM注册.没有紧急服务可用子状态”。如果附着或RAU过程指示没有紧急服务可用或者小区对于可靠的紧急呼叫过于拥塞，该子状态可以被UE选择。如果可接受紧急服务的缺乏，UE可以或应当重选到相同或不同RAT的另一个小区或者移动到“GMM注册.普通服务”子状态。如果UE决定重选，UE可以或应当不发起任何EMM过程，除了小区和PLMN重选。在一个实施例中，不可以或应当发送或接收数据。

第二典型的子状态可以是“GMM注册.限制紧急服务可用”子状态。如果附着或RAU过程指示仅有受限制的紧急服务可用，该子状态可以被UE选择。如果受限制的紧急服务不被接受，UE可以或应当重选到相同或不同RAT的另一个小区。如果限制的紧急服务被接受，UE可以或应当移动到“GMM注册.普通服务”子状态。如果UE决定重选，UE可以或应当不发起任何EMM过程，除了小区和PLMN重选。在一个实施例中，不可以或应当被发送或接收数据。

除了GMM状态，另一个UE可能经历的状态改变是从一个状态到MM空闲状态。当返回MM空闲时，例如在位置更新过程之后，UE可以选择在3GPP TS43.022和3GPP TS25.304中规定的小区。如果回到空闲状态不在以接收原因“不允许在该位置区中漫游”终结的位置更新过程之后，则服务状态可以基于小区选择过程的结果、基于移动站的更新状态、基于存储在移动站中的位置数据，和/或基于SIM/USIM的存在。

当返回MM空闲状态时，如果没有找到小区，则服务状态可以是没有小区可用，直到找到一个小区。如果没有SIM/USIM存在，或如果***的SIM/USIM被UE认为是无效的，则服务状态可以是没有IMSI。

同样当返回MM空闲时，如果因为UE在附着过程或跟踪区过程或组合跟踪区过程中接收到对没有紧急服务可用、或受限制紧急服务可用但受限制紧急服务不被接受，或小区对于可靠的紧急呼叫过于拥塞的指示，UE从GMM注册状态回到GMM注销状态，则子状态可以是没有紧急服务可用。如果选择的小区不支持紧急服务、或其支持受限制的紧急服务但受限制紧急服务不被接受，子状态可以是没有紧急服务可用。

另一个UE状态可以是EMM注销状态。可以在一个或多个条件被触发时进入该状态。呈现了这种触发的两个非限制性示例。一个这样的触发是当附着请求被MME接受但是MME指示没有紧急服务可用、受限制的紧急服务可用但受限制的紧急服务不被接受，或者小区对于可靠的紧急呼叫过于拥塞。另一个这样的触发是当TAU请求被MME接受但是MME指示没有紧急服务可用、受限制的紧急服务可用但受限制的紧急服务不被接受，或者小区对于可靠的紧急呼叫过于拥塞。基于进入EMM注销状态，UE可以或应当根据3GPP TS36.304执行小区选择，并且当找到小区时选择合适的子状态。UE可以或应当不选择相同的小区。UE可以或应当不支持紧急承载服务的附着。

EMM注销状态可以被细分为多个子状态。在UE进入子状态(除了“EMM注销.没有IMSI”子状态)之前，有效的用户数据可以用于UE。

EMM注销状态的子状态的一个示例是“EMM注销.没有可用的紧急服务”子状态。如果EPS更新状态是EU1并且其知道选择的小区在UE搜索其他小区期间不能够提供紧急服务，可以在UE中选择该子状态。可以知道所选择的小区在处于EMM注册状态的UE已经在附着过程、跟踪区过程或组合跟踪区过程中接收到对没有紧急服务可用、或受限制紧急服务可用但受限制紧急服务不被接受，或小区对于可靠的紧急呼叫过于拥塞的指示时，不能够提供紧急服务。

另一个UE状态可以是EMM注册状态。该状态也可以被细分为多个子状态。

EMM注册子状态的一个示例是“EMM注册.没有紧急服务可用”子状态。如果附着或RAU过程指示没有紧急服务可用或者小区对于可靠的紧急呼叫过于拥塞，该子状态可以被UE选择。在该情况中，UE可以或应当重选到另一个小区或者移动到“GMM注销.没有紧急服务可用”子状态。如果UE决定重选，UE可以或应当不发起任何EMM过程，除了小区和PLMN重选。没有数据可以或应当被发送或接收。如果紧急服务的缺乏被接受，UE可以或应当移动到“EMM注册.普通服务”子状态中。

EMM注册子状态的另一个示例是“EMM注册.受限制紧急服务可用”子状态。如果附着或RAU过程指示仅受限制制的紧急服务可用，该子状态可以被UE选择。如果受限制的紧急服务不被接受，UE可以或应当重选到另一个小区或者移动到“EMM注销.没有紧急服务可用”。如果UE决定重选，UE可以或应当不发起任何EMM过程，除了小区和PLMN重选。没有数据可以或应当被发送或接收。如果受限制的紧急服务被接受，UE可以或应当移动到“EMM注册.普通服务”子状态中。

在一些情况中，UE可以从EMM状态回到EMM注销状态。当回到EMM注销状态时，UE可以或应当选择在3GPP TS36.304中规定的小区。该子状态可以基于小区选择过程的结果、先前执行的EMM特定过程的结果、基于UE的EPS更新状态、基于存储在UE中的跟踪区数据以及基于USIM的存在，或基于一些因素中的任意一个。在一个示例性的非限制性实施例中，如果因为UE已经在附着过程、跟踪区过程，或组合跟踪区过程中接收到对没有紧急服务可用、受限制紧急服务可用但受限制紧急服务不被接受或小区对于可靠的紧急呼叫过于拥塞的指示而导致UE回到EMM注销状态，则该子状态可以或应当是无紧急服务可用。

对EMM注册状态下的UE行为的描述

在无紧急服务可用子状态中，如果紧急服务的缺乏不被接受则UE可以或应当根据3GPP TS36.304来执行小区选择或重选。如果紧急服务的缺乏被接受，则UE可以或应当去往普通服务状态。

在受限制紧急服务可用子状态中，如果受限制的紧急服务不被接受则UE可以或应当根据3GPP TS36.304执行小区选择或重选。如果受限制的紧急服务被接受，则UE可以或应当去往普通服务状态。

图6是根据本发明实施例的在UE中发起紧急呼叫的过程的流程图。图6中示出的过程可以由处理器和其他组件，如在图11中示出的那些组件来实现。图6中示出的过程可以根据参考图1到图5描述的技术和设备，并参考上述在其他地方描述的实施例实现。

当UE中的通话控制实体为了进行紧急呼叫，通过请求RCC连接来发起移动起始呼叫时，该过程开始(步骤600)。UE的RRC层可以确定该请求用于紧急呼叫，并且还确定UE驻留在家庭增强型NodeB(H(e)NB)小区或家庭NodeB(HNB)小区中的一个上(步骤602)。RRC层可以发起重选到不同的、非毫微微小区(步骤604)。最后，RRC层可以执行RRC连接建立过程(步骤606)。

图7是根据本发明的实施例，准备重选到宏小区的过程的流程图。图7中示出的过程可以由处理器和其他组件，如在图11中示出的那些组件实现。图7中示出的过程可以根据参考图1到图5描述的技术和设备，并参考上述在别处描述的实施例实现。

该过程由响应于UE在毫微微小区中的一个上进行紧急呼叫，UE准备重选到宏小区而开始(步骤700)。在UE准备重选期间，UE继续紧急呼叫(步骤702)。准备重选包括如这里其他地方描述的扫描可用的宏小区或微小区。该过程随后终止。

图8是根据本发明的实施例，指示紧急服务支持的过程的流程图。图8中示出的过程可以由处理器和其他组件，如在图11中示出的那些组件实现。图8中示出的过程可以根据参考图1到图5描述的技术和设备，并参考上述在别处描述的实施例实现。

该过程由UE接收ECSI(步骤800)开始。然后，UE可以基于ECSI值尝试附着到可用的毫微微小区(步骤802)。该过程随后终止。

图9是根据本发明的实施例，指示紧急呼叫支持过程的流程图。图9中示出的过程可以由处理器和其他组件，如在图11中示出的那些组件实现。图9中示出的过程可以根据参考图1到图5描述的技术和设备，并参考上述在别处描述的实施例实现。

该过程由网络组件发送ECSI(步骤900)开始。然后网络组件可以发送消息，该消息被配置为在UE进行紧急呼叫时指示UE连接到毫微微小区(步骤902)。该过程随后终止。

图10是根据本发明的实施例，确定是否进行紧急呼叫过程的流程图。图10中示出的过程可以由处理器和其他组件，如在图11中示出的那些组件实现。图10中示出的过程可以根据参考图1到图5描述的技术和设备，并参考上述在别处描述的实施例实现。

该过程由UE接收毫微微小区之一拥塞的指示开始(步骤1000)。响应于接收该指示，UE可以确定是否在毫微微小区之一上进行紧急呼叫(步骤1002)。该过程随后终止。

上述的UE和其他组件可以包括单独或组合的组件，该组件能够执行指令或者能够提升上述动作的出现。图11示出了***1100的示例，***600包括适用于实现在此公开的一个或多个实施例的处理组件，例如处理器1110。除了处理器1110(可以将其称作中央处理单元或CPU)之外，***1100可以包括网络连接设备1120、随机存取存储器(RAM)1130、只读存储器(ROM)1140、辅助存储器1150、以及输入/输出(I/O)设备1160。这些组件可以经由总线1100彼此通信。在一些情况下，这些组件中的一些可以不存在，或可以通过彼此间的各种组合或与图中未示出的其他组件的各种组合的方式来进行组合。这些组件可以位于单个物理实体中，或者可以位于一个以上的物理实体中。本文中描述为由处理器1110进行的任何动作可以由处理器1110单独进行，或者由处理器1110结合图中示出或者未示出的一个或多个组件进行，例如数字信号处理器(DSP)1180。虽然DSP 1180被示出为单独的组件，然而可以将DSP 1180并入到处理器1110中。

处理器1110执行其可以从网络连接设备1120、RAM 1130、ROM1140或辅助存储器1150(其可以包括各种基于盘的***，例如硬盘、软盘或光盘)存取的指令、代码、计算机程序或者脚本。虽然仅示出了一个CPU 1110，然而可以存在多个处理器。因此，尽管可以将指令讨论为由处理器执行，但是指令可以由一个或多个处理器同时地、串行地、或以其他方式执行。可以将处理器1110实现为一个或多个CPU芯片。

网络连接设备1120可以采用以下形式：调制解调器、调制解调器组、以太网设备、通用串行总线(USB)接口设备、串行接口、令牌环设备、光纤分布式数据接口(FDDI)设备、无线局域网(WLAN)设备、射频收发信机设备(例如，码分多址(CDMA)设备)、全球移动通信***(GSM)无线收发信机设备、微波接入的全球可互操作性(WiMAX)设备、和/或其他众所周知的用于连接网络的设备。这些网络连接设备1120可以使得处理器1110能够与互联网或者一个或多个电信网络通信，或者与处理器1110可以从其接收信息或处理器1110可以向其输出信息的其他网络通信。网络连接设备1120还可以包括能够无线发送和/或接收数据的一个或多个收发信机组件1125。

RAM 1130可以用于存储易失性数据并且可能用于存储由处理器1110执行的指令。ROM 1140是存储器容量通常比辅助存储器1150的存储器容量的更小的非易失性存储器设备。ROM 1140可以用于存储指令以及存储可能在指令执行期间读取的数据。对RAM 1130和ROM 1140的访问通常快于对辅助存储器1150的访问。辅助存储器1150通常包括一个或者多个盘驱动或者带驱动，并且可以用于数据的非易失性存储，或者如果RAM 1130不够大到足以保存所有工作数据时，还要将辅助存储器650用作溢出数据存储设备。辅助存储器1150可以用于存储程序，当选择执行该程序时将该程序加载至RAM 1130。

I/O设备1160可以包括液晶显示器(LCD)、触摸屏显示器、键盘、键区、开关、拨号盘、鼠标、轨迹球、语音识别器、读卡器、纸带读取器、打印机、视频监视器、或者其它众所周知的输入/输出设备。同样地，替代作为网络连接设备1125的组件或者除了作为网络连接设备1120的组件之外，可以将收发信机725视为I/O设备1160的组件。

这样，该实施例提供了包括一个或多个处理器的UE，该处理器被配置为：当UE在毫微微小区中或在毫微微小区中驻留时，响应于UE进行紧急呼叫而使UE重选到宏小区。

实施例还提供了一种方法，用于在用户设备(UE)中发起紧急呼叫。通话控制实体通过请求指示目的在于发起紧急呼叫的连接来发起移动初始呼叫。确定所述请求用于紧急呼叫，以及还确定UE在毫微微小区上驻留。UE发起到不同的非毫微微小区的重选。UE执行连接建立过程。

实施例还提供了一种用户设备(UE)，包括一个或多个处理器，被配置为：响应于UE在毫微微小区中进行紧急呼叫而使UE准备重选到宏小区，其中准备重选在紧急呼叫之外执行。

实施例还提供了一种用户设备(UE)，包括一个或多个处理器，被配置为接收毫微微小区拥塞的指示，并且响应于接收该指示，确定是否在毫微微小区上进行紧急呼叫。

虽然已经在本发明中提供了一些实施例，然而应当理解的是该公开的***和方法可以以多种不同的特定形式，在不脱离本发明精神或范围的情况下被实现。本示例被认为是示例性的并且不限制的，以及本发明不被限制在这里给出的细节中。例如，多种元素或组件可以结合或者集成到另一个***中或特定特征可以被省略或不实现。

同样，在多个实施例中分离或独立地被描述和阐述的技术、***、子***和方法可以与其他***、模块、技术或方法在不脱离本发明精神的情况下结合或集成。连接或直接连接或与彼此通信被示出或讨论的其他项目可以间接连接或通过一些接口、设备，或中间组件电子地、机械地等方式通信。改变、替代和变形的其他示例由本领域熟练技术人员可确定并且可以在不脱离这里描述的精神和范围之内被作出。

Claims (34)

1.一种用户设备(UE)，包括：

一个或多个处理器，被配置为：当UE在毫微微小区中，或者当UE在毫微微小区上驻留时，响应于UE进行紧急呼叫，使UE重选到宏小区。

2.根据权利要求1所述的UE，其中，所述处理器还被配置为通过使用接入层“AS”使UE进行重选。

3.根据权利要求1所述的UE，其中，UE中的移动性管理实体“MME”向UE中的无线资源控制“RRC”层传递发起紧急呼叫的请求，以及RRC层执行重选。

4.根据权利要求1所述的UE，其中，根据重选算法执行重选，服务小区的信号质量被认为比阈值低，包括S_serving＜Thresh_serving。

5.一种在用户设备“UE”中发起紧急呼叫的方法，所述方法包括：

通过请求指示目的在于发起紧急呼叫的连接来发起移动初始呼叫；

确定所述请求用于紧急呼叫，以及还确定UE在毫微微小区上驻留；

发起到不同的非毫微微小区的重选；以及

执行连接建立过程。

6.根据权利要求5所述的方法，其中，发起重选是根据重选算法执行的，其中服务小区的信号质量被认为比阈值低，包括S_serving＜Thresh_serving。

7.根据权利要求6所述的方法，其中，已知服务小区在专用于一个毫微微小区的频率上，以及UE避免频率内重选，并像没有向所述频率指派优先级一样进行操作。

8.根据权利要求5所述的方法，其中，重选到与毫微微小区所连接的公共陆地移动网络“PLMN”不同的PLMN。

9.根据权利要求5所述的方法，其中，UE以不允许自主重选的模式驻留在毫微微小区中。

10.根据权利要求9所述的方法，还包括：

在执行重选之前释放正在进行的连接。

11.根据权利要求9所述的方法，还包括：

向网络组件发送目标小区和请求切换的指示。

12.根据权利要求11所述的方法，还包括：

处理器还使UE调谐到非服务小区的广播信道，并接收广播***信息。

13.根据权利要求12所述的方法，还包括：

响应于从非服务小区接收到该非服务小区可靠支持紧急服务的指示，向服务小区发送指示至少以下之一的消息：

允许服务小区发起向非服务小区的切换准备的充分的标识信息；

测量信息；以及

需要切换以进行紧急呼叫的指示。

14.根据权利要求5所述的方法，还包括丢弃除了紧急服务之外的其他服务。

15.根据权利要求5所述的方法，其中，当互联网协议多媒体子***(IMS)应用请求紧急承载时，触发到宏小区的重选。

16.根据权利要求5所述的方法，其中，当互联网协议多媒体子***“IMS”应用尝试生成紧急呼叫时，建立紧急承载以支持用于IMS紧急呼叫的互联网协议业务。

17.根据权利要求5所述的方法，其中，存储器管理实体“MME”知道毫微微小区连接性。

18.根据权利要求5所述的方法，还包括：

接收公共陆地移动网络“PLMN”标识符“ID”的集合，所述PLMNID标识UE能够在其中建立紧急呼叫的那些毫微微小区，以及重选还包括仅向所述集合中的小区进行重选。

19.根据权利要求18所述的方法，其中，以设备管理对象的形式接收所述集合。

20.根据权利要求18所述的方法，还包括：

建立具有闭合订户组紧急支持的公共陆地移动网络的本地列表。

21.一种用户设备“UE”，包括：

一个或多个处理器，被配置为接收毫微微小区拥塞的指示，并且响应于接收到所述指示，确定是否在毫微微小区上进行紧急呼叫。

22.根据权利要求21所述的UE，其中，所述处理器还被配置为：如果所述指示是毫微微小区拥塞，避免进行紧急呼叫。

23.根据权利要求21所述的UE，其中，所述指示是从毫微微小区接收的，以及UE还被配置为：确定UE是应当驻留在限制紧急服务的小区，还是UE应当重选到另一个小区。

24.根据权利要求21所述的UE，其中，所述指示是以紧急呼叫服务指示符“ECSI”的形式接收的。

25.根据权利要求21所述的UE，其中，所述指示是以独立于紧急呼叫支持的形式接收的，以及所述指示是以接入层“AS”级别和非接入层“NAS”级别之一提供的。

26.根据权利要求21所述的UE，其中，所述指示是以独立于紧急呼叫支持的形式接收的，以及所述指示是在UE所接收的***信息块“SIB”的字段中提供的。

27.根据权利要求21所述的UE，其中，所述指示采用当毫微微小区是服务设备时丢弃紧急呼叫的形式，以及所述处理器还被配置为：响应于丢弃的紧急呼叫，使UE重选到另一小区。

28.一种在用户设备“UE”中实现的方法，用于确定是否进行紧急呼叫，所述方法包括：

接收毫微微小区拥塞的指示；以及

响应于接收到所述指示，确定是否在毫微微小区上进行紧急呼叫。

29.根据权利要求28所述的方法，还包括：

如果所述指示是毫微微小区拥塞，避免进行紧急呼叫。

30.根据权利要求28所述的方法，其中，所述指示是从毫微微小区接收的，以及所述方法还包括：

确定UE是应当驻留在限制紧急服务的小区中，还是UE应当重选到另一小区。

31.根据权利要求28所述的方法，其中，所述指示是以紧急呼叫服务指示符“ECSI”的形式接收的。

32.根据权利要求28所述的方法，其中，所述指示是以独立于紧急呼叫支持的形式接收的，以及所述方法还包括：

以接入层“AS”级别和非接入层“NAS”级别之一提供所述指示。

33.根据权利要求28所述的方法，其中，所述指示是以独立于紧急呼叫支持的形式接收的，以及所述方法还包括：

在UE所接收的***信息块“SIB”的字段中提供所述指示。

34.根据权利要求28所述的UE，其中，所述指示采用当毫微微小区是服务设备时丢弃紧急呼叫的形式，以及所述方法还包括：

响应于丢弃的紧急呼叫，使UE重选到另一小区。

Images