CN112740824B - 恢复请求随后释放和重定向 - Google Patents

恢复请求随后释放和重定向 Download PDF

Info

Publication number
CN112740824B
CN112740824B CN201980062426.0A CN201980062426A CN112740824B CN 112740824 B CN112740824 B CN 112740824B CN 201980062426 A CN201980062426 A CN 201980062426A CN 112740824 B CN112740824 B CN 112740824B
Authority
CN
China
Prior art keywords
rrc
base station
network
release
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201980062426.0A
Other languages
English (en)
Other versions
CN112740824A (zh
Inventor
艾卡罗·L·J·达席尔瓦
奥斯卡·奥尔松
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN112740824A publication Critical patent/CN112740824A/zh
Application granted granted Critical
Publication of CN112740824B publication Critical patent/CN112740824B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/04—Reselecting a cell layer in multi-layered cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本文提供了用于恢复请求随后释放和重定向的方法和系统。根据一个方面，一种由用户设备执行的用于在电信网络内进行通信的方法，包括：当在无线电资源控制(RRC)非活动状态下时，向基站发送用于恢复通信的请求，并且在没有进入RRC连接状态的情况下，从基站接收用于释放和重定向的指令；以及响应于接收到用于释放和重定向的指令，以无线电接入技术执行小区选择，并且尝试建立或恢复与所选择的小区的通信。

Description

恢复请求随后释放和重定向
相关申请的交叉引用
本申请要求于2018年9月25日提交的临时专利申请序列号62/736,332的权益，该申请的公开内容通过引用整体并入本文。
技术领域
本申请涉及用于以消除用户设备(UE)首先进入连接模式的需要的方式来处理恢复请求随后释放和重定向的方法和系统。
背景技术
长期演进(LTE)在无线电资源控制(RRC)状态和连接管理(CM)状态方面对用户设备(UE)的状态进行了定义。
在RRC_IDLE(RRC_空闲)状态下，UE对于演进分组核心(EPS)是已知的，并且具有网际协议(IP)地址，但是对于特定基站(例如，演进或增强型节点B(eNB))则是未知的。
在RRC_CONNECTED(RRC_连接)状态下，UE对于EPC和eNB二者是已知的。
在CM-IDLE(CM-空闲)状态下，UE与网络之间不存在非接入层(NAS)信令连接。eNB中没有针对UE的上下文。UE未连接到移动性管理实体(MME)。
在CM-CONNECTED(CM-连接)状态下，存在NAS信令连接，并且UE位置对于MME是已知的，MME协调切换和其他与移动性相关的过程。
如本文所使用的，在RRC_IDLE状态下的UE可以被称为“RRC_IDLE UE”，在RRC_CONNECTED状态下的UE可以被称为“RRC_CONNECTED UE”等。
LTE-挂起和恢复
在LTE版本13(Rel-13)中，引入了一种机制，用于由网络将UE挂起在类似于RRC_IDLE的挂起状态，但是区别在于UE存储接入层(AS)上下文或RRC上下文。这使得有可能在UE再次变得活动时通过恢复RRC连接、而不是如先前从头开始建立RRC连接，来减少信令。减少信令可以具有若干益处，例如减少时延(例如，针对智能电话接入互联网)、和/或减少的电池消耗(尤其针对发送很少数据的机器类型设备)。Rel-13解决方案描述了一种过程，其中UE向网络发送RRC连接恢复请求(RRCConnectionResumeRequest)消息，并作为响应从网络接收RRC连接恢复(RRCConnectionResume)。RRC连接恢复未被加密，但受到完整性保护。
NR-RRC_INACTIVE(RRC非活动)
在LTE版本15(Rel-15)(也称为增强型LTE(eLTE)或连接到第五代(5G)核心网络(NGC)的LTE)中和在新无线电(NR)中，作为第三代合作伙伴计划(3GPP)中有关5G NR的标准化工作的一部分，已经决定NR应支持具有与LTE Rel-13中的挂起状态类似属性的RRC_INACTIVE状态。RRC_INACTIVE与LTE状态的属性略有不同，因为它是单独的RRC状态，而不是像在LTE中是RRC_IDLE的一部分。此外，在核心网络(CN)/无线电接入网(RAN)连接(NG或N2接口)在LTE中被挂起时，它被保持为RRC_INACTIVE。
图1示出了UE状态机以及NR中的RRC状态之间的可能状态转变。图1中的状态的属性如下：
RRC_IDLE。UE特定的不连续接收(DRX)可以由上层配置；UE基于网络配置来控制移动性。UE针对使用5G系统架构演进(SAE)临时移动订户标识(5G-S-TMSI)的CN寻呼来监视寻呼信道，执行相邻小区测量和小区(重新)选择，并获取系统信息。
RRC_INACTIVE。UE特定的DRX可以由上层或RRC层配置。UE基于网络配置来控制移动性。UE存储接入层(AS)上下文。UE针对使用5G-S-TMSI的CN寻呼和使用非活动无线电网络临时标识符(I-RNTI)的RAN寻呼来监视寻呼信道，执行相邻小区测量和小区(重新)选择，周期性以及在移出基于RAN的通知区域时执行基于RAN的通知区域更新，并获取系统信息。
RRC_CONNECTED。UE存储AS上下文。去往/来自UE的单播数据的传输发生。在下层，UE可以被配置有UE特定的DRX。对于支持载波聚合(CA)的UE，为了增加的带宽，可以将一个或多个辅小区(SCell)与特殊小区(SpCell)或主小区(PCell)聚合。对于支持双连接(DC)的UE，为了增加的带宽，可以将一个辅小区组(SCG)与主小区组(MCG)聚合。支持网络控制的移动性，即，在NR内的切换以及向/自演进的通用陆地无线电接入(E-UTRAN)的切换。UE监视寻呼信道，监视与共享数据信道相关联的控制信道以确定是否针对其调度了数据，提供信道质量和反馈信息，执行相邻小区测量和测量报告，以及获取系统信息。
图1示出了RRC_IDLE、RRC_CONNECTED和RRC_INACTIVE状态之间可能的状态转变。在图1中，这些转变如下：
状态转变102“释放[和重定向]”被这样命名，是因为可以在有或没有被重定向到另一个频率或无线电接入技术(RAT)的情况下释放UE。
释放和重定向特征
在LTE中，根据3GPP技术规范(TS)36.331，释放和重定向特征用于将RRC_CONNECTED UE释放到RRC_IDLE，并将它重定向到相同RAT或不同RAT中的另一个频率。在下文中，除非另有说明，否则TS被假定为3GPP TS。
在柏林的3GPP无线电接入网层2(RAN2)工作组会议RAN2#99期间，“释放和重定向”和“在释放后小区重选优先级”(在LTE中称为移动性控制信息)功能针对NR达成一致：
协议11：已达成一致，RRC连接释放类型的消息可以包括原因信息、重定向载波频率和空闲模式移动性控制信息。
协议27：已达成一致，对于CONNECTED(连接)到INACTIVE(非活动)RRC转变，RRC连接释放类型的消息包括(a)与协议11中列出的信息相同的信息(即，原因信息、重定向载波频率和移动性控制信息)，并且可以包括(b)UE标识(或UE上下文标识)，以及可选的(c)挂起/非活动指示(FFS隐式还是显式)，(d)RAN配置的DRX周期，(e)RAN周期性通知定时器，以及(f)RAN通知区域。
这些提议已在RRC规范(TS 38.331)和空闲/非活动模式(TS38.304)规范中具体说明。在RRC(TS38.331)中，RRC释放(RRCRelease)消息用于将UE从RRC_CONNECTED移到RRC_IDLE或从RRC_CONNECTED移到RRC_INACTIVE。然后，当RRC释放消息中包括字段重定向载波信息(redirectedCarrierInfo)时，将激活释放和重定向特征。以下再现了来自TS 38.331的摘录，其中相关的补充以粗体示出。
[开始摘录自RRC TS38.331]
RRC释放消息
[结束摘录自RRC 38.331]
根据TS 38.304，规定了在接收到字段redirectedCarrierInfo后，以下UE行为：
在从RRC_CONNECTED转变到RRC_IDLE状态或RRC_INACTIVE状态时，如果redirectedCarrierInfo被包括在用于该转变的RRC消息中，则UE应尝试根据redirectedCarrierInfo驻留在合适的小区(即，具有指定载波频率的小区)上。如果UE找不到合适的小区，则允许UE驻留在指示的RAT的任何合适的小区上。如果RRC释放消息不包含redirectedCarrierInfo，则UE应尝试在NR载波上选择合适的小区。如果根据上述未找到合适的小区，则UE应使用存储的信息执行小区选择，以便找到要驻留的合适的小区。
在UE从驻留在任何小区状态移到RRC_CONNECTED状态后返回RRC_IDLE状态时，UE应根据redirectedCarrierInfo(如果被包括在RRC释放消息中)尝试驻留在可接受的小区上。如果UE找不到可接受的小区，则允许UE驻留在指示的RAT的任何可接受的小区上。如果RRC释放消息不包含redirectedCarrierInfo，则UE应尝试在NR载波上选择可接受的小区。如果根据上述未找到可接受的小区，则UE应在任何小区选择的状态下继续搜索任何PLMN的可接受的小区。
无线电网络子系统应用部分用户自适应(RNA)更新过程
在布拉格的RAN2#99bis中，已经达成一致，对于RAN区域更新，网络可以使用RRC释放(可能包含重定向信息)响应RRC恢复请求(RRCResumeRequest)：
协议3：尝试恢复RRC连接的在INACTIVE状态下的UE，可以接收具有至少完整性保护的通过SRB1发送的MSG4以将UE移回到INACTIVE状态(即，未被拒绝)。(RNA更新用例)
协议4：协议3的MSG4(即，未被拒绝)可以配置至少与将UE移到INACTIVE状态的消息所配置的参数相同的参数(例如，I-RNTI、RNA、RAN DRX周期、周期性RNAU定时器、重定向载波频率、针对非活动模式的移动性控制信息或重选优先级信息)。(安全框架将单独讨论)
协议5：尝试恢复RRC连接的在INACTIVE状态下的UE，可以接收具有至少完整性保护的通过SRB1发送的MSG4以将UE移到IDLE状态。
没有重定向的常规RRC释放
图2示出了常规无线电网络子系统应用部分用户自适应(RNA)更新过程。图2描述了当在RRC_INACTIVE状态下的UE移出所配置的RNA(涉及通过Xn接口进行上下文检索)时UE触发的RNA更新过程。因为释放不涉及重定向，所以该过程可以由UE执行而无需进入RRC_CONNECTED状态。在步骤200处，UE发出RRC恢复请求，指示这是针对RNA更新的。接收到该请求的新无线电基站(gNB)从上一个服务的gNB检索UE上下文(步骤202和204)，并且向上一个服务的gNB提供数据转发地址指示(步骤206)。然后，第一gNB请求服务的AMF执行路径切换(步骤208和210)。然后，第一gNB使用RRC释放响应UE(步骤212)，该RRC释放包括suspendConfig信息。然后，第一gNB通知上一个服务的gNB可以丢弃该UE的上下文信息(步骤214)。
现有解决方案的问题
当前存在某些挑战。根据当前的3GPP标准，当释放包括将UE重定向到不同RAT的重定向信息时，UE将转变到RRC_IDLE状态。实际上，接收到重定向信息的UE无论如何都进入RRC_IDLE状态。因此，图2中所示的常规过程对于没有重定向的RRC释放是可以接受的，但是如果RRC释放包括重定向信息，则是不可接受的，因为UE会转变到RRC_IDLE状态，并且丢失任何已激活的安全。
然后的问题是，是否需要保护重定向信息。在蒙特利尔的RAN2会议RAN2#AH 2018-07中，针对NR讨论了包含重定向信息的RRC释放消息的安全方面，并且RAN2向3GPP服务和系统方面(SA)工作组3-安全(SA3)发送了联络声明(LS)，请求该消息是否可以出于性能原因而不受保护地发送，因为时延可能很高并且当UE来自RRC_IDLE以及需要进入RRC_CONNECTED并建立AS安全时可能生成太多的信令。该讨论是，重定向似乎是要保护的敏感信息，随后被SA3确认。
因此，已经决定，由于RRC释放消息的安全方面，UE必须在接收到包括重定向信息的RRC释放消息之前已经建立了AS安全。结果，诸如图2所示的RNA更新过程之类的过程不适用于接收包括重定向信息的释放消息。而是，常规系统必须使用诸如图3所示的过程。
具有到NR频率的重定向的常规释放
UE在RRC_IDLE状态下
图3示出了用于针对当前在RRC_IDLE状态下的UE的释放和重定向到NR频率的常规过程。在哥德堡的RAN2#103会议上，SA3关于包含这些信息中的一些信息的RRC释放消息的安全方面答复了RAN2 LS，指出SA3认为RAN2有必要确保RRC连接释放消息至少受到完整性保护，并且这是使UE能够验证消息源的真实性并防止假基站攻击所必需的。
换句话说，RRC释放消息只能由RRC_CONNECTED UE来处理，并且在它以安全的方式出现的情况下(即，至少受完整性保护)才能被处理。因此，在图3中，UE首先从RRC_IDLE状态转变到RRC_CONNECTED状态(步骤300和302)，然后从CM-IDLE状态转变到CM-CONNECTED状态(步骤304和306)，建立NAS传输(步骤308、310、312、314)，并在它可以接收具有重定向信息的RRC释放消息(步骤322)之前建立安全上下文(步骤316、318和320)。
此外，根据RRC规范(更确切地说是redirectedCarrierInfo的字段描述)和空闲/非活动规范，仅在UE离开RRC_CONNECTED状态的情况下，才可以对其进行重定向。RRC规范可能是在考虑特定用例的情况下编写的-即，其中源RAT(例如，NR)中的网络节点正变得过载，并且没有实现具有同步的切换/重新配置，或者由于某些其他原因而优选地将RRC_CONNECTED UE重定向到另一个频率或RAT，而不必配置测量。该用例假定UE在RRC_CONNECTED状态下。
然而，另一个相关用例是UE在RRC_IDLE状态下并想要开始给定服务，并且由于一些网络条件(例如，特定频率和/或RAT中的过载、不支持所请求的服务(如网际协议语音(VoIP)等)，UE被移到RRC_CONNECTED状态，然后使用释放消息进行重定向。因为需要保护该消息的SA3要求，该用例在时延和信令方面遭受较大的惩罚。
此外，在针对尝试恢复或建立连接的进入的UE(想要接入目标小区中不支持的特定服务(例如，VoIP、视频呼叫等))的时延方面，存在性能问题。如上所述，在RRC_IDLE UE的情况下，UE将需要触发RRC建立过程，进入RRC_CONNECTED，执行初始安全激活，然后才接收受保护的重定向信息。这也将涉及一些核心网络信令，如图3所示。
具有到NR频率的重定向的常规释放，
UE在RRC INACTIVE状态下
随着在NR中引入RRC_INACTIVE状态，从RRC_INACTIVE进入RRC_CONNECTED状态的过程比从RRC_IDLE状态进入RRC_CONNECTED状态的过程要快。因此，由于已经激活了安全，即，不需要执行初始安全激活过程，进入的UE进入RRC_CONNECTED状态然后被释放的用例变得更快。
然而，尽管与RRC_IDLE状态相比具有益处，但是即使对于RRC_INACTIVE UE，由于UE在可被重定向之前首先需要进入RRC_CONNECTED状态的事实，仍然存在相当大量的信令和时延。与UE来自RRC_IDLE状态的情况相比，从RRC_INACTIVE状态开始的释放和重定向的时延可以更短，因为已经激活了安全。在发送安全RRC释放消息后，网络可以将UE移到RRC_IDLE状态或RRC_INACTIVE状态。当网络将UE重定向到另一个NR频率时，在典型情况下，网络将UE移到RRC_INACTIVE状态，以加速目标频率中的连接恢复，从而进一步减少总体时延，如图4所示。
图4示出了用于针对当前在RRC_INACTIVE状态下的UE的具有到NR频率的重定向的释放的常规过程。在图4中，UE发出RRC恢复请求(步骤400)。gNB从上一个服务的gNB检索UE上下文(步骤402和404)，并且向UE发送RRC恢复指令(步骤406)。然后，UE进入RRC_CONNECTED状态，并向gNB发出RRC恢复完成(RRCResumeComplete)消息(步骤408)。gNB可选地向上一个服务的gNB提供数据转发地址指示(步骤410)。然后，gNB发起在AMF处的路径切换(步骤412和414)，释放UE上下文(步骤416)，并且向UE发送RRC释放(步骤418)。RRC释放指示UE进入RRC_INACTIVE状态并重定向到NR频率。然后，UE进入RRC_INACTIVE模式，然后尝试在指示的NR频率中恢复(步骤420)。
如图4所示，如果RRC_INACTIVE UE尝试恢复RRC连接，并且在进入RRC_CONNECTED状态之后，UE被挂起到具有到NR频率的重定向信息的RRC_INACTIVE状态，则可以改进时延。在目标小区处，UE尝试恢复连接。在这种场景中，延迟可以被计算为：
2*RTT_nr(RRC恢复请求，RRC恢复，RRC恢复完成，RRC释放)
+RTT_Xn(来自上下文获取的源中的网络延迟)
+RTT_5gc(CN和源路径切换之间的信令)
+1.5*RTT_nr(RRC恢复请求，RRC恢复，RRC恢复完成)
+RTT_Xn(来自上下文获取的目标中的网络延迟)
+RTT_5gc(CN和源路径切换之间的信令)
＝3.5＊RTT_nr+2＊RTT_Xn+2＊RTT_5gc。
具有到演进的通用陆地无线电接入(E-UTRA)频率的重定向的常规释放，UE在RRC_INACTIVE状态下
图5示出了用于针对当前在RRC_INACTIVE状态下的UE的具有到E-UTRA频率的重定向的释放的常规过程。在这种RAT间的情况下，如果NR不支持UE请求的服务，则网络可以将UE重定向到另一个RAT，例如LTE。在接收到具有重定向信息的RRC释放后，无论网络是否指示UE移到RRC_INACTIVE状态或RRC_IDLE状态，UE应在进入RRC_IDLE状态后执行动作并执行到指示的E-UTRA频率中的LTE小区的小区选择，执行RRC连接建立过程(从RRC_IDLE状态转变到E-UTRA中的RRC_CONNECTED状态)。
在图5中，UE发出RRC恢复请求(步骤500)。gNB从上一个服务的gNB检索UE上下文(步骤502和504)，并且向UE发送RRC恢复指令(步骤506)。然后，UE进入RRC_CONNECTED状态，并向gNB发出RRC恢复完成消息(步骤508)。gNB可选地向上一个服务的gNB提供数据转发地址指示(步骤510)。然后，gNB发起在AMF处的路径切换(步骤512和514)，释放UE上下文(步骤516)，并且向UE发送RRC释放(步骤518)。RRC释放消息可以具有或不具有suspendConfig，并重定向到LTE频率。然后，UE进入RRC_IDLE模式，在指示的LTE频率中执行小区选择，并触发RRC连接建立(步骤520)。
从图5所示的RAT间情况可以看出，如果RRC_INACTIVE UE尝试恢复RRC连接，并且在进入RRC_CONNECTED状态之后，UE被挂起到具有到E-UTRA频率的重定向信息的RRC_INACTIVE状态，则可以改进时延。在目标小区处，UE尝试建立连接(使用RRC_IDLE到RRC_CONNECTED状态的转变)。在这种场景中，延迟可以被计算为：
2*RTT_nr(RRC恢复请求，RRC恢复，RRC恢复完成，RRC释放)
+RTT_Xn(来自上下文获取的源中的网络延迟)
+RTT_5CN(CN和源路径切换之间的信令)
+3.5*RTT_eutra(RRC连接请求，RRC建立，RRC建立完成，安全模式命令(SecurityModeCommand)，安全模式完成(SecurityModeComplete))
+2.5*RTT_EPC(CN和目标eNB之间的信令)
＝2＊RTT_nr+2.5＊RTT_eutra+RTT_5GC+2.5＊RTT_EPC。
现有解决方案的问题
根据RRC规范，在接收到具有字段redirectedCarrierInfo的RRC释放消息后，UE根据TS 38.304中描述的内容进行动作，如下所示：“在从RRC_CONNECTED状态转变到RRC_IDLE状态或RRC_INACTIVE状态时，UE应根据redirectedCarrierInfo(如果被包括在用于该转变的RRC消息中)尝试驻留在合适的小区上。
简言之，当前的3GPP规范要求，在接收到RRC恢复消息后，UE应首先进入RRC_CONNECTED状态，然后才能接收redirectedCarrierInfo字段并执行释放和重定向过程。由于UE在源小区/源RAT中将没有任何数据连接，因此存在大量的无线电接口上的信令(首先经由完整的恢复过程进入RRC_CONNECTED状态)、RAN网络节点之间的信令(用于上下文获取)、RAN和CN节点之间的信令(用于路径切换)。本公开的主题尝试解决这些问题。
发明内容
以下阐述的实施例呈现使本领域技术人员能够实践实施例的信息并且示出实践实施例的最佳模式。在根据附图阅读以下描述以后，本领域技术人员将理解本公开的构思并且将认识到本文未具体给出的这些构思的应用。应当理解的是，这些构思和应用落入本公开的范围内。本公开的某些方面及其实施例可以提供针对前述或其他挑战的解决方案。
根据本公开的一个方面，一种由用户设备(UE)执行的用于在电信网络内进行通信的方法，包括：当在无线电资源控制RRC非活动状态下时，向基站发送用于恢复通信的请求，并且在没有进入RRC连接状态的情况下，从基站接收用于释放和重定向的指令；以及响应于接收到用于释放和重定向的指令，以无线电接入技术RAT执行小区选择，并且尝试建立或恢复与所选择的小区的通信。
在一些实施例中，用于恢复通信的请求包括RRC恢复请求消息。
在一些实施例中，用于释放和重定向的指令包括RRC释放消息。
在一些实施例中，用于释放和重定向的指令标识将在其中执行小区选择的RAT。
在一些实施例中，将在其中执行小区选择的RAT包括新无线电(NR)频率或长期演进(LTE)频率。
在一些实施例中，尝试建立或恢复与所选择的小区的通信包括尝试建立与所选择的小区的通信。
在一些实施例中，尝试建立与所选择的小区的通信包括执行RRC建立过程。
在一些实施例中，尝试建立或恢复与所选择的小区的通信包括尝试恢复与所选择的小区的通信。
在一些实施例中，尝试恢复与所选择的小区的通信包括执行RRC恢复过程。
根据本公开的另一方面，一种由基站执行的用于在电信网络内与UE进行通信的方法，包括：从在RRC INACTIVE状态下的UE接收用于恢复通信的请求；以及响应于接收到用于恢复通信的请求，并且在没有首先向UE发送用于恢复的指令的情况下，向UE发送用于释放和重定向的指令。
在一些实施例中，用于恢复通信的请求包括RRC恢复请求消息。
在一些实施例中，用于释放和重定向的指令包括RRC释放消息。
在一些实施例中，用于释放和重定向的指令标识将在其中执行小区选择的RAT。
在一些实施例中，将在其中执行小区选择的RAT包括NR频率或LTE频率。
在一些实施例中，该方法还包括：在发送用于释放和重定向的指令之前，执行上下文重定位。
在一些实施例中，执行上下文重定位还包括以下步骤：从上一个服务基站检索与UE相关联的上下文；以及向接入和移动性管理功能(AMF)发送路径切换请求；以及从AMF接收路径切换请求响应。
在一些实施例中，该方法还包括：在发送用于释放和重定向的指令之后，向上一个服务基站发送用于释放与UE相关联的上下文的指令。
根据本公开的另一方面，一种用于在电信网络内进行通信的无线设备包括：处理电路，被配置为执行本文公开的任何UE方法；以及电源电路，被配置为向无线设备供电。
根据本公开的另一方面，一种用于在电信网络内与UE进行通信的基站包括：处理电路，被配置为执行本文公开的任何基站方法；以及电源电路，被配置为向基站供电。
根据本公开的另一方面，一种用于在电信网络内进行通信的UE，包括：天线，被配置为发送和接收无线信号；无线电前端电路，连接到天线和处理电路，并被配置为调节在天线和处理电路之间传送的信号；处理电路，被配置为执行本文公开的任何UE方法；输入接口，连接到处理电路，并被配置为允许信息输入到UE中以由处理电路处理；输出接口，连接到处理电路，并被配置为从UE输出已经由处理电路处理的信息；以及电池，连接到处理电路并被配置为向UE供电。
根据本公开的另一方面，一种包括主机计算机的通信系统，该主机计算机包括：处理电路，被配置为提供用户数据；以及通信接口，被配置为将用户数据转发给蜂窝网络以向UE进行传输；其中，蜂窝网络包括具有无线电接口和处理电路的基站，基站的处理电路被配置为执行本文公开的任何基站方法。
在一些实施例中，通信系统还包括基站。
在一些实施例中，UE被配置为与基站通信。
在一些实施例中，主机计算机的处理电路被配置为执行主机应用，从而提供用户数据；并且UE包括处理电路，该处理电路被配置为执行与主机应用相关联的客户端应用。
根据本公开的另一方面，一种在包括主机计算机、基站和UE的通信系统中实现的方法，包括：在主机计算机处，提供用户数据；以及在主机计算机处，经由包括基站的蜂窝网络发起向UE的携带用户数据的传输，其中，基站执行本文公开的任何基站方法。
在一些实施例中，该方法还包括：在基站处，发送用户数据。
在一些实施例中，通过执行主机应用在主机计算机处提供用户数据，该方法还包括在UE处执行与主机应用相关联的客户端应用。
根据本公开的另一方面，一种被配置为与基站通信的UE，包括无线电接口和处理电路，该处理电路被配置为执行本文公开的任何UE方法。
根据本公开的另一方面，一种包括主机计算机的通信系统，该主机计算机包括：处理电路，被配置为提供用户数据；以及通信接口，被配置为将用户数据转发给蜂窝网络以向UE进行传输；其中，UE包括无线电接口和处理电路，UE的组件被配置为执行本文公开的任何UE方法。
在一些实施例中，蜂窝网络还包括被配置为与UE通信的基站。
在一些实施例中，主机计算机的处理电路被配置为执行主机应用，从而提供用户数据；并且UE的处理电路被配置为执行与主机应用相关联的客户端应用。
根据本公开的另一方面，一种在包括主机计算机、基站和UE的通信系统中实现的方法，包括：在主机计算机处，提供用户数据；以及在主机计算机处，经由包括基站的蜂窝网络发起向UE的携带用户数据的传输，其中，UE执行本文公开的任何UE方法。
在一些实施例中，该方法还包括：在UE处，从基站接收用户数据。
根据本公开的另一方面，一种包括主机计算机的通信系统，该主机计算机包括：通信接口，被配置为接收源自从UE到基站的传输的用户数据；其中，UE包括无线电接口和处理电路，UE的处理电路被配置为执行本文公开的任何UE方法。
在一些实施例中，该通信系统还包括UE。
在一些实施例中，基站包括：无线电接口，被配置为与UE通信；以及通信接口，被配置为将从UE到基站的传输所携带的用户数据转发给主机计算机。
在一些实施例中，主机计算机的处理电路被配置为执行主机应用；并且UE的处理电路被配置为执行与主机应用相关联的客户端应用，从而提供用户数据。
在一些实施例中，主机计算机的处理电路被配置为执行主机应用，从而提供请求数据；并且UE的处理电路被配置为执行与主机应用相关联的客户端应用，从而响应于请求数据而提供用户数据。
根据本公开的另一方面，一种在包括主机计算机、基站和UE的通信系统中实现的方法，包括：在主机计算机处，接收从UE向基站传输的用户数据，其中，UE执行本文公开的任何UE方法。
在一些实施例中，该方法还包括：在UE处，向基站提供用户数据。
在一些实施例中，该方法还包括：在UE处，执行客户端应用，从而提供要发送的用户数据；以及在主机计算机处，执行与客户端应用相关联的主机应用。
在一些实施例中，该方法还包括：在UE处，执行客户端应用；以及在UE处，接收对客户端应用的输入数据，输入数据是通过执行与客户端应用相关联的主机应用在主机计算机处提供的；其中，要发送的用户数据是客户端应用响应于输入数据而提供的。
根据本公开的另一方面，一种通信系统包括主机计算机，该主机计算机包括通信接口，该通信接口被配置为接收源自从UE到基站的传输的用户数据，其中，基站包括无线电接口和处理电路，基站的处理电路被配置为执行本文公开的任何基站方法。
在一些实施例中，该通信系统还包括基站。
在一些实施例中，UE被配置为与基站通信。
在一些实施例中，主机计算机的处理电路被配置为执行主机应用；并且UE被配置为执行与主机应用相关联的客户端应用，从而提供要由主机计算机接收的用户数据。
根据本公开的另一方面，一种在包括主机计算机、基站和UE的通信系统中实现的方法，包括：在主机计算机处，从基站接收源自基站已经从UE接收到的传输的用户数据，其中，UE执行本文公开的任何UE方法。
在一些实施例中，该方法还包括：在基站处，从UE接收用户数据。
在一些实施例中，该方法还包括：在基站处，发起对接收到的用户数据向主机计算机的传输。
因此，本文公开的系统和方法包括使用具有重定向的两步释放过程将在RRC_INACTIVE状态下的UE重定向到不同的频率/RAT，即，直接响应于恢复请求而发送具有重定向的释放消息。
本文提出了解决本文公开的一个或多个问题的各种实施例。某些实施例可以提供以下技术优点中的一个或多个。所提出的方法的一个优点是减少了空中接口和节点间接口(RAN节点之间的接口和RAN与CN之间的接口二者)的时延和信令。
附图说明
并入本说明书中并且形成其一部分的附图示出了本公开的若干方面，并且与描述一起用于解释本公开的原理。
图1示出了用户设备(UE)状态机以及新无线电(NR)中的无线电资源控制(RRC)状态之间的可能状态转变；
图2示出了常规无线电网络子系统应用部分用户自适应(RNA)更新过程；
图3示出了用于针对当前在RRC_IDLE状态下的UE的释放和重定向到NR频率的常规过程；
图4示出了用于针对当前在RRC_INACTIVE状态下的UE的具有到NR频率的重定向的释放的常规过程；
图5示出了用于针对当前在RRC_INACTIVE状态下的UE的具有到E-UTRA频率的重定向的释放的常规过程；
图6示出了根据本公开的一些实施例的由UE执行的用于释放和重定向的示例性过程；
图7示出了根据本公开的一些实施例的由网络节点执行的用于释放和重定向的示例性过程；
图8示出了根据本公开的一些实施例的用于释放和重定向的示例性两步过程；
图9示出了上层/非接入层(NAS)和接入层(AS)之间的常规交互；
图10示出了根据本公开的一些实施例的用于释放和重定向的示例性两步过程；
图11示出了根据本公开的一些实施例的在示例性NAS和AS层之间的示例性交互；
图12示出了根据本公开的一些实施例的在示例性NAS和AS层之间的示例性交互；
图13示出了根据本公开的一些实施例的蜂窝通信网络的一个示例；
图14示出了被表示为由核心网络功能(NF)组成的第五代(5G)网络架构的无线通信系统，其中任何两个NF之间的交互由点对点参考点/接口表示；
图15示出了在控制面中NF之间使用基于服务的接口的5G网络架构；
图16是根据本公开的一些实施例的无线电接入节点的示意性框图；
图17是示出了根据本公开的一些实施例的无线电接入节点的虚拟化实施例的示意性框图；
图18是根据本公开的一些其它实施例的无线电接入节点的示意性框图；
图19是根据本公开的一些实施例的UE的示意性框图；
图20是根据本公开的一些其它实施例的UE的示意性框图；
图21示出了根据本公开的一些实施例的通信系统；
图22示出了根据本公开的一些其它实施例的通信系统；
图23是示出了根据本公开的一些实施例的在通信系统中实现的方法的流程图；
图24是示出了根据本公开的一些实施例的在通信系统中实现的方法的流程图；
图25是示出了根据本公开的一些实施例的在通信系统中实现的方法的流程图；以及
图26是示出了根据本公开的一些实施例的在通信系统中实现的方法的流程图。
具体实施方式
现在将参考附图更全面地描述本文中设想的一些实施例。然而，其他实施例包含在本文所公开的主题的范围内，所公开的主题不应被解释为仅限于本文阐述的实施例；而是，这些实施例是通过示例方式提供的，以向本领域技术人员传达本主题的范围。
无线电节点：如本文所使用的，“无线电节点”是无线电接入节点或无线设备。
无线电接入节点：如本文所使用的，“无线电接入节点”或“无线电网络节点”是进行操作以无线地发送和/或接收信号的蜂窝通信网络的无线电接入网中的任何节点。无线电接入节点的一些示例包括但不限于基站(例如，第三代合作伙伴计划(3GPP)第五代(5G)NR网络中的新无线电(NR)基站(gNB)或3GPP长期演进(LTE)网络中的增强或演进型节点B(eNB))、高功率或宏基站、低功率基站(例如，微基站、微微基站、归属eNB等)、和中继节点。
核心网络节点：如本文所使用的，“核心网络节点”是核心网络中的任何类型的节点。核心网节点的一些示例包括例如移动性管理实体(MME)、分组数据网络网关(P-GW)、服务能力开放功能(SCEF)等。
无线设备：如本文所使用的，“无线设备”是通过无线地向无线电接入节点发送信号和/或从无线电接入节点接收信号来接入蜂窝通信网络(即，由蜂窝通信网络服务)的任何类型的设备。无线设备的一些示例包括但不限于3GPP网络中的用户装置设备(UE)和机器类型通信(MTC)设备。
网络节点：本文中所使用的，“网络节点”是作为蜂窝通信网络/系统的无线电接入网或核心网络的一部分的任何节点。
请注意，本文中给出的描述侧重于3GPP蜂窝通信系统，并且因此通常使用3GPP术语或与3GPP术语类似的术语。然而，本文公开的构思不限于3GPP系统。
请注意，在本文的描述中，可以参考术语“小区”，然而，特别是对于5G NR概念，可以使用波束来代替小区，因此，重要的是注意本文描述的构思同样适用于小区和波束二者。
以下阐述的实施例呈现使本领域技术人员实践实施例的信息并且示出实践实施例的最佳模式。在根据附图阅读以下描述以后，本领域技术人员将理解本公开的构思并且将认识到本文未具体给出的这些构思的应用。应当理解的是，这些构思和应用落入本公开的范围内。
具有重定向的改进释放-UE
图6示出了根据本公开的一些实施例的由UE执行的用于释放和重定向的示例性过程。在图6所示的实施例中，由在无线电资源控制(RRC)非活动(RRC_INACTIVE)状态下的UE执行的方法包括以下步骤：
步骤600：从上层(例如，非接入层(NAS)层)接收恢复RRC连接的请求(例如，以相关联的原因值来开始给定服务的请求，该相关联的原因值例如是：emergency(紧急情况)；highPriorityAccess(高优先级接入)；移动终止(MT)原因值，例如，MT-Access(MT-接入)；移动始发(MO)原因值，例如MO-Data(MO-数据)、MO-VoiceCall(MO-语音呼叫)、MO-VideoCall(MO-视频呼叫)和MO-SMS；多媒体优先级服务(MPS)原因值，例如，MPS-PriorityAccess(MPS-优先接入)；关键任务支持(MCS)原因值，例如，MCS-PriorityAccess(MCS-优先接入)，或将来引入的任何其他原因值)。这些服务可以受所有节点支持，或可以受某些节点支持，而其他节点不支持。
在从上层接收到请求后，UE在发送具有与来自上层的请求相关联的原因值的RRC恢复请求之类的消息时可以执行动作。
尽管上面将步骤600描述为来自上层的请求，但是该方法也适用于来自AS或RRC层的请求，例如，在RNA更新的情况下，使用消息来响应该RNA更新，该消息将UE挂起回到RRC_INACTIVE状态(或等效状态)，并将UE重定向到相同无线电接入技术(RAT)中的另一个频率或不同RAT中的另一个频率。
步骤602：向网络节点(例如，eNB)发送RRC恢复请求消息，该RRC恢复请求消息具有与来自上层的请求相关联的原因值。常规网络只可以使用RRC恢复请求类型的消息(例如，RRC恢复请求消息或RRC恢复请求1(或LTE中的RRC连接恢复请求)，或者在RRC恢复请求与无线电网络子系统应用部分用户自适应(RNA)更新相关联的情况下(例如，当它们具有原因值Movement Authority(MA)Update(移动授权更新)时)使用RRC释放(或LTE中的RRC连接释放)消息来响应。
步骤604：从网络节点并且响应于步骤602中的消息，接收具有到另一个载波的重定向信息的RRC释放消息，该载波可以来自同一RAT或来自不同RAT。存在若干种场景，涉及重定向目标中的变化(例如，NR与LTE)以及RRC释放消息是否包括挂起配置：
NR非活动到NR非活动。在一些实施例中，如果RRC_INACTIVEUE尝试在NR中恢复并且接收到NR频率的重定向信息，并且该消息包含挂起配置，则UE保持在RRC_INACTIVE状态，并且在进入RRC_INACTIVE后在消息中指示的载波频率中执行小区选择。
NR非活动到NR空闲。在一些实施例中，如果RRC_INACTIVE UE尝试在NR中恢复并且接收到NR频率的重定向信息，并且该消息不包含挂起配置，则UE进入RRC_IDLE状态(并相应地执行动作，例如停止定时器、释放资源等)，并在进入RRC_IDLE后在消息中指示的载波频率中执行小区选择。
相同的原理可以应用于“LTE到LTE”过程。
NR非活动到LTE非活动。在一些实施例中，如果RRC_INACTIVE UE尝试在NR中恢复并且接收到LTE频率的重定向信息，并且该消息包含挂起配置，则UE保持在RRC_INACTIVE状态，并且在进入RRC_INACTIVE后在消息中指示的载波频率中执行RAT间小区选择。这由在目标RAT(在该示例中为LTE)中支持RRC_INACTIVE的UE执行。如果UE在LTE中不支持RRC_INACTIVE，则无论消息是否包含挂起配置，UE都在接收到具有重定向信息的RRC释放后进入RRC_IDLE，并且在进入RRC_IDLE后在消息中指示的载波频率中执行RAT间小区选择。
NR非活动到LTE空闲。在一些实施例中，如果RRC_INACTIVE UE尝试在NR中恢复并且接收到LTE频率的重定向信息，并且该消息不包含挂起配置，则UE进入RRC_IDLE状态(并相应地执行动作，例如停止定时器、释放资源等)，并在进入RRC_IDLE后在消息中指示的载波频率中执行小区选择。
相同的原理可以应用于“LTE到NR”过程。
在任何这些情况下(LTE到NR、NR到NR、LTE到LTE或NR到LTE)，UE需要执行小区选择。
上述不同场景由图6的步骤606、608、610、612和614处理。在图6所示的实施例中，UE确定重定向信息是否朝向相同的RAT(步骤606)，并且如果是，则UE将保持在RRC_INACTIVE状态(步骤608)。然而，如果重定向信息朝向不同的RAT，则UE将确定新的RAT是否支持RRC_INACTIVE状态(步骤610)，并且如果是，则将保持在该状态(步骤608)，否则将进入RRC_IDLE状态(步骤612)。之后，UE执行以下步骤。
步骤614：在进入RRC_INACTIVE状态或RRC_IDLE状态后，以RRC释放消息中指示的频率(在重定向信息中)执行小区选择。
在进行小区选择时，UE可以进入没有为UE配置的新的RNA，即小区、跟踪区域、注册区域、RAN区域ID等。UE不执行RAN区域更新，而是根据恢复原因尝试在新选择的小区中恢复，该恢复原因首先生成RRC恢复请求消息，其由上层请求并且使用具有重定向信息的RRC释放进行响应。更一般地，在一些实施例中，上层请求和恢复过程被认为是待定的(pending)，并且应该在小区选择之后被发起。它们应优先于在小区选择后触发的任何RRC或AS过程，如进入未配置为针对该UE的RNA配置的一部分的新RAN区域。
在进行小区选择时，UE可以进入未配置有(例如，不是其配置的区域列表的一部分)的新的跟踪区域(或注册区域)。在这些场景中，在一些实施例中，代替执行跟踪区域更新(或等效的，如注册区域更新)，该方法包括根据恢复原因尝试在新选择的小区中恢复，该恢复原因首先生成RRC恢复请求消息，其由上层请求并且使用具有重定向信息的RRC释放进行响应。在一些实施例中，上层请求和恢复过程被认为是待定的，并且应该在小区选择之后被发起。它们应优先于在小区选择后触发的任何RRC过程、AS过程或甚至NAS过程(在注册区域更新的情况下)。
在进行小区选择时，UE可以进入未配置有(例如，不是其配置的区域列表的一部分)的新的跟踪区域(或注册区域)。代替执行跟踪区域更新(或等效的，如注册区域更新)，该方法包括根据恢复原因尝试在新选择的小区中恢复，该恢复原因首先生成RRC恢复请求消息，其由上层请求并且使用具有重定向信息的RRC释放进行响应。更一般地，上层请求和恢复过程被认为是待定的，并且应该在小区选择之后被发起。它们应优先于在小区选择后触发的任何RRC过程、AS过程但不是与注册区域更新相关的NAS过程。原因可以是由于在执行区域更新之前不支持给定服务的事实。
在一些实施例中，UE即使没有离开RRC_CONNECTED状态也执行小区选择。因此，这是针对小区选择的新触发：当UE来自RRC_INACTIVE状态时，在接收到RRC释放消息(到RRC_IDLE状态或RRC_INACTIVE状态)后，UE进入RRC_INACTIVE状态或RRC_IDLE状态。
在进入RRC_INACTIVE状态或进入RRC_IDLE状态后的小区选择中，UE应根据redirectedCarrierInfo(如果包括在用于该转变的RRC消息中)尝试驻留在合适的小区上。如果UE找不到合适的小区，则允许UE驻留在指示的RAT的任何合适的小区上。如果根据上述未找到合适的小区，则UE应使用存储的信息执行小区选择，以便找到要驻留的合适的小区。
步骤616：确定UE的当前RRC状态，例如RRC_IDLE或RRC_INACTIVE。
步骤618：如果UE在RRC_INACTIVE状态下，则基于重定向信息触发以指示的RAT的连接恢复过程或以指示的RAT的其他过程。
步骤620：如果UE在RRC_IDLE状态下，则基于重定向信息触发以指示的RAT的连接建立过程或以指示的RAT的其他过程。
具有重定向的改进释放-网络节点
图7示出了根据本公开的一些实施例的由网络节点执行的用于释放和重定向的示例性过程。在图7所示的实施例中，由网络节点执行的方法包括以下步骤：
步骤700：从在RRC INACTIVE状态下的UE接收RRC恢复请求消息，该消息包括原因值，或者以其他方式指示这是由上层请求的。在该步骤中，服务于在其中UE尝试恢复的小区的目标gNB(或eNB或任何种类的RAN节点)从UE接收RRC恢复请求之类的消息。与该恢复请求相关联的原因值指示该请求是由UE中的上层(例如，NAS)触发的。这些的示例包括但不限于：emergency、highPriorityAccess、MT-Access、MO-Data、MO-VoiceCall、MO-VideoCall、MO-SMS、MPS-PriorityAccess或MCS-PriorityAccess。
由于某些网络条件或本地策略(例如，目标小区/载波/RAT过载或与原因值相关联的服务在目标小区/载波/RAT中不可用)，目标gNB可以决定重定向到另一个频率或RAT。备选地，如果未重定位AS上下文，并且是源gNB生成RRC释放消息，则可以是源gNB(或eNB或任何种类的RAN节点)决定重定向UE。然而，例如，这可能需要目标gNB将原因值或指示请求服务的一些其他信息转发给源gNB。
步骤702：确定UE应被重定向到另一个频率和/或另一个RAT。
步骤704：在确定应将UE重定向到另一个频率或另一个RAT后，在没有将UE移到RRC_CONNECTED状态的情况下，使能安全消息的传输。这可以在有或没有上下文重定位的情况下完成。
在第一备选方案中，目标gNB通过Xn接口从源gNB(有时称为锚gNB)获取AS上下文。作为上下文获取过程的一部分，源gNB还验证发出该请求的UE的标识(通过验证包含在恢复请求之类的消息中的shortResumeMAC-I(短恢复MAC-I))。AS上下文除其他外包含重新激活AS安全所需的安全参数(例如，安全密钥和安全算法)，以便可以受保护地发送RRC释放消息(因此满足针对5G的SA3安全要求)。目标gNB还使用AMF执行路径切换过程，以向CN通知UE的新位置并更新控制面和用户面路径。作为该过程的一部分，目标gNB还从AMF接收新的{NCC，NH}对。该对中的NCC值被包括在下一步骤中发送的RRC释放消息中的非活动配置(suspendConfig)中。作为优化，为了进一步减少重定向的时延，目标gNB可以选择与发送释放消息并行或在发送释放消息之后执行路径切换过程(即，以下的步骤3)。然而，由于释放消息中通常包括路径切换确认中的NCC值，因此这要求目标gNB可以提前预测/确定在路径切换确认中接收到的NCC。这是可能的，因为下一个NCC通常是前一个NCC值(可以将其存储为AS上下文的一部分)加1。
在第二备选方案中，目标gNB仍与源gNB联系以验证请求，但它不获取AS上下文。由于未重定位AS上下文，目标gNB将无法重新激活AS安全，并且因此，源gNB必须保护(即，完整性保护和加密)释放消息。这意味着构建释放消息所需的所有信息必须已经对于源gNB是已知的或已由目标gNB转发给源gNB。因此，如果目标gNB做出重定向UE的决定，则它需要将重定向信息(例如，目标频率和目标RAT)发送给源gNB，以便源gNB可以在释放消息中包括重定向信息。请注意，由于未重定位AS上下文，因此目标gNB不执行路径切换。
在现有技术中，已经提到了RAN区域更新(特别是周期性RAN区域更新)作为使用恢复而无需上下文重定位的过程。本公开的主题引入了新的用例，其中知道这将是释放和重定向过程的目标节点触发该过程而无需重定位。目标节点可以将释放和重定向的原因通知给源节点，以便源不必费心某些挂起配置参数，例如与RNA更新相关的参数。从目标到源的消息中可以存在指示，表明这是释放和重定向过程，而无需上下文重定位。
步骤706：向UE发送对RRC恢复请求消息的响应，该响应包括具有重定向信息的RRC释放。在该步骤中，如果在上一步骤中重定位了AS上下文，则目标gNB生成并保护释放消息重定向信息，并将其发送给UE。释放消息包括有关重定向的载波的信息(redirectedCarrierInfo)，并且如果网络希望UE保持在RRC_INACTIVE状态，则该释放消息包括非活动配置(suspendConfig)。如果未重定位AS上下文，则释放消息由源gNB构建和保护，并被发送给目标gNB，该目标gNB转而将其透明地转发给UE。由于释放消息是响应于恢复请求而发送的，因此UE不转变为RRC_CONNECTED；作为替代，如果释放消息中包括挂起配置，则它保持在RRC_INACTIVE状态，否则转变为RRC_IDLE。
步骤708：处理UE上下文取决于UE被移到RRC_IDLE状态还是RRC_INACTIVE状态以及重定向信息是RAT间还是RAT内。由于在Rel-15中跨RAT不支持RRC_INACTIVE，因此，无论释放消息是否包含非活动配置，如果UE从NR被重定向到LTE(反之亦然)，UE将自动转变为RRC_IDLE。因此，如果网络将UE从NR重定向到LTE(反之亦然)，则它可以在发送释放消息后删除AS上下文。取决于是否重定位AS上下文，由源gNB或目标gNB删除AS上下文。
以2个步骤，具有到NR频率的重定向的释放，
UE在RRC_INACTIVE状态下
图8示出了具有上下文重定位和不具有上下文重定位的所提出的解决方案的一种方法，其中确切的时延减少有所不同。
图8示出了根据本公开的一些实施例的用于释放和重定向的示例性两步过程。在这种场景中，使用上下文重定位，图8所示的调用流程可以适用于到NR频率的重定向。在图8所示的实施例中，执行以下步骤：
步骤800：在RRC_INACTIVE、CM-CONNECTED状态下的UE向第一gNB发出RRC恢复请求消息。
步骤802和804：第一gNB从上一个服务的gNB检索UE上下文。
步骤806：第一gNB向上一个服务的gNB提供数据转发地址指示。
步骤808和810：第一gNB然后请求服务的AMF执行路径切换。
步骤812：第一gNB随后使用RRC释放消息来响应UE，该消息包括suspendConfig信息，并且还将UE重定向到另一个NR频率。与现有技术方法不同(在现有技术方法中，gNB将在发出RRC释放消息之前发出RRC恢复消息)，在图8所示的实施例中，gNB不会首先发出RRC恢复消息。因此，UE不进入RRC CONNECTED状态。
步骤814：UE然后在NR中执行小区选择并且尝试在目标小区中恢复。
步骤816：该gNB向上一个服务的gNB发出UE上下文释放(UE Context Release)消思。
由于从UE的角度来看，该过程仅涉及两个步骤-发送RRC恢复请求(步骤800)和接收具有重定向的RRC释放(步骤812)，因此该方法在本文中称为“两步”过程。在如图8所示的具有上下文重定位的两步释放和重定向中，RRC_INACTIVE UE尝试恢复RRC连接，并且在没有进入RRC_CONNECTED状态的情况下，UE被挂起为具有到NR频率的重定向信息的RRC_INACTIVE状态。在目标小区处，UE尝试恢复连接。与UE首先进入RRC_CONNECTED状态然后释放的常规情况相比，可以跳过UE与目标之间的两个消息(RRC恢复和RRC恢复完成)。在这种场景中，延迟可以被计算为：
RTT_nr(RRC恢复请求，RRC释放)
+RTT_Xn(来自上下文获取的源中的网络延迟)
+RTT_5gc(CN和源路径切换之间的信令)
+1.5*RTT_nr(RRC恢复请求，RRC恢复，RRC恢复完成)
+RTT_Xn(来自上下文获取的目标中的网络延迟)
+RTT_5gc(CN和源路径切换之间的信令)
＝2.5＊RTT_nr+3＊RTT_Xn+2＊RTT_5gc。
在一些实施例中，在UE执行两步过程而没有上下文重定位的情况下，甚至进一步优化了图8所示的过程。在这些实施例中，在发送RRC恢复请求(不是RNA更新)后，UE接收具有suspendConfig的RRC释放，但网络不执行上下文重定位-例如，不执行步骤808和810。由于网络知道在释放和重定向的情况下，UE无论如何都将转到另一个频率并在可能位于另一个gNB中的另一个小区中恢复，因此触发上下文获取可能没有意义，因为该新目标可以再次触发上下文获取。因此，不具有上下文重定位的两步过程(RRC恢复请求后跟随具有suspendConfig和重定向信息的RRC释放)甚至可以进一步减少过程的时延，这是由于不需要执行路径切换的事实(因为锚gNB/eNB保持与CN的连接将不需要改变)。在这种场景中，延迟可以被计算为：
RTT_nr(RRC恢复请求，RRC释放)
+1.5*RTT_Xn(来自上下文获取的目标中的网络延迟)
+1.5*RTT_nr(RRC恢复请求，RRC恢复，RRC恢复完成)
+1.5*RTT_Xn(来自上下文获取的目标中的网络延迟)
+RTT_5gc(CN和源路径切换之间的信令)
＝2.5＊RTT_nr+3＊RTT_Xn+RTT_5gc。
对于跨频释放和重定向，不同场景中的时延可以总结在下表中：
在一些实施例中，具有上下文重定位的两步过程被优化以实现与不具有上下文重定位的两步过程相同的时延。在该优化中，仍获取上下文并且仍然执行路径切换，但是具有重定向的释放消息在路径切换之前而不是之后被发送。参考图8，在这些实施例中，步骤812将在该过程中较早地发生，例如，在步骤810、808、806、804或802之前。以这种方式，由于在接收到具有重定向的释放消息之后，UE可以立即开始在目标小区恢复，所以路径切换过程不增加UE所经历的延迟。这种优化是可能的，因为释放消息可以由gNB在接收到路径切换响应之前准备。
以2个步骤，具有到LTE频率的重定向的释放，
UE在RRC_INACTIVE状态下
除了将UE重定向到LTE载波而不是NR载波之外，针对该情况的调用流程与先前的情况相似。尽管详细的信令有所不同，但在这种情况下也可以实现与常规相比类似的时延增益。
其他应用
本公开将该方法描述为由NR中的RRC_INACTIVE UE执行的动作。尽管本公开的主题适用于该情况，但是可以存在本公开的主题同样适用的其他附加情况，例如：
所有先前的情况，其中过程在LTE而不是NR中发生；也就是说，对于LTE RRC_INACTIVE UE的情况(当UE连接到5GC并且由LTE小区支持时)；
在RRC_INACTIVE状态下的RAT间过程，主要在连接到相同CN(5G核心网络)的LTE和NR之间：
o在LTE RRC_INACTIVE状态下的UE尝试通过释放和重定向以两个步骤恢复并被挂起为NR RRC_INACTIVE状态，并且然后尝试根据重定向信息在NR中恢复；
o在NR RRC_INACTIVE状态下的UE尝试通过释放和重定向以两个步骤恢复并被挂起为LTE RRC_INACTIVE状态，并且然后尝试根据重定向信息在LTE中恢复；
在RRC_INACTIVE状态或RRC_IDLE状态下的RAT间过程(例如，在LTE和NR之间)，即使当LTE不支持RRC_INACTIVE状态(例如，在LTE连接到EPC的情况下)或NR不支持RRC_INACTIVE状态(在给定网络、该网络的频率或部分不支持非活动状态的情况下)：
o在LTE RRC_INACTIVE状态下的UE尝试通过释放和重定向以两个步骤恢复并被挂起为NR RRC_INACTIVE状态，并且然后进入RRC_IDLE状态，并且尝试根据重定向信息在NR中建立连接；
o在NR RRC_INACTIVE状态下的UE尝试通过释放和重定向以两个步骤恢复并被挂起为LTE RRC_INACTIVE状态，并且然后进入RRC_IDLE状态，并且尝试根据重定向信息在LTE中建立连接；
注意，在针对RAT间情况的描述中，针对RRC_INACTIVE移动性定义了协调的挂起/恢复过程，即，UE可以在一个RAT中被挂起并且在另一个RAT中恢复。
对于在网络侧描述的方法，可以是可能具有与其相关联的小区的任何RAN节点，或者更根本地其中UE可以驻留并执行恢复请求过程的任何RAN节点。在NR小区或LTE小区连接到5GC的情况下，该网络节点可以是gNB。在NR小区的情况下，该网络节点可以是gNB。在LTE小区(例如，连接到EPC)的情况下，该网络节点可以是演进或增强型节点B(eNB)。
对于在网络侧描述的方法，术语Xn接口已用于指代在NR情况/5GC中在gNB之间的Xn接口。然而，该方法适用于其中可以获取/重定位AS上下文的在RAN节点之间的任何节点间接口，例如，LTE中的在eNB之间的X2接口。在这些情况下，消息使用如XnAP或X2AP的应用层协议。
接入层(AS)和非接入层(NAS)层之间的交互
本文提出的主题的另一个新颖的方面是AS和NAS层之间的交互。在现有技术情况下，当恢复被挂起的连接时，即，当UE进入RRC_CONNECTED时，通知上层。通过这样做，上层知道承载已成功被恢复。否则，通知上层已经发生故障，并且在这种情况下，上层可以触发NAS恢复过程(例如，跟踪区域更新或注册区域更新)。在从RRC_IDLE到RRC_CONNECTED的转变的情况下，在无线电资源配置期间完成的对承载的建立后提供对上层的这种确认。
作为该方法的一部分，上层被通知，UE在用于恢复连接的请求之后正在被挂起。查看RRC规范，如今这当前看起来是这样的：
[开始摘录自RRC规范]
5.3.13.4由UE对RRC恢复的接收
UE应：
停止定时器T319；
如栗RRC恢复包括fullConfig(完整配置)：
执行5.3.5.11中规定的完整配置过程；
否则：
恢复PDCP状态，并且针对SRB2和所有DRB重置COUNT(计数)值；
从存储的UE AS上下文恢复cellGroupConfig(小区组配置)；
向下层指示所存储的UE AS上下文被使用；
丢弃fullI-RNTI(完整I-RNTI)、shortI-RNTI(短I-RNTI)和存储的UE AS上下文，除ran-NotificationAreaInfo(ran-通知区域信息)之外；
如栗RRC恢复包括masterCellGroup(主小区组)：
根据5.3.5.5针对接收到的masterCellGroup执行小区组配置；
编者注：FFS在恢复时是否支持配置secondaryCellGroup(辅小区组)。
如果RRC恢复包括radioBearerConfig(无线电承载配置)：
根据5.3.5.6执行无线电承载配置；
编者注：FFS是否需要第二radioBearerConfig。
恢复SRB2和所有DRB；
如果被存储，则丢弃由cellReselectionPriorities(小区释放优先级)提供或从另一个RAT继承的小区重选优先级信息；
停止定时器T320(如果正在运行)；
如果RRC连接恢复消息包括measConfig(测量配置)：
执行5.5.2中规定的测量配置过程；
如果被挂起，则恢复测量；
编者注：FFS是否需要定义与接入控制定时器(相当于LTE中的T302、T303、T305、T306、T308)相关的UE动作。例如，如果给定的定时器没有在运行，则通知上层。
进入RRC_CONNECTED；
向上层指示挂起的RRC连接已经恢复；
停止小区重选过程；
将当前小区视为PCell；
将RRC恢复完成消息的内容设置如下：
如果上层提供NAS PDU，则设置dedicatedNAS-Message(专用NAS消息)，以包括从上层接收到的信息；
如果上层提供PLMN，则将selectedPLMN-Identity(所选择的PLMN标识)设置为上层从SIB1中的plmn-IdentityList(plmn标识列表)中包括的PLMN中选择的PLMN(TS 24.501[23])；
如果masterCellGroup包括reportUplinkTxDirectCurrent(报告上行链路发送直流)：
包括uplinkTxDirectCurrentList(上行链路发送直流列表)；
将RRC恢复完成消息提交给下层以进行传输；
该过程结束。
[结束摘录自RRC规范]
图9示出了上层/NAS和AS之间的常规交互。在图9所示的实施例中，以下步骤在UE内发生：
步骤900：上层/NAS(下文中简称为“NAS”)请求恢复挂起的连接。
步骤902：AS将RRC恢复请求消息发送给网络。
步骤904：AS从网络接收RRC恢复消息。
步骤906：上层被通知并认为该过程成功，例如，已恢复挂起的连接。UE进入RRC_CONNECTED状态。因此，图9示出了UE从RRC_INACTIVE状态进入RRC_CONNECTED状态的场景。
NAS规范(TS 24.501)还涵盖了在状态RRC_CONNECTED(或在5GC UE情况下为5GMM-CONNECTED)下的UE接收RRC释放消息以转变为RRC_INACTIVE状态的情况，例如，具有非活动指示的GMM-CONNECTED，如以下TS 38.331和TS 24.501所示：
[开始摘录自NAS规范]
5.3.8.3由UE对RRC释放的接收
UE应：
从接收到RRC释放消息的那一刻起，或者可选地，当下层指示已成功确认对RRC释放消息的接收时(以较早者为准)，将该子节中定义的后续动作延迟60ms。
停止定时器T320(如果正在运行)；
如果RRC释放消息包括指示重定向到eutra的redirectedCarrierInfo：
如果包括cnType：
接收到的cnType被提供给上层；
注意：处理如果在重定向后选择的E-UTRA小区不支持cnType指定的核心网络类型的情况，取决于UE实现。
如果RRC释放消息包括cellReselectionPriorities：
存储由cellReselectionPriorities提供的小区重选优先级信息；
如果包括t320：
启动定时器T320，根据t320的值设置定时器值；
否则：
应用系统信息中广播的小区重选优先级信息；
如果包括deprioritisationReq：
启动或重新启动定时器T325，定时器值被设置为发信号通知的deprioritisationTimer；
存储deprioritisationReq，直到T325到期；
如果RRC释放包括suspendConfig：
应用接收到的suspendConfig；
存储suspendConfig中提供的fullI-RNTI、shortI-RNTI、nextHopChainingCount(下一跳链接计数)、t380和ran-PagingCycle；
重置MAC；
针对SRB1重新建立RLC实体；
如果响应于RRC恢复请求或RRC恢复请求1而接收具有suspendConfig的RRC释放消息：
停止定时器T319(如果正在运行)；
用suspendConfig中的新接收的安全上下文来替换任何先前存储的安全上下文；
用UE已经接收到RRC释放消息的小区中的临时C-RNTI来替换先前存储的C-RNTI；
用UE已经接收到RRC释放消息的小区的cellIdentity来替换先前存储的cellIdentity；
用UE已经接收到RRC释放消息的小区的物理小区标识来替换先前存储的物理小区标识；
否则：
存储UE AS上下文(包括当前的RRC配置、当前的安全上下文、包括ROHC状态的PDCP状态、SDAP配置、源PCell中使用的C-RNTI、源PCell的cellIdentity和物理小区标识)；
挂起除SRB0之外的所有SRB和DRB；
启动定时器T380，其中定时器值被设置为t380；
向上层指示RRC连接的挂起；
进入RRC_INACTIVE并执行TS 38.304[21]中规定的过程
否则
在进入RRC_IDLE时执行5.3.11中规定的动作，其中释放原因为“其他”。
编者注：FFS是否需要有不同的释放原因和相关联的动作。
******
5.3.1.4具有RRC非活动指示的5GMM-CONNECTED模式
...
在从下层接收到UE已经转变为RRC_INACTIVE状态的指示后，UE应从3GPP接入上的5GMM-CONNECTED模式转变为具有RRC非活动指示的5GMM-CONNECTED模式。
在以下情况时：
-对要求发送NAS消息的过程的触发；或者
-针对具有挂起的用户面资源的PDU会话要发送的上行链路用户数据分组；
在3GPP接入上的具有RRC非活动指示的5GMM-CONNECTED模式下的UE应请求下层转变为RRC_CONNECTED状态(参见3GPPTS 38.300[27])。
在从下层接收到UE已经转变为RRC_CONNECTED状态的指示后，UE应从具有RRC非活动指示的5GMM-CONNECTED模式转变为3GPP接入上的5GMM-CONNECTED模式(参见3GPP TS38.300[27])。
注意：AMF可以知道针对UE的在5GMM-CONNECTED模式和具有RRC非活动指示的5GMM-CONNECTED模式之间的转变(参见3GPP TS 23.502[9])。
[结束摘录自NAS规范]
尽管NAS规范涵盖了UE从RRC_CONNECTED移到RRC_INACTIVE状态以及从RRC_INACTIVE移到RRC_CONNECTED状态的情况，但当前的NAS规范并未涵盖UE在RRC_INACTIVE下时上层请求恢复请求并且可能接收具有重定向到RRC_IDLE(在这种情况下转变为5GMM-IDLE)或RRC_INACTIVE(在这种情况下转变为具有非活动指示的5GMM-CONNECTED)的释放的情况。图10中示出了该场景。
图10示出了根据本公开的一些实施例的用于释放和重定向的示例性两步过程，示出了常规NAS没有能力处理这种场景。在图10所示的实施例中，以下步骤在UE内发生：
步骤1000：上层/NAS请求恢复挂起的连接。
步骤1002：AS将RRC恢复请求消息发送给网络。
步骤1004：AS从网络接收RRC释放消息。
步骤1006：上层被通知，但是常规NAS不知道如何处理该信息。图11和图12示出了解决该问题的实施例。
图11示出了根据本公开的一些实施例的在示例性NAS和AS层之间的示例性交互。在图11所示的实施例中，在发送RRC恢复请求之后接收到具有重定向信息的进入RRC_INACTIVE的消息后，UE通知上层其正在被挂起(尽管它已经被挂起)。在一些实施例中，在来自下层的对挂起的指示后，上层将通过隐式地理解在具有重定向信息的情况下UE被释放而认为UE仍在具有非活动指示的MM-CONNECTED下并认为第一请求待定。在UE执行小区选择之后，上层可以再次触发该请求。在图11所示的实施例中，以下步骤在UE内发生：
步骤1100：上层/NAS请求恢复挂起的连接。
步骤1102：AS将RRC恢复请求消息发送给网络。
步骤1104：AS从网络接收到RRC恢复消息。
步骤1106：NAS认为该过程待定。
步骤1108：上层例如在小区选择后再次触发该请求。
图12示出了根据本公开的一些实施例的在示例性NAS和AS层之间的示例性交互。在图12所示的实施例中，在发送RRC恢复请求之后接收到具有重定向信息的进入RRC_INACTIVE的消息后，UE通知上层其正在被挂起(尽管它已经被挂起)并且指示是否包括释放和重定向信息。在来自下层的对具有该重定向指示的挂起的指示之后，上层将认为UE仍在具有非活动指示的MM-CONNECTED下，并认为第一请求待定。在UE执行小区选择之后，上层可以再次触发该请求。
在图12所示的实施例中，以下步骤在UE内发生：
步骤1200：上层/NAS请求恢复挂起的连接。
步骤1202：AS将RRC恢复请求消息发送给网络。
步骤1204：AS从网络接收RRC释放消息，该消息包括重定向信息。
步骤1206：AS认为该过程待定，并在小区重选后触发待定请求。
在根据本公开的又一示例性实施例中，如果UE在2步骤过程中被重定向，则来自上层的用于恢复的待定请求由AS层处理。在这些实施例中，在发送RRC恢复请求之后接收到具有重定向信息的进入RRC_INACTIVE的消息后，UE不通知上层其正在被挂起，而是认为来自上层的请求仍然有效。因此，在根据重定向信息执行小区选择后，UE触发来自上层的待定恢复请求。由于上层可以期望在某个时间内响应，因此根据先前情况的对重定向的指示可以用于向上层指示该过程不应被放弃。
规范中方法的实现
根据本公开的一些实施例可以被编纂在如下所示的3GPP规范中。新文本以粗体下划线标记。
本公开的一个实施例可以被编纂为RRC规范中的更改，以阐明导致小区选择的RRC释放中的redirectedCarrierInfo可以不一定导致离开RRC_CONNECTED的过程：
[开始对RRC规范的所提出的更改1]
[结束对RRC规范的所提出的更改1]
本公开的另一个实施例可以被编纂为空闲/非活动规范中的更改，以阐明导致小区选择的RRC释放中的redirectedCarrierInfo可以不一定导致离开RRC_CONNECTED的过程：
[开始对RRC规范的所提出的更改2]
5.2.6离开RRC_CONNECTED状态时的小区选择
在从RRC_CONNECTED状态转变为RRC_IDLE状态或RRC_INACTIVE状态时，或者在两 步过程中保持在RRC_INACTIVE状态(即，UE被挂起而没有进入RRC_CONNECTED)时，UE应根据redirectedCarrierInfo(如果包括在用于该转变的RRC消息中)尝试驻留在合适的小区上。如果UE找不到合适的小区，则允许UE驻留在指示的RAT的任何合适的小区上。如果RRC释放消息不包含redirectedCarrierInfo，则UE应尝试在NR载波上选择合适的小区。如果根据上述未找到合适的小区，则UE应使用存储的信息执行小区选择，以便找到要驻留的合适的小区。
在UE从驻留在任何小区状态移到RRC_CONNECTED状态后返回RRC_IDLE状态时，UE应根据redirectedCarrierInfo(如果被包括在RRC释放消息中)尝试驻留在可接受的小区上。如果UE找不到可接受的小区，则允许UE驻留在指示的RAT的任何可接受的小区上。如果RRC释放消息不包含redirectedCarrierInfo，则UE应尝试在NR载波上选择可接受的小区。如果根据上述未找到可接受的小区，则UE应在任何小区选择的状态下继续搜索任何PLMN的可接受的小区。
[结束对RRC规范的所提出的更改2]
本公开的另一个实施例可以被编纂为阶段2规范(TS 38.300)中的更改，以阐明导致小区选择的RRC释放中的redirectedCarrierInfo可以不一定导致离开RRC_CONNECTED的过程：
[开始对RRC规范的所提出的更改3]
9.2.2.5两步恢复请求/释放过程(例如，RNA更新)
下图描述了当UE移出所配置的RNA(涉及通过Xn进行上下文检索)时UE触发的RNA更新过程：
<<图9.2.2.5-1：RNA更新过程>>
1.UE从RRC_INACTIVE恢复，提供由上一个服务的gNB分配的I-RNTI和适当的原因值
2.如果能够解析I-RNTI中包含的gNB标识，则gNB请求上一个服务的gNB提供UE上下文。
3.上一个服务的gNB提供UE上下文。
4.gNB可以将UE移到RRC_CONNECTED，或者使UE回到RRC_INACTIVE状态，或者使UE移到RRC_IDLE。如果使UE移动RRC_IDLE，则不需要以下步骤。
5.如果应防止上一个服务的gNB中缓冲的DL用户数据的丢失，则gNB提供转发地址。
6./7.gNB执行路径切换。
8.gNB触发在上一个服务的gNB处的对UE资源的释放。
UE可以响应于RRC恢复请求类型的消息而接收具有重定向信息的RRC释放。
[结束对RRC规范的所提出的更改]
附加说明
图13示出了根据本公开的一些实施例的蜂窝通信网络1300的一个示例。在本文描述的实施例中，蜂窝通信网络1300是5G NR网络。在该示例中，蜂窝通信网络1300包括在LTE中被称为eNB而在5G NR中被称为gNB的基站1302-1和1302-2，该基站1302-1和1302-2控制对应的宏小区1304-1和1304-2。基站1302-1和1302-2在本文中被通常统称为基站1302，且分别地称为基站1302。同样，宏小区1304-1和1304-2在本文中被通常统称为宏小区1304，且分别地称为宏小区1304。蜂窝通信网络1300还可以包括控制对应小小区1308-1至1308-4的多个低功率节点1306-1至1306-4。低功率节点1306-1至1306-4可以是小型基站(比如，微微或毫微微基站)或远程无线电头端(RRH)等。值得注意的是，尽管未示出，但是可以备选地由基站1302提供一个或多个小小区1308-1至1308-4。低功率节点1306-1至1306-4在本文中被通常统称为低功率节点1306，且分别地称为低功率节点1306。同样，小小区1308-1至1308-4在本文中被通常统称为小小区1308，且分别地称为小小区1308。基站1302(以及可选的低功率节点1306)连接到核心网络1310。
基站1302和低功率节点1306向对应小区1304和1308中的无线设备1312-1至1312-5提供服务。无线设备1312-1至1312-5在本文中被通常统称为无线设备1312，且分别地称为无线设备1312。无线设备1312在本文中有时也称为UE。
图14示出了被表示为由核心网络功能(NF)组成的5G网络架构的无线通信系统，其中任何两个NF之间的交互由点对点参考点/接口表示。图14可以被视为图13的系统1300的一个特定实现。
从接入侧看，图14中所示的5G网络架构包括连接到无线电接入网(RAN)或接入网(AN)以及接入和移动性管理功能(AMF)的多个用户设备(UE)。通常，R(AN)包括基站，例如，演进型节点B(eNB)或NR基站(gNB)等。从核心网络侧看，图14所示的5G核心NF包括网络切片选择功能(NSSF)、认证服务器功能(AUSF)、统一数据管理(UDM)、AMF、会话管理功能(SMF)、策略控制功能(PCF)和应用功能(AF)。
在规范标准化中，5G网络架构的参考点表示被用于形成详细的调用流程。N1参考点被定义为承载UE和AMF之间的信令。用于AN和AMF之间以及AN和UPF之间连接的参考点分别被定义为N2和N3。在AMF和SMF之间存在参考点N11，这意味着SMF至少部分地由AMF控制。SMF和UPF使用N4，以便可以使用SMF生成的控制信号设置UPF，以及UPF可以将其状态报告给SMF。分别地，N9是不同UPF之间的连接的参考点，N14是不同AMF之间进行连接的参考点。由于PCF分别将策略应用于AMF和SMP，因此定义了N15和N7。AMF需要N12来执行对UE的认证。因为AMF和SMF需要UE的订阅数据，所以定义了N8和N10。
5G核心网络旨在分离用户面和控制面。在网络中，用户面承载用户业务，而控制面承载信令。在图14中，UPF在用户面中，并且所有其他NF，即AMF、SMF、PCF、AF、AUSF和UDM，都在控制面中。分离用户面和控制面确保能够独立缩放每个平面资源。它还允许UPF以分布式方式与控制面功能分开部署。在该架构中，UPF可以非常靠近UE部署，以针对需要低时延的一些应用缩短UE和数据网络之间的往返时间(RTT)。
核心5G网络架构由模块化功能组成。例如，AMF和SMF是控制面中的独立功能。分离的AMF和SMF允许独立的演进和缩放。其他控制面功能(如PCF和AUSF)可以如图14所示分开。模块化功能设计使5G核心网络能够灵活地支持各种服务。
每个NF直接与另一个NF交互。可以使用中间功能将消息从一个NF路由到另一个NF。在控制面中，两个NF之间的一组交互被定义为服务，以便可以重用它。该服务实现对模块化的支持。用户面支持诸如不同UPF之间的转发操作之类的交互。
图15示出了5G网络架构，其使用控制面中的NF之间的基于服务的接口，而不是图14的5G网络架构中使用的点对点参考点/接口。然而，上面参考图14描述的NF对应于图15中所示的NF。NF提供给其他授权的NF的服务等可以通过基于服务的接口暴露给授权的NF。在图15中，基于服务的接口由字母“N”后跟NF的名称来指示，例如，针对AMF的基于服务的接口是Namf，针对SMF的基于服务的接口是Nsmf等。图15中的网络暴露功能(NEF)和网络存储库功能(NRF)并未在上面讨论的图14中示出。然而，应澄清的是，尽管在图14中没有明确示出，图14中描绘的所有NF可以根据需要与图15的NEF和NRF交互。
可以以下面的方式描述图14和图15中所示的NF的一些性质。AMF提供基于UE的认证、授权、移动性管理等。即使使用多种接入技术的UE基本上与单个AMF连接，因为AMF独立于接入技术。SMF负责会话管理，并为UE分配网际协议(IP)地址。它还选择和控制UPF以进行数据传输。如果UE具有多个会话，则可以将不同的SMF分配给每个会话以单独管理它们并且可能针对每个会话提供不同的功能。AF向负责策略控制的PCF提供有关分组流的信息，以支持服务质量(QoS)。根据这些信息，PCF确定有关移动性和会话管理的策略，以使AMF和SMF正常运行。AUSF支持对UE的认证功能等，因此存储用于UE的认证等的数据，而UDM存储UE的订阅数据。数据网络(DN)(不是5G核心网络的一部分)提供互联网接入或运营商服务等。
NF可以实现为专用硬件上的网络元件，实现为在专用硬件上运行的软件实例，或实现为在适合的平台(例如，云基础设施)上实例化的虚拟化功能。
图16是根据本公开的一些实施例的无线电接入节点1600的示意性框图。无线电接入节点1600可以是例如基站1302或1306。如所示，无线电接入节点1600包括控制系统1602，控制系统1602包括一个或多个处理器1604(例如，中央处理单元(CPU)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)等)、存储器1606和网络接口1608。一个或多个处理器1604在本文中也被称为处理电路。此外，无线电接入节点1600包括一个或多个无线电单元1610，每个无线电单元1610包括与一个或多个天线1616耦接的一个或多个发射机1612以及一个或多个接收机1614。无线电单元1610可以被称为无线电接口电路或者是无线电接口电路的一部分。在一些实施例中，无线电单元1610在控制系统1602的外部，并且经由例如有线连接(例如，光缆)连接到控制系统1602。然而，在一些其它实施例中，无线电单元1610和可能的天线1616与控制系统1602集成在一起。一个或多个处理器1604用于提供如本文所述的无线电接入节点1600的一个或多个功能。在一些实施例中，所述功能以例如存储器1606中存储的并由一个或多个处理器1604执行的软件来实现。
图17是示出了根据本公开的一些实施例的无线电接入节点1600的虚拟化实施例的示意性框图。该讨论同样适用于其它类型的网络节点。此外，其它类型的网络节点可以具有类似的虚拟化架构。
如本文所使用的，“虚拟化的”无线电接入节点是(例如，经由在网络中的物理处理节点上执行的虚拟机)无线电接入节点1600的功能的至少一部分被实现为虚拟组件的无线电接入节点1600的实现。如所示，在该示例中，无线电接入节点1600包括控制系统1602，控制系统1602包括一个或多个处理器1604(例如，CPU、ASIC、FPGA等)、存储器1606和网络接口1608以及一个或多个无线电单元1610，每个无线电单元1610如上所述的包括与一个或多个天线1616耦接的一个或多个发射机1612和一个或多个接收机1614。控制系统1602经由例如光缆等连接到无线电单元1610。控制系统1602经由网络接口1608连接到一个或多个处理节点1700，处理节点1700与网络1702耦接或被包括在网络1702中而作为网络1702的一部分。每个处理节点1700包括一个或多个处理器1704(例如，CPU、ASIC、FPGA等)、存储器1706和网络接口1708。
在该示例中，本文所述的无线电接入节点1600的功能1710在一个或多个处理节点1700处实现，或者以任何期望的方式分布在控制系统1602和一个或多个处理节点1700上。在一些特定实施例中，本文所述的无线电接入节点1600的功能1710中的一些或所有功能被实现为由在由处理节点1700托管的虚拟环境中实现的一个或多个虚拟机执行的虚拟组件。如本领域普通技术人员将认识到的那样，为了执行期望功能1710中的至少一些，使用处理节点1700和控制系统1602之间的附加信令或通信。值得注意的是，在一些实施例中，可以不包括控制系统1602，在这种情况下，无线电单元1610经由适当的网络接口直接与处理节点1700通信。
在一些实施例中，提供了包括指令的计算机程序，所述指令在由至少一个处理器执行时使得至少一个处理器执行无线电接入节点1600或根据本文所述的任何实施例的虚拟环境中的实现无线电接入节点1600的功能1710的一个或多个功能的节点(例如，处理节点1700)。在一些实施例中，提供了包括上述计算机程序产品的载体。所述载体是电子信号、光信号、无线电信号或计算机可读存储介质(例如，诸如存储器的非暂时性计算机可读介质)之一。
图18是根据本公开的一些其它实施例的无线电接入节点1600的示意性框图。无线电接入节点1600包括一个或多个模块1800，模块1800中的每个模块是以软件实现的。一个或多个模块1800提供本文所述的无线电接入节点1600的功能。该讨论同样适用于图17的处理节点1700，其中模块1800可以在处理节点1700中的一个处实现或分布在多个处理节点1700上和/或分布在处理节点1700和控制系统1602上。
图19是根据本公开的一些实施例的UE 1900的示意性框图。如图所示，UE 1900包括一个或多个处理器1902(例如，CPU、ASIC、FPGA等)、存储器1904以及一个或多个收发器1906，每个收发器1906包括与一个或多个天线1912耦接的一个或多个发射机1908和一个或多个接收机1910。如本领域普通技术人员将理解的是，收发器1906包括连接到天线1912的无线电前端电路，该无线电前端电路被配置为调节在天线1912和处理器1902之间传送的信号。处理器1902在本文中也被称为处理电路。收发器1906在本文中也被称为无线电电路。在一些实施例中，上述UE 1900的功能可完全或部分地以例如存储器1904中存储的并由处理器1902执行的软件来实现。注意，UE 1900可以包括在图19中没有示出的附加组件，例如一个或多个用户接口组件(例如，包括显示器、按钮、触摸屏、麦克风、扬声器等的输入/输出接口，和/或用于允许向UE 1900中输入信息和/或允许从UE 1900中输出信息的任何其他组件)、电源(例如，电池和相关联的电源电路)等。
在一些实施例中，提供了一种包括指令的计算机程序，所述指令当由至少一个处理器执行时使得该至少一个处理器执行根据本文所述的任何一个实施例的UE 1900的功能。在一些实施例中，提供了包括上述计算机程序产品的载体。所述载体是电子信号、光信号、无线电信号或计算机可读存储介质(例如，诸如存储器的非暂时性计算机可读介质)之一。
图20是根据本公开的一些其它实施例的UE 1900的示意性框图。UE 1900包括一个或多个模块2000，每个模块2000是以软件实现的。模块2000提供本文所述的UE 1900的功能。
图21示出了根据本公开的一些实施例的通信系统。参照图21，根据实施例，通信系统包括电信网络2100(例如，3GPP类型的蜂窝网络)，电信网络2100包括接入网2102(例如，RAN)和核心网络2104。接入网2102包括多个基站2106A、2106B、2106C(例如，NB、eNB、gNB或其他类型的无线接入点(AP))，每个基站定义对应覆盖区域2108A、2108B、2108C。每个基站2106A、2106B、2106C通过有线或无线连接2110可连接到核心网络2104。位于覆盖区域2108C中的第一UE 2112被配置为以无线方式连接到对应基站2106C或被对应基站2106C寻呼。覆盖区域2108A中的第二UE 2114以无线方式可连接到对应基站2106A。虽然在该示例中示出了多个UE 2112、2114，但所公开的实施例同等地适用于唯一的UE处于覆盖区域中或者唯一的UE正连接到对应基站2106的情形。
电信网络2100自身连接到主机计算机2116，主机计算机2116可以以独立服务器、云实现的服务器、分布式服务器的硬件和/或软件来实现，或者被实现为服务器集群中的处理资源。主机计算机2116可以处于服务提供商的所有或控制之下，或者可以由服务提供商或代表服务提供商来操作。电信网络2100与主机计算机2116之间的连接2118和2120可以直接从核心网络2104延伸到主机计算机2116，或者可以经由可选的中间网络2122进行。中间网络2122可以是公共、私有或承载网络中的一个或多于一个的组合；中间网络2122(若存在)可以是骨干网或互联网；具体地，中间网络2122可以包括两个或更多个子网络(未示出)。
图21的通信系统作为整体实现了所连接的UE 2112、2114与主机计算机2116之间的连接。该连接可被描述为过顶(Over-the-Top，OTT)连接2124。主机计算机2116和所连接的UE 2112、2114被配置为使用接入网2102、核心网络2104、任何中间网络2122和可能的其他基础设施(未示出)作为中介，经由OTT连接2124来传送数据和/或信令。在OTT连接2124所经过的参与通信设备未意识到上行链路和下行链路通信的路由的意义上，OTT连接2124可以是透明的。例如，可以不向基站2106通知或者可以无需向基站2106通知具有源自主机计算机2116的要向所连接的UE 2112转发(例如，移交)的数据的输入下行链路通信的过去的路由。类似地，基站2106无需意识到源自UE 2112向主机计算机2116的输出上行链路通信的未来的路由。
图22示出了根据本公开的一些其他实施例的通信系统。现将参照图22来描述根据实施例的在先前段落中所讨论的UE、基站和主机计算机的示例实现方式。在通信系统2200中，主机计算机2202包括硬件2204，硬件2204包括通信接口2206，通信接口2206被配置为建立和维护与通信系统2200的不同通信设备的接口的有线或无线连接。主机计算机2202还包括处理电路2208，其可以具有存储和/或处理能力。具体地，处理电路2208可以包括适用于执行指令的一个或多个可编程处理器、ASIC、PFGA或它们的组合(未示出)。主机计算机2202还包括软件2210，其被存储在主机计算机2202中或可由主机计算机2202访问并且可由处理电路2208来执行。软件2210包括主机应用2212。主机应用2212可操作为向远程用户(例如，UE 2214)提供服务，UE 2214经由在UE 2214和主机计算机2202处端接的OTT连接2216来连接。在向远程用户提供服务时，主机应用2212可以提供使用OTT连接2216来发送的用户数据。
通信系统2200还包括在电信系统中提供的基站2218，基站2218包括使其能够与主机计算机2202和与UE 2214进行通信的硬件2220。硬件2220可以包括：通信接口2222，其用于建立和维护与通信系统2200的不同通信设备的接口的有线或无线连接；以及无线电接口2224，其用于至少建立和维护与位于基站2218所服务的覆盖区域(图22中未示出)中的UE2214的无线连接2226。通信接口2222可以被配置为促进到主机计算机2202的连接2228。连接2228可以是直接的，或者它可以经过电信系统的核心网络(图22中未示出)和/或经过电信系统外部的一个或多个中间网络。在所示实施例中，基站2218的硬件2220还包括处理电路2230，处理电路2230可以包括适用于执行指令的一个或多个可编程处理器、ASIC、FPGA或它们的组合(未示出)。基站2218还具有内部存储的或经由外部连接可访问的软件2232。
通信系统2200还包括已经提及的UE 2214。UE 2214的硬件2234可以包括无线电接口2236，其被配置为建立和维护与服务于UE 2214当前所在的覆盖区域的基站的无线连接2226。UE 2214的硬件2234还包括处理电路2238，其可以包括适用于执行指令的一个或多个可编程处理器、ASIC、FPGA或它们的组合(未示出)。UE 2214还包括软件2240，其被存储在UE2214中或可由UE 2214访问并可由处理电路2238执行。软件2240包括客户端应用2242。客户端应用2242可操作为在主机计算机2202的支持下经由UE 2214向人类或非人类用户提供服务。在主机计算机2202中，执行的主机应用2212可以经由端接在UE 2214和主机计算机2202处的OTT连接2216与执行客户端应用2242进行通信。在向用户提供服务时，客户端应用2242可以从主机应用2212接收请求数据，并响应于请求数据来提供用户数据。OTT连接2216可以传送请求数据和用户数据二者。客户端应用2242可以与用户进行交互，以生成其提供的用户数据。
注意，图22所示的主机计算机2202、基站2218和UE 2214可以分别与图21的主机计算机2116、基站2106A、2106B、2106C之一和UE 2112、2114之一相似或相同。也就是说，这些实体的内部工作可以如图22所示，并且独立地，周围网络拓扑可以是图21的网络拓扑。
在图22中，已经抽象地绘制OTT连接2216，以示出经由基站2218在主机计算机2202与UE 2214之间的通信，而没有明确地提到任何中间设备以及经由这些设备的消息的精确路由。网络基础设施可以确定该路由，该路由可以被配置为向UE 2214隐藏或向操作主机计算机2202的服务提供商隐藏或向这二者隐藏。在OTT连接2216活动时，网络基础设施还可以(例如，基于负载均衡考虑或网络的重新配置)做出其动态地改变路由的决策。
UE 2214与基站2218之间的无线连接2226根据贯穿本公开所描述的实施例的教导。各种实施例中的一个或多个实施例改进了使用OTT连接2216向UE 2214提供的OTT服务的性能，其中无线连接2226形成OTT连接2216中的最后一段。更精确地，这些实施例的教导可以减少针对在RRC_INACTIVE状态下的UE执行释放和重定向所需要的时间，从而提供诸如改进的UE的响应性、UE与网络实体之间的减少的信令、以及减少的UE的功耗的益处。
出于监视一个或多个实施例改进的数据速率、时延和其他因素的目的，可以提供测量过程。还可以存在用于响应于测量结果的变化而重新配置主机计算机2202与UE 2214之间的OTT连接2216的可选网络功能。用于重新配置OTT连接2216的测量过程和/或网络功能可以以主机计算机2202的软件2210和硬件2204或以UE 2214的软件2240和硬件2234或以这二者来实现。在实施例中，传感器(未示出)可被部署在OTT连接2216经过的通信设备中或与OTT连接2216经过的通信设备相关联地来部署；传感器可以通过提供以上例示的监视量的值或提供软件2210、2240可以用来计算或估计监视量的其他物理量的值来参与测量过程。对OTT连接2216的重新配置可以包括消息格式、重传设置、优选路由等；该重新配置不需要影响基站2218，并且其对于基站2218来说可以是未知的或不可感知的。这种过程和功能在本领域中可以是已知的和已被实践的。在特定实施例中，测量可以涉及促进主机计算机2202对吞吐量、传播时间、时延等的测量的专有UE信令。该测量可以如下实现：软件2210和2240在其监视传播时间、差错等的同时使得能够使用OTT连接2216来发送消息(具体地，空消息或“假”消息)。
图23是示出了根据本公开的一些实施例的在通信系统中实现的方法的流程图。该通信系统包括主机计算机、基站和UE，其可以是参照图21和图22描述的主机计算机、基站和UE。为了本公开的简明，在本部分中将仅包括对图23的图引用。在步骤2300中，主机计算机提供用户数据。在步骤2300的子步骤2302(其可以是可选的)中，主机计算机通过执行主机应用来提供用户数据。在步骤2304中，主机计算机发起向UE的携带用户数据的传输。在步骤2306(其可以是可选的)中，根据贯穿本公开所描述的实施例的教导，基站向UE发送在主机计算机发起的传输中所携带的用户数据。在步骤2308(其也可以是可选的)中，UE执行与主机计算机所执行的主机应用相关联的客户端应用。
图24是示出了根据本公开的一些实施例的在通信系统中实现的方法的流程图。该通信系统包括主机计算机、基站和UE，其可以是参照图21和图22描述的主机计算机、基站和UE。为了本公开的简明，在本部分中将仅包括对图24的图引用。在方法的步骤2400中，主机计算机提供用户数据。在可选子步骤(未示出)中，主机计算机通过执行主机应用来提供用户数据。在步骤2402中，主机计算机发起向UE的携带用户数据的传输。根据贯穿本公开描述的实施例的教导，该传输可以经由基站。在步骤2404(其可以是可选的)中，UE接收传输中所携带的用户数据。
图25是示出了根据本公开的一些实施例的在通信系统中实现的方法的流程图。该通信系统包括主机计算机、基站和UE，其可以是参照图21和图22描述的主机计算机、基站和UE。为了本公开的简明，在本部分中将仅包括对图25的图引用。在步骤2500(其可以是可选的)中，UE接收由主机计算机所提供的输入数据。附加地或备选地，在步骤2502中，UE提供用户数据。在步骤2500的子步骤2504(其可以是可选的)中，UE通过执行客户端应用来提供用户数据。在步骤2502的子步骤2506(其可以是可选的)中，UE执行客户端应用，该客户端应用回应于接收到的主机计算机提供的输入数据来提供用户数据。在提供用户数据时，所执行的客户端应用还可以考虑从用户接收的用户输入。无论提供用户数据的具体方式如何，UE在子步骤2508(其可以是可选的)中都发起用户数据向主机计算机的传输。在方法的步骤2510中，根据贯穿本公开描述的实施例的教导，主机计算机接收从UE发送的用户数据。
图26是示出了根据本公开的一些实施例的在通信系统中实现的方法的流程图。该通信系统包括主机计算机、基站和UE，其可以是参照图21和图22描述的主机计算机、基站和UE。为了本公开的简明，在本部分中将仅包括对图26的图引用。在步骤2600(其可以是可选的)中，根据贯穿本公开描述的实施例的教导，基站从UE接收用户数据。在步骤2602(其可以是可选的)中，基站发起接收到的用户数据向主机计算机的传输。在步骤2604(其可以是可选的)中，主机计算机接收由基站所发起的传输中所携带的用户数据。
可以通过一个或多个虚拟装置的一个或多个功能单元或模块来执行本文公开的任何适合的步骤、方法、特征、功能或益处。每个虚拟装置可以包括多个这些功能单元。这些功能单元可以通过处理电路实现，处理电路可以包括一个或多个微处理器或微控制器以及其他数字硬件(可以包括数字信号处理器(DSP)、专用数字逻辑等)。处理电路可以被配置为执行存储在存储器中的程序代码，该存储器可以包括一种或若干类型的存储器，例如只读存储器(ROM)、随机存取存储器(RAM)、高速缓存存储器、闪存设备、光学存储设备等。存储在存储器中的程序代码包括用于执行一种或多种电信和/或数据通信协议的程序指令，以及用于执行本文所述的一种或多种技术的指令。在一些实现中，处理电路可用于使相应功能单元根据本公开的一个或多个实施例执行对应功能。
虽然附图中的过程示出了本公开的某些实施例执行的特定操作顺序，但是应当理解，这种顺序是示例性的(例如，备选实施例可以以不同的顺序执行操作、组合某些操作、重叠某些操作等)。
实施例
本公开的以下示例性实施例是说明性的而不是限制性的。
A组实施例
1.一种由UE执行的用于在电信网络内进行通信的方法，所述方法包括：当在RRC_INACTIVE状态下时，向基站发送用于恢复通信的请求，并且在没有进入RRC_CONNECTED状态的情况下，从基站接收用于释放和重定向的指令；以及响应于接收到用于释放和重定向的指令，以RAT执行小区选择，并尝试恢复与所选择的小区的通信。
2.根据实施例1的方法，其中，用于恢复通信的请求包括RRC恢复请求消息。
3.根据实施例1或2的方法，其中，用于释放和重定向的指令包括RRC释放消息。
4.根据实施例1至3中任一实施例的方法，其中，用于释放和重定向的指令标识要在其中执行小区选择的RAT。
5.根据实施例1至4中任一实施例的方法，其中，要在其中执行小区选择的RAT包括NR频率或LTE频率。
B组实施例
6.一种由基站执行的用于在电信网络内与UE进行通信的方法，该方法包括：从在RRC INACTIVE状态下的UE接收用于恢复通信的请求；以及响应于接收到用于恢复通信的请求，并且在没有首先向UE发送用于恢复的指令的情况下，向UE发送用于释放和重定向的指令。
7.根据实施例6的方法，其中，用于恢复通信的请求包括RRC恢复请求消息。
8.根据实施例6或7的方法，其中，用于释放和重定向的指令包括RRC释放消息。
9.根据实施例6至8中任一实施例的方法，其中，用于释放和重定向的指令标识要在其中执行小区选择的RAT。
10.根据实施例6至9中任一实施例的方法，其中，要在其中执行小区选择的RAT包括NR频率或LTE频率。
11.根据实施例6至10中任一实施例的方法，还包括：在发送用于释放和重定向的指令之前，执行上下文重定位。
12.根据实施例12的方法，其中，执行上下文重定位还包括以下步骤：从上一个服务基站检索与UE相关联的上下文；向AMF发送路径切换请求；以及从AMF接收路径切换请求响应。
13.根据实施例11或12的方法，还包括：在发送用于释放和重定向的指令之后，向上一个服务基站发送用于释放UE上下文的指令。
C组实施例
14.一种用于在电信网络内通信的无线设备，该无线设备包括：处理电路，被配置为执行A组实施例中任一实施例的任何步骤；以及电源电路，被配置为向无线设备供电。
15.一种用于在电信网络内与UE通信的基站，该基站包括：处理电路，被配置为执行B组实施例中任一实施例的任何步骤；以及电源电路，被配置为向基站供电。
16.一种用于在电信网络内通信的UE，该UE包括：天线，被配置为发送和接收无线信号；无线电前端电路，连接到天线和处理电路，并被配置为调节在天线和处理电路之间传送的信号；处理电路，被配置为执行A组实施例中任一实施例的任何步骤；输入接口，连接到处理电路，并被配置为允许信息输入到UE中以由处理电路处理；输出接口，连接到处理电路，并被配置为从UE输出已经由处理电路处理的信息；以及电池，连接到处理电路并被配置为向UE供电。
17.一种通信系统，包括主机计算机，该主机计算机包括：处理电路，被配置为提供用户数据；以及通信接口，被配置为将用户数据转发给蜂窝网络以用于传输给UE，其中，该蜂窝网络包括具有无线电接口和处理电路的基站，该基站的处理电路被配置为执行B组实施例中任一实施例的任何步骤。
18.根据前述实施例的通信系统，还包括基站。
19.根据前述两个实施例的通信系统，还包括UE，其中，UE被配置为与基站通信。
20.根据前述三个实施例的通信系统，其中：主机计算机的处理电路被配置为执行主机应用，从而提供用户数据；并且UE包括处理电路，该处理电路被配置为执行与主机应用相关联的客户端应用。
21.一种在包括主机计算机、基站和UE的通信系统中实现的方法，该方法包括：在主机计算机处，提供用户数据；以及在主机计算机处，经由包括基站在内的蜂窝网络发起向UE的携带用户数据的传输，其中，基站执行B组实施例中任一实施例的任何步骤。
22.根据前述实施例的方法，还包括：在基站处，发送用户数据。
23.根据前述两个实施例的方法，其中，通过执行主机应用在主机计算机处提供用户数据，该方法还包括：在UE处执行与主机应用相关联的客户端应用。
24.一种UE，被配置为与基站通信，该UE包括无线电接口和处理电路，处理电路被配置为执行前述三个实施例的方法。
25.一种通信系统，包括主机计算机，该主机计算机包括：处理电路，被配置为提供用户数据；以及通信接口，被配置为将用户数据转发给蜂窝网络以用于传输给UE，其中，该UE包括无线电接口和处理电路，该UE的处理电路被配置为执行A组实施例中任一实施例的任何步骤。
26.根据前述实施例的通信系统，其中，蜂窝网络还包括被配置为与UE通信的基站。
27.根据前述两个实施例的通信系统，其中：主机计算机的处理电路被配置为执行主机应用，从而提供用户数据；并且UE的处理电路被配置为执行与主机应用相关联的客户端应用。
28.一种在包括主机计算机、基站和UE的通信系统中实现的方法，该方法包括：在主机计算机处，提供用户数据；以及在主机计算机处，发起经由包括基站在内的蜂窝网络向UE的携带用户数据的传输，其中，UE执行A组实施例中任一实施例的任何步骤。
29.根据前述实施例的方法，还包括：在UE处，从基站接收用户数据。
30.一种通信系统，包括主机计算机，该主机计算机包括：通信接口，被配置为接收源自从UE到基站的传输的用户数据，其中，该UE包括无线电接口和处理电路，该UE的处理电路被配置为执行A组实施例中任一实施例的任何步骤。
31.根据前述实施例的通信系统，还包括UE。
32.根据前述两个实施例的通信系统，还包括基站，其中基站包括：无线电接口，被配置为与UE通信；以及通信接口，被配置为将从UE到基站的传输所携带的用户数据转发给主机计算机。
33.根据前述三个实施例的通信系统，其中：主机计算机的处理电路被配置为执行主机应用；并且UE的处理电路被配置为执行与主机应用相关联的客户端应用，从而提供用户数据。
34.根据前述四个实施例的通信系统，其中：主机计算机的处理电路被配置为执行主机应用，从而提供请求数据；并且UE的处理电路被配置为执行与主机应用相关联的客户端应用，从而响应于请求数据而提供用户数据。
35.一种在包括主机计算机、基站和UE的通信系统中实现的方法，该方法包括：在主机计算机处，接收从UE向基站传输的用户数据，其中，UE执行A组实施例中任一实施例的任何步骤。
36.根据前述实施例的方法，还包括：在UE处，向基站提供用户数据。
37.根据前述两个实施例的方法，还包括：在UE处，执行客户端应用，从而提供要发送的用户数据；并且在主机计算机处，执行与客户端应用相关联的主机应用。
38.根据前述三个实施例的方法，还包括：在UE处，执行客户端应用；以及在UE处，接收对客户端应用的输入数据，输入数据是通过执行与客户端应用相关联的主机应用在主机计算机处提供的；其中，要发送的用户数据是客户端应用响应于输入数据而提供的。
39.一种通信系统，包括主机计算机，该主机计算机包括通信接口，该通信接口被配置为接收源自从UE到基站的传输的用户数据，其中，基站包括无线电接口和处理电路，基站的处理电路被配置为执行B组实施例中任一实施例的任何步骤。
40.根据前述实施例的通信系统，还包括基站。
41.根据前述两个实施例的通信系统，还包括UE，其中，UE被配置为与基站通信。
42.根据前述三个实施例的通信系统，其中：主机计算机的处理电路被配置为执行主机应用；并且UE被配置为执行与主机应用相关联的客户端应用，从而提供要由主机计算机接收的用户数据。
43.一种在包括主机计算机、基站和UE的通信系统中实现的方法，该方法包括：在主机计算机处，从基站接收源自基站已经从UE接收到的传输的用户数据，其中，UE执行A组实施例中任一实施例的任何步骤。
44.根据前述实施例的方法，还包括：在基站处，从UE接收用户数据。
45.根据前述两个实施例的方法，还包括：在基站处，发起对接收到的用户数据向主机计算机的传输。
在本公开中可以使用以下缩略语中的至少一些。如果缩略语之间存在不一致，则应优先考虑上面如何使用它。如果在下面多次列出，则首次列出应优先于任何后续列出。
3G 第三代
3GPP 第三代合作伙伴计划
4G 第四代
5G 第五代
5GS 第五代系统
5GMM 第五代系统移动性管理
5GC 第五代核心网络
5G-S-TMSI 第五代-系统架构演进-临时移动订户标识
AF 应用功能
AMF 接入和移动性管理功能
AN 接入网
AP 接入点
ARFCN 绝对射频信道号
AS 接入层
ASIC 专用集成电路
AUSF 认证服务器功能
CA 载波聚合
CN 核心网络
CPU 中央处理单元
C-RNTI 小区无线电网络临时标识符
DC 双连接
DL 下行链路
DN 数据网络
DRB 数据无线电承载
DRX 不连续接收
DSP 数字信号处理器
eNB 增强或演进型节点B
EPC 增强或演进的分组核心
E-UTRA 演进的通用陆地无线电接入
E-UTRAN 演进的通用陆地无线电接入网
FDD 频分双工
FFS 有待进一步研究
FPGA 现场可编程门阵列
gNB 新无线电基站
ID 标识符/标识
IP 网际协议
I-RNTI 针对RRC_INACTIVE状态的无线电网络临时标识符
LS 联络声明
LTE 长期演进
MA 移动授权
MAC 媒体访问控制
MCG 主小区组
MCS 任务关键的支持
MME 移动性管理实体
MO 移动始发
MPS 多媒体优先级服务
MT 移动终止
MTC 机器类型通信
NAS 非接入层
NB 窄带
NCC 下一跳链接计数器
NEF 网络开放功能
NF 网络功能
NH 下一跳
NR 新无线电
NRF 网络存储库功能
NSSF 网络切片选择功能
OTT 过顶
Pcell 主小区
PCF 策略控制功能
PDCP 分组数据会聚协议
PDU 协议数据单元
P-GW 分组数据网络网关
PLMN 公共陆地移动网络
QoS 服务质量
RAM 随机存取存储器
RAN 无线电接入网
RAT 无线电接入技术
RLC 无线电链路控制
RNA 无线电网络子系统应用部分用户自适应
RNAU 无线电网络子系统应用部分用户自适应更新
RNTI 无线电网络临时标识符
ROHC 鲁棒报头压缩
ROM 只读存储器
RRC 无线电资源控制
RRH 远程无线电头端
RTT 往返时间
SAE 系统架构演进
SAP 服务接入点
SCEF 服务能力开放功能
Scell 辅小区
SCG 辅小区组
SDAP 服务数据适配协议
SMF 会话管理功能
SMS 短消息服务
SpCell 特殊小区
SRB 信令无线电承载
TMSI 临时移动订户标识
TS 技术规范
UDM 统一数据管理
UE 用户设备
UTRA 通用陆地无线电接入
UTRAN 通用陆地无线电接入网
VOIP 网际协议语音
X2AP X2接口应用协议
XnAP Xn接口应用协议
本领域技术人员将认识到对本公开的实施例的改进和修改。所有这些改进和修改被认为落入本文公开的构思的范围内。

Claims (18)

1.一种由无线设备执行的用于在电信网络内进行通信的方法，所述方法包括：
当在无线电资源控制RRC非活动状态下时，向基站发送(600)用于恢复通信的请求，其特征在于：
在没有进入RRC连接状态的情况下，从所述基站接收(604)用于释放和重定向的指令；以及
响应于接收到所述用于释放和重定向的指令，以一无线电接入技术RAT执行(614)小区选择，并且尝试建立(620)或恢复(618)与所选择的小区的通信。
2.根据权利要求1所述的方法，其中，所述用于恢复通信的请求包括RRC恢复请求消息，以及所述用于释放和重定向的指令包括RRC释放消息。
3.根据权利要求1至2中任一项所述的方法，其中，所述用于释放和重定向的指令标识将用于执行小区选择的所述RAT。
4.根据权利要求1至2中任一项所述的方法，其中，将用于执行小区选择的所述RAT包括新无线电NR频率或长期演进LTE频率。
5.根据权利要求1至2中任一项所述的方法，其中，尝试建立或恢复与所选择的小区的通信包括：尝试建立与所选择的小区的通信。
6.根据权利要求5所述的方法，其中，尝试建立与所选择的小区的通信包括：执行RRC建立过程。
7.根据权利要求1至2中任一项所述的方法，其中，尝试建立或恢复与所选择的小区的通信包括：尝试恢复与所选择的小区的通信。
8.根据权利要求7所述的方法，其中，尝试恢复与所选择的小区的通信包括：执行RRC恢复过程。
9.一种由基站执行的用于在电信网络内与无线设备进行通信的方法，所述方法包括：
从在无线电资源控制RRC非活动状态下的所述无线设备接收(700)用于恢复通信的请求，其特征在于：
响应于接收到所述用于恢复通信的请求，并且在没有首先向所述无线设备发送用于恢复的指令的情况下，向所述无线设备发送(706)用于释放和重定向的指令。
10.根据权利要求9所述的方法，其中，所述用于恢复通信的请求包括RRC恢复请求消息，以及所述用于释放和重定向的指令包括RRC释放消息。
11.根据权利要求9所述的方法，其中，所述用于释放和重定向的指令标识将用于执行小区选择的无线电接入技术RAT。
12.根据权利要求9所述的方法，其中，将用于执行小区选择的所述RAT包括新无线电NR频率或长期演进LTE频率。
13.根据权利要求9所述的方法，还包括：在发送所述用于释放和重定向的指令之前，执行上下文重定位。
14.根据权利要求13所述的方法，其中，执行所述上下文重定位还包括以下步骤：
从上一个服务基站检索与所述无线设备相关联的上下文；
向接入和移动性管理功能AMF发送路径切换请求；以及
从所述AMF接收路径切换请求响应。
15.根据权利要求13或14所述的方法，还包括：在发送所述用于释放和重定向的指令之后，向所述上一个服务基站发送用于释放与所述无线设备相关联的上下文的指令。
16.一种用于在电信网络内进行通信的无线设备(1900)，所述无线设备包括：
一个或多个处理器(1902)；以及
存储器(1904)，存储能够由所述一个或多个处理器执行的指令，由此所述无线设备可操作以执行根据权利要求1至8中任一项所述的方法。
17.一种用于在电信网络内与无线设备进行通信的基站(1700)，所述基站被配置为：
一个或多个处理器(1604)；以及
存储器(1606)，存储能够由所述一个或多个处理器执行的指令，由此所述基站可操作以执行根据权利要求9至15中任一项所述的方法。
18.一种计算机可读存储介质，在所述计算机可读存储介质上存储有计算机程序，所述计算机程序包括指令，所述指令当在至少一个处理器上执行时使所述至少一个处理器执行如由无线设备(1900)或基站(1700)执行的根据权利要求1至15中任一项所述的方法。
CN201980062426.0A 2018-09-25 2019-06-27 恢复请求随后释放和重定向 Active CN112740824B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201862736332P 2018-09-25 2018-09-25
US62/736,332 2018-09-25
PCT/SE2019/050627 WO2020067944A1 (en) 2018-09-25 2019-06-27 Resume request followed by release and redirect

Publications (2)

Publication Number Publication Date
CN112740824A CN112740824A (zh) 2021-04-30
CN112740824B true CN112740824B (zh) 2024-06-04

Family

ID=67211796

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980062426.0A Active CN112740824B (zh) 2018-09-25 2019-06-27 恢复请求随后释放和重定向

Country Status (12)

Country Link
US (3) US11924693B2 (zh)
EP (3) EP3677089B1 (zh)
JP (1) JP7145319B2 (zh)
CN (1) CN112740824B (zh)
BR (1) BR112021004810A2 (zh)
CO (1) CO2021004048A2 (zh)
DK (1) DK3826422T3 (zh)
ES (2) ES2888407T3 (zh)
HU (1) HUE054234T2 (zh)
PL (1) PL3677089T3 (zh)
PT (1) PT3826422T (zh)
WO (1) WO2020067944A1 (zh)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10667185B2 (en) * 2018-03-28 2020-05-26 Telefonaktiebolaget Lm Ericsson (Publ) Method for avoiding unnecessary actions in resume procedure
JP6970650B2 (ja) * 2018-09-20 2021-11-24 Kddi株式会社 待ち受け状態で通信を行う端末装置、その制御方法、及びプログラム
CN115996486A (zh) * 2018-10-04 2023-04-21 谷歌有限责任公司 用于处理无线电资源控制小区组配置的方法
WO2021025246A1 (en) * 2019-08-06 2021-02-11 Lg Electronics Inc. Method and apparatus for handling security information between a wireless device and a network for a fast rrc release procedure in a wireless communication system
EP4044759A4 (en) * 2019-11-07 2022-11-02 Huawei Technologies Co., Ltd. RADIO RESOURCE CONTROL (RRC) CONNECTION RESTORATION METHOD AND DEVICE
EP4122284A1 (en) * 2020-03-18 2023-01-25 Telefonaktiebolaget LM ERICSSON (PUBL) Determination of operational state
CN113840337B (zh) * 2020-06-23 2022-09-20 荣耀终端有限公司 一种提升终端寻呼响应速度的方法及终端
CN113905457B (zh) * 2020-07-06 2023-08-08 维沃移动通信有限公司 消息发送方法、接收方法、装置及通信设备
CN113905452B (zh) * 2020-07-06 2023-08-08 维沃移动通信有限公司 消息发送方法、接收方法、装置及通信设备
WO2022027612A1 (zh) * 2020-08-07 2022-02-10 华为技术有限公司 信令传输的方法和装置
BR102021016648A2 (pt) * 2020-08-26 2022-03-08 Nokia Technologies Oy Realocação de contexto de equipamento de usuário na borda de área de notificação de rede de acesso de rádio
US20220078875A1 (en) * 2020-09-08 2022-03-10 Asustek Computer Inc. Method and apparatus for timer control for rrc connection resume procedure in a wireless communication system
EP3968696A1 (en) * 2020-09-15 2022-03-16 Nokia Technologies Oy Ng based context release and data forwarding for multi-hop mobility
WO2022067660A1 (zh) * 2020-09-30 2022-04-07 华为技术有限公司 一种小区驻留方法及装置
WO2022082582A1 (en) * 2020-10-22 2022-04-28 Apple Inc. Rrc-based user data transmission in inactive state
GB2608262A (en) * 2021-05-11 2022-12-28 Samsung Electronics Co Ltd Improvements in and relating to proximity services in a telecommunication network
KR20230021425A (ko) * 2021-08-05 2023-02-14 김성훈 무선 이동 통신 시스템에서 rrc 연결을 재개하는 방법 및 장치
CN113727467A (zh) * 2021-09-24 2021-11-30 Oppo广东移动通信有限公司 一种恢复rrc连接的方法、装置、芯片、设备及存储介质
WO2024031268A1 (en) * 2022-08-08 2024-02-15 Zte Corporation Methods and devices for determining target cell id for mac-i calculation
CN115499886A (zh) * 2022-08-09 2022-12-20 华为技术有限公司 一种mps管理方法及相关装置
US12022383B1 (en) 2023-11-10 2024-06-25 T-Mobile Usa, Inc. Radio exposure function for telecommunications networks

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017135779A1 (ko) * 2016-02-05 2017-08-10 엘지전자 주식회사 무선 통신 시스템에서 rrc 연결 재개를 수행하는 방법 및 장치
CN107079509A (zh) * 2014-11-07 2017-08-18 瑞典爱立信有限公司 用于暂停和恢复ran‑cn连接的方法、ran节点和移动性管理节点
CN108076536A (zh) * 2016-11-11 2018-05-25 诺基亚技术有限公司 用于无线网络中的双连接和互通的连接控制

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114449603B (zh) 2012-12-24 2024-06-07 北京三星通信技术研究有限公司 无线通信系统中的基站及由其执行的方法
CN107615828B (zh) 2015-05-15 2021-10-26 夏普株式会社 终端装置、基站装置以及方法
BR112017014947A2 (pt) 2016-01-08 2018-03-13 Ericsson Telefon Ab L M ?método de controle de recurso de rádio, produto de programa de computador, sistema de memória, entidades de rede de comunicação e de terminal, terminal, e, método de realização de um processo de controle de admissão durante uma operação de retomada do controle de recurso de rádio?
US10470218B2 (en) 2016-05-16 2019-11-05 Cisco Technology, Inc. System and method for optimized idle and active state transitions of user equipment in a network environment
US10028254B2 (en) * 2016-12-13 2018-07-17 Qualcomm Incorporated Techniques for improved decoding of system information blocks
KR102582554B1 (ko) * 2017-01-03 2023-09-25 삼성전자 주식회사 차세대 이동 통신 시스템에서 light connection을 지원하는 방법 및 장치
ES2900501T3 (es) * 2017-01-05 2022-03-17 Nec Corp Estación base, terminal inalámbrica, y métodos y medios legibles por ordenador no transitorios para los mismos
EP3806575A1 (en) 2017-01-16 2021-04-14 Telefonaktiebolaget Lm Ericsson (Publ) Tracking area update in rrc_inactive
US10624150B2 (en) 2017-01-30 2020-04-14 FG Innovation Company Limited Radio resource control connection resume method of wireless communication system
CN110546975B (zh) * 2017-03-17 2021-06-04 三星电子株式会社 无线电接入网络通知区域更新失败
US11184785B2 (en) 2017-03-17 2021-11-23 Qualcomm Incorporated Radio measurement and configuration
WO2019233119A1 (en) * 2018-06-06 2019-12-12 Huawei Technologies Co., Ltd. System and method for supporting measurements and mobility in a wireless communications system
EP3609289A1 (en) 2018-08-10 2020-02-12 Nokia Technologies Oy Combined rrc inactive resume, rrc rna & nas registration procedure

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107079509A (zh) * 2014-11-07 2017-08-18 瑞典爱立信有限公司 用于暂停和恢复ran‑cn连接的方法、ran节点和移动性管理节点
WO2017135779A1 (ko) * 2016-02-05 2017-08-10 엘지전자 주식회사 무선 통신 시스템에서 rrc 연결 재개를 수행하는 방법 및 장치
CN108076536A (zh) * 2016-11-11 2018-05-25 诺基亚技术有限公司 用于无线网络中的双连接和互通的连接控制

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Huawei, HiSilicon.R2-1803250 "Remaining issues on State transition between RRC CONNECTED and INACTIVE".3GPP tsg_ran\WG2_RL2.2018,(第TSGR2_101期),全文. *
OPPO. "R2-1804555-Discussion on RRC Resume procedure from inactive to inactive or idle".3GPP tsg_ran\WG2_RL2.2018,全文. *

Also Published As

Publication number Publication date
PT3826422T (pt) 2022-07-05
US11937131B2 (en) 2024-03-19
EP3826422A1 (en) 2021-05-26
US11924693B2 (en) 2024-03-05
JP7145319B2 (ja) 2022-09-30
CN112740824A (zh) 2021-04-30
JP2022500898A (ja) 2022-01-04
EP3677089A1 (en) 2020-07-08
EP4096344A1 (en) 2022-11-30
US20220159518A1 (en) 2022-05-19
BR112021004810A2 (pt) 2021-06-01
EP4096344C0 (en) 2023-08-23
ES2888407T3 (es) 2022-01-04
US20240137817A1 (en) 2024-04-25
EP3826422B1 (en) 2022-06-08
US20200314700A1 (en) 2020-10-01
HUE054234T2 (hu) 2021-08-30
CO2021004048A2 (es) 2021-04-30
EP4096344B1 (en) 2023-08-23
PL3677089T3 (pl) 2021-08-02
WO2020067944A1 (en) 2020-04-02
EP3677089B1 (en) 2021-01-13
DK3826422T3 (da) 2022-08-01
ES2961827T3 (es) 2024-03-14

Similar Documents

Publication Publication Date Title
CN112740824B (zh) 恢复请求随后释放和重定向
RU2764259C1 (ru) Способ для активизации или деактивизации соединения плоскости пользователя в каждом сеансе
US11943676B2 (en) Switching between network based and relay based operation for mission critical voice call
US11095645B2 (en) Virtualization of the evolved packet core to create a local EPC
US11284468B2 (en) Suspending/resuming measurements in RRC inactive state
WO2019196783A1 (en) Handling qos flow without a mapping data radio bearer
WO2020167170A1 (en) A master node, a secondary node, a user equipment and methods therein for handling of a seconday cell group (scg)
TWI792415B (zh) Ue和網路之間的多存取pdu會話狀態同步
EP4046461A1 (en) Signaling delivery in a wireless network
US20220256407A1 (en) Handling of ue in cm-connected state with rrc inactive state
CA3179413A1 (en) 5g multicast broadcast service handover

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant