CN112040554A - 移动终止提前数据传送和预配置上行链路资源方法和设备 - Google Patents

Abstract

本发明公开一种方法和设备。在一实例中，从用户设备的角度，用户设备从网络节点接收指示移动终止提前数据传送的寻呼消息。响应于接收到寻呼消息，用户设备确定与一个或多个预配置上行链路资源相关联的时序参数的有效性。用户设备基于有效性确定是发起用于移动终止提前数据传送的随机接入程序还是发起使用一个或多个预配置上行链路资源的传送。

Description

移动终止提前数据传送和预配置上行链路资源方法和设备

相关申请案的交叉参考

本申请案要求2019年6月3日提交的第62/856,643号美国临时专利申请案的权益，所述美国临时专利申请案的全部公开内容以全文引用的方式并入本文中。

技术领域

本公开大体上涉及无线通信网络，且更具体地说，涉及无线通信***中用于移动终止提前数据传送(Mobile-terminated Early Data Transmission，MT-EDT)和预配置上行链路资源(Preconfigured Uplink Resource，PUR)的方法和设备。

背景技术

随着往来移动通信装置的大量数据的通信需求的快速增长，传统的移动语音通信网络演进成与互联网协议(Internet Protocol，IP)数据包通信的网络。此类IP数据包通信可以为移动通信装置的用户提供IP承载语音、多媒体、多播和点播通信服务。

示例性网络结构是演进型通用陆地无线电接入网(Evolved UniversalTerrestrial Radio Access Network，E-UTRAN)。E-UTRAN***可提供高数据吞吐量以便实现上述IP承载语音及多媒体服务。目前，3GPP标准组织正在讨论新下一代(例如，5G)无线电技术。因此，目前在提交和考虑对3GPP标准的当前主体的改变以使3GPP标准演进和完成。

发明内容

根据本公开，提供一种或多种装置和/或方法。在一实例中，从用户设备(UserEquipment，UE)的角度，所述用户设备从网络节点接收指示移动终止提前数据传送(MT-EDT)的寻呼消息。响应于接收到所述寻呼消息，所述UE确定与一个或多个预配置上行链路资源(PUR)相关联的时序参数的有效性。所述UE基于所述有效性确定是发起用于MT-EDT的随机接入(Random Access，RA)程序还是发起使用所述一个或多个预配置上行链路资源的传送。

附图说明

图1示出根据一个示例性实施例的无线通信***的图。

图2是根据一个示例性实施例的传送器***(也被称作接入网络)和接收器***(也被称作用户设备或UE)的框图。

图3是根据一个示例性实施例的通信***的功能框图。

图4是根据一个示例性实施例的图3的程序代码的功能框图。

图5是根据一个示例性实施例的说明与经建立用于控制平面蜂窝式物联网(Cellular Internet of Thing，CIoT)演进型分组***(Evolved Packet System，EPS)优化的无线电资源控制(Radio Resource Control，RRC)连接相关联的示例性情形的图。

图6是根据一个示例性实施例的说明与RRC连接暂停程序相关联的示例性情形的图。

图7是根据一个示例性实施例的说明与RRC连接恢复程序相关联的示例性情形的图。

图8是根据一个示例性实施例的说明与RRC连接恢复程序相关联的示例性情形的图。

图9是根据一个示例性实施例的说明与用于控制平面CIoT EPS优化的提前数据传送(Early Data Transmission，EDT)相关联的示例性情形的图。

图10是根据一个示例性实施例的说明与用于用户平面CIoT EPS优化的EDT相关联的示例性情形的图。

图11是根据一个示例性实施例的说明与用于用户平面CIoT EPS优化的EDT相关联的示例性情形的图。

图12是根据一个示例性实施例的说明随机接入前导码格式的图。

图13是根据一个示例性实施例的说明上行链路-下行链路时序关系的图。

图14是根据一个示例性实施例的说明其中UE确定与预配置上行链路资源(PUR)时机相关联的持续时间的示例性情形的图。

图15是根据一个示例性实施例的说明其中UE在可配置时间段期间监视物理下行链路控制信道(Physical Downlink Control Channel，PDCCH)的示例性情形的图。

图16是根据一个示例性实施例的说明其中UE在可配置时间段期间监视PDCCH的示例性情形的图。

图17是根据一个示例性实施例的说明其中UE在可配置时间段期间监视PDCCH的示例性情形的图。

图18是根据一个示例性实施例的流程图。

图19是根据一个示例性实施例的流程图。

具体实施方式

下文描述的示例性无线通信***和装置采用支持广播服务的无线通信***。无线通信***经广泛部署以提供各种类型的通信，例如，语音、数据等等。这些***可基于码分多址(code division multiple access，CDMA)、时分多址(time division multipleaccess，TDMA)、正交频分多址(orthogonal frequency division multiple access，OFDMA)、第三代合作伙伴计划(3^rd Generation Partnership Project，3GPP)长期演进(Long Term Evolution，LTE)无线接入、3GPP高级长期演进(Long Term EvolutionAdvanced，LTE-A或LTE-高级)、3GPP2超移动宽带(Ultra Mobile Broadband，UMB)、WiMax、用于5G的3GPP新无线电(New Radio，NR)无线接入或一些其它调制技术。

确切地说，下文描述的示例性无线通信***装置可被设计成支持一个或多个标准，例如由名称为“第三代合作伙伴计划”(在本文中被称作3GPP)的联合体提供的标准，包含：3GPP TS 36.300 V15.5.0，“E-UTRA和E-UTRAN总体描述；阶段2(E-UTRA and E-UTRAN,Overall description,Stage 2)”；3GPP TS 36.331 V15.5.0，“E-UTRA、RRC协议规范(E-UTRA,RRC protocol specification)”；3GPP TS 36.304V15.2.0，“空闲模式中的E-UTRA用户设备(UE)程序(E-UTRA,User Equipment(UE)procedures in idle mode)”；3GPP RAN1#94***纪要；3GPP RAN1#94bis***纪要；3GPP RAN1#95***纪要；3GPP RAN1#96***纪要；3GPP RAN1#96bis***纪要；3GPP RAN1#97***纪要；3GPP TS 36.211 V15.5.0，“E-UTRA、物理信道和调制(E-UTRA,Physical channels and modulation)”。上文所列的标准和文献特此明确地以全文引用的方式并入。

图1呈现根据本公开的一个或多个实施例的多址无线通信***。接入网络100(access network，AN)包含多个天线群组，其中一个天线群组包含104和106，另一天线群组包含108和110，并且又一天线群组包含112和114。在图1中，针对每一天线群组仅示出两个天线，然而，每一天线群组可利用更多或更少的天线。接入终端116(access terminal，AT)与天线112和114通信，其中天线112和114通过前向链路120向接入终端116传送信息，并通过反向链路118从接入终端116接收信息。AT 122与天线106和108通信，其中天线106和108在前向链路126上传送信息到AT 122，且在反向链路124上从AT 122接收信息。在频分双工(frequency-division duplexing，FDD)***中，通信链路118、120、124和126可以使用不同频率用于通信。举例来说，前向链路120可使用与反向链路118所使用的频率不同的频率。

每一天线群组和/或其设计成在其中通信的区域通常被称作接入网络的扇区。在实施例中，天线群组各自可被设计成与接入网络100所覆盖区域的扇区中的接入终端通信。

在经由前向链路120和126的通信中，接入网络100的传送天线可利用波束成形以便改进不同接入终端116和122的前向链路的信噪比。并且，相比于通过单个天线传送到它的所有接入终端的接入网络，使用波束成形以传送到在接入网络的整个覆盖范围中随机分散的接入终端的所述接入网络通常会对相邻小区中的接入终端造成更少的干扰。

接入网络(AN)可为用于与终端通信的固定站或基站，且也可被称作接入点、节点B、基站、增强型基站、eNodeB(eNB)、下一代节点B(gNB)或某一其它术语。接入终端(AT)还可以被称作用户设备(UE)、无线通信装置、终端、接入终端或某一其它术语。

图2呈现多输入多输出(multiple-input and multiple-output，MIMO)***200中的传送器***210(也被称为接入网络)和接收器***250(也被称为接入终端(AT)或用户设备(UE))的实施例。在传送器***210处，可以将多个数据流的业务数据从数据源212提供到传送(transmit，TX)数据处理器214。

在一个实施例中，通过相应的传送天线传送每一数据流。TX数据处理器214基于针对每一数据流而选择的特定译码方案来格式化、译码及交错所述数据流的业务数据以提供经译码数据。

可使用正交频分多路复用(orthogonal frequency-division multiplexing，OFDM)技术将每一数据流的经译码数据与导频数据多路复用。导频数据通常可以是以已知方式处理的已知数据模式，且可以在接收器***处使用以估计信道响应。接着，可基于针对每个数据流而选择的特定调制方案(例如，二进制相移键控(binary phase shift keying，BPSK)、正交相移键控(quadrature phase shift keying，QPSK)、M进制相移键控(M-aryphase shift keying，M-PSK)，或M进制正交振幅调制(M-ary quadrature amplitudemodulation，M-QAM)等)来调制(即，符号映射)多路复用的导频和所述数据流的经译码数据，以提供调制符号。可以通过由处理器230执行的指令确定针对每个数据流的数据速率、译码和/或调制。

接着将数据流的调制符号提供给TX MIMO处理器220，所述TXMIMO处理器可进一步处理所述调制符号(例如，用于OFDM)。TX MIMO处理器220接着将N_T个调制符号流提供给N_T个传送器(transmitter，TMTR)222a至222t。在某些实施例中，TX MIMO处理器220可将波束成形权重应用于数据流的符号及从其传送所述符号的天线。

每一传送器222接收且处理相应符号流以提供一个或多个模拟信号，并且进一步调节(例如，放大、滤波和/或上变频转换)所述模拟信号以提供适合于通过MIMO信道传送的经调制信号。接着，可以分别从N_T个天线224a至224t传送来自传送器222a至222t的N_T个已调制信号。

在接收器***250处，通过N_R个天线252a至252r接收所传送的经调制信号，并且可以将从每一天线252接收的信号提供到相应接收器(receiver，RCVR)254a至254r。每个接收器254可调节(例如，滤波、放大和降频转换)相应的所接收信号、将已调节信号数字化以提供样本，和/或进一步处理所述样本以提供对应的“所接收”符号流。

RX数据处理器260接着基于特定接收器处理技术从N_R个接收器254接收和/或处理N_R个接收到的符号流以提供N_T个“检测到的”符号流。RX数据处理器260接着可以对每一检测到的符号流解调、解交错和/或解码以恢复用于数据流的业务数据。由RX数据处理器260进行的处理可与由传送器***210处的TX MIMO处理器220和TX数据处理器214执行的处理互补。

处理器270可周期性地确定要使用哪个预译码矩阵(下文论述)。处理器270制定包括矩阵索引部分和秩值部分的反向链路消息。

反向链路消息可以包括与通信链路和/或接收到的数据流有关的各种类型的信息。反向链路消息随后可由TX数据处理器238(所述TX数据处理器还接收来自数据源236的多个数据流的业务数据)处理，由调制器280调制，由传送器254a至254r调节，和/或被传送回到传送器***210。

在传送器***210处，来自接收器***250的已调制信号由天线224接收、由接收器222调节、由解调器240解调，并由RX数据处理器242处理，以提取由接收器***250传送的反向链路消息。接着，处理器230可以确定使用哪一预译码矩阵以确定波束成形权重，接着可以处理所提取的消息。

图3呈现根据所公开主题的一个实施例的通信装置的替代简化功能框图。如图3中所示，可以利用无线通信***中的通信装置300以用于实现图1中的UE(或AT)116和122或图1中的基站(AN)100，并且无线通信***可为是LTE或NR***。通信装置300可以包含输入装置302、输出装置304、控制电路306、中央处理单元(central processing unit，CPU)308、存储器310、程序代码312以及收发器314。控制电路306通过CPU 308执行存储器310中的程序代码312，由此控制通信装置300的操作。通信装置300可接收由用户通过输入装置302(例如键盘或小键盘)输入的信号，且可通过输出装置304(例如监视器或扬声器)输出图像和声音。收发器314用于接收和传送无线信号、将所接收的信号递送到控制电路306、且无线地输出由控制电路306产生的信号。也可以利用无线通信***中的通信装置300以用于实现图1中的AN 100。

图4是根据所公开主题的一个实施例的在图3中所示的程序代码312的简化框图。在此实施例中，程序代码312包含应用层400、层3部分402和层2部分404，且耦合到层1部分406。层3部分402通常执行无线电资源控制。层2部分404可以执行链路控制。层1部分406可以执行和/或实施物理连接。

与LTE中的蜂窝式物联网(CIoT)信令减少优化和提前数据传送(EDT)相关的描述提供于3GPP TS 36.300 V15.5.0中。值得注意的是，3GPP TS 36.300 V15.5.0的标题为“经建立用于控制平面CIoT EPS优化的RRC连接(The RRC connection established forControl Plane CIoT EPS Optimizations)”的章节7.3a.2的图7.3a.2-1在本文中再现为图5。3GPP TS 36.300 V15.5.0的标题为“RRC连接暂停程序(RRC Connection Suspendprocedure)”的章节7.3a.3的图7.3a.3-1在本文中再现为图6。3GPP TS 36.300 V15.5.0的标题为“RRC连接恢复程序(RRC Connection Resume procedure)”的章节7.3a.3的图7.3a.3-2在本文中再现为图7。3GPP TS 36.300 V15.5.0的标题为“不同eNB中的RRC连接恢复程序(RRC Connection Resume procedure in different eNB)”的章节7.3a.3的图7.3a.3-3在本文中再现为图8。3GPP TS 36.300 V15.5.0的标题为“用于控制平面CIoT EPS优化的EDT(EDT for Control Plane CIoT EPS Optimizations)”的章节7.3b.2的图7.3b-1在本文中再现为图9。3GPP TS 36.300 V15.5.0的标题为“用于用户平面CIoT EPS优化的EDT(EDT for User Plane CIoTEPS Optimizations)”的章节7.3b.3的图7.3b-2在本文中再现为图10。3GPP TS 36.300 V15.5.0的标题为“用于不同eNB中的用户平面CIoT EPS优化的EDT(EDT for User Plane CIoT EPS Optimizations in different eNB)”的章节7.3b.3的图7.3b-3在本文中再现为图11。3GPP TS 36.300 V15.5.0的部分引述如下：

7.3NAS消息的传输

AS在小区中提供NAS消息的可靠依序递送。在切换期间，可能发生NAS消息的消息丢失或重复。

在E-UTRAN中，NAS消息与RRC消息串接或在RRC中载送而不串接。在相同UE的对于高优先级队列需要与RRC串接而对于较低优先级队列不需要串接的同时NAS消息到达时，所述消息首先根据需要排入列队以维持依序递送。

在下行链路中，在触发EPS承载(EPS bearer，EPC)或PDU会话(5GC)建立或释放程序时，或在控制平面CIoT EPS优化的情况下对于EDT，NAS消息通常应与相关联RRC消息串接。在修改EPS承载(EPC)或PDU会话(5GC)时以及在所述修改也取决于无线电承载的修改时，NAS消息与相关联RRC消息通常应串接。否则不允许DL NAS与RRC消息的串接。在上行链路中，NAS消息与RRC消息的串接仅用于在连接设置期间传送初始NAS消息且用于控制平面CIoT EPS优化情况下的EDT。初始直接传送不用于E-UTRAN中，且NAS消息不与RRC连接请求串接。

在EPS承载(EPC)或PDU会话(5GC)建立或修改期间，可在单个下行链路RRC消息中发送多个NAS消息。在此情况下，NAS消息在RRC消息中的次序应与在对应S1-AP(EPC)或NG-AP(5GC)消息中的次序相同，以便确保NAS消息的依序递送。

注释：除了由NAS执行的完整性保护和加密之外，NAS消息还通过PDCP来进行完整性保护和加密。

7.3a CIoT信令减少优化

7.3a.1总则

使用CIoT信令减少优化的哪一解决方案是经由UE与MME之间的NAS信令配置。

对于NB-IoT，在不激活AS安全性时不使用PDCP。

7.3a.2控制平面CIoT EPS优化

按照TS 24.301[20]中的定义，经建立用于控制平面CIoT EPS优化的RRC连接表征如下：

-载送数据的UL NAS信令消息或UL NAS消息可在UL RRC容器消息中传送(参见图7.3a.2-1)。DL NAS信令或DL NAS数据可在DL RRC容器消息中传送；

-对于NB-IoT：

-不支持RRC连接重新配置；

-不使用数据无线电承载(data radio bearer，DRB)；

-不使用AS安全性；

-在RRC连接建立或重新建立期间可对所有单播传送配置非锚载波。

-AS中的不同数据类型(即，IP、非IP或SMS)之间不存在区分。

图7.3a.2-1：经建立用于控制平面CIoT EPS优化的RRC连接

7.3a.3用户平面CIoT EPS优化

按照TS 24.301[20]中的定义，经建立用于用户平面CIoT EPS优化的RRC连接表征如下：

-在RRC连接释放时使用RRC连接暂停程序，eNB可在RRC_IDLE中请求UE保持包含UE能力的UE AS上下文；

-在从RRC_IDLE到RRC_CONNECTED的转变时使用RRC连接恢复程序，其中UE以及eNB中先前存储的信息用以恢复RRC连接。在恢复消息中，UE提供恢复ID以待由eNB用来存取恢复RRC连接所需要的所存储信息；

-在暂停恢复时，安全性继续。在RRC连接恢复程序中不支持重新键控。短MAC-I由UE重新使用为RRC连接重新建立程序和RRC连接恢复程序中的认证令牌。eNB也在RRCConnectionResume消息中提供NCC。而且，UE也使计数复位；

-不支持在从RRC_IDLE到RRC CONNECTED的转变中多路复用CCCH和DTCH；

-对于NB-IoT，在于建立RRC连接时另外重新建立、恢复或重新配置RRC连接时，可针对所有单播传送配置非锚载波。

图7.3a.3-1和7.3a.3-2中分别说明RRC连接暂停与恢复程序。应注意，此处的描述仅意欲为概述，且因此未在消息流中列出所有参数。

图7.3a.3-1：RRC连接暂停程序

1.由于一些触发项，例如UE不活动定时器到期，eNB决定暂停RRC连接。

2.eNB发起S1-AP UE上下文暂停程序以向MME通知RRC连接被暂停。

3.MME请求S-GW释放用于UE的所有S1-U承载。

4.MME确认步骤2。

5.eNB通过将RRCConnectionRelease消息与releaseCause集合发送到rrc-Suspend来暂停RRC连接。所述消息包含由UE所存储的恢复ID。任选地，对于EDT，所述消息还包含由UE所存储的NextHopChainingCount。

6.UE存储AS上下文，暂停所有SRB和DRB，且进入RRC_IDLE。

图7.3a.3-2：RRC连接恢复程序

1.在某一随后时间点(例如，在UE被寻呼时或在新数据到达上行链路缓冲区中时)，UE通过将RRCConnectionResumeRequest发送到eNB来恢复连接。UE包含其恢复ID、建立原因和认证令牌。认证令牌是以与RRC连接重新建立中使用的短MAC-I相同的方式计算，且允许eNB验证UE识别码。

2.只要恢复ID存在且认证令牌成功地验证，eNB就以RRCConnectionResume作出响应。所述消息包含为了重新建立AS安全性而需要的下一跳链计数(Next Hop ChainingCount，NCC)值。

3.UE恢复所有SRB和DRB，且重新建立AS安全性。UE现在处于RRC_CONNECTED。

4.每当可能时，UE向eNB响应以确认RRC连接成功地恢复的RRCConnectionResumeComplete，连同上行链路缓冲区状态报告及/或UL数据。

5.eNB发起S1-AP上下文恢复程序以向MME通知UE状态改变。

6.MME请求S-GW激活用于UE的S1-U承载。

7.MME确认步骤5。

RRC连接也可在不同于连接被暂停的eNB(旧eNB)的eNB(新eNB)中恢复。使用上下文提取处置eNB间连接恢复，借此新eNB经由X2接口从旧eNB检索UE上下文。新eNB提供由旧eNB用来识别UE上下文的恢复ID。这在图7.3a.3-3中说明。

图7.3a.3-3：不同eNB中的RRC连接恢复程序

1.与eNB内连接恢复中的步骤1相同。

2.新eNB使用恢复ID定位旧eNB，且借助于X2-AP检索UE上下文程序检索UE上下文。

3.旧eNB以与恢复ID相关联的UE上下文作出响应。

4.与eNB内连接恢复中的步骤2相同。

5.与eNB内连接恢复中的步骤3相同。

6.与eNB内连接恢复中的步骤4相同。

7.新eNB发起S1-AP路径切换程序以建立到服务MME的S1UE相关联信令连接，且请求MME恢复UE上下文。

8.MME请求S-GW激活用于UE的S1-U承载，且更新下行链路路径。

9.MME确认步骤7。

10.在S1-AP路径切换程序之后，新eNB借助于X2-AP UE上下文释放程序触发在旧eNB处的UE上下文的释放。

对于支持控制平面CIoT EPS优化和S1-U数据传送或用户平面CIoTEPS优化的NB-IoT UE，如TS 24.301[20]中所限定，不使用PDCP，直到AS安全性被激活。

7.3b EDT

7.3b.1总则

EDT在随机接入程序期间允许一个上行链路数据传送视情况继之以一个下行链路数据传送。

在上部层已请求建立或恢复移动发起数据(即，并非信令或SMS)的RRC连接且上行链路数据大小小于或等于***信息中指示的TB大小时，触发EDT。在使用用户平面CIoT EPS优化时，EDT不用于控制面上的数据。

EDT仅适用于BL UE、增强型覆盖范围(Enhanced Coverage)中的UE及NB-IoT UE。

7.3b.2用于控制平面CIoT EPS优化的EDT

按照TS 24.301[20]中的定义，用于控制平面CIoT EPS优化的EDT表征如下：

-上行链路用户数据在CCCH上在串接于UL RRCEarlyDataRequest消息中的NAS消息中传送；

-下行链路用户数据视情况在CCCH上在串接于DLRRCEarlyDataComplete消息中的NAS消息中传送；

-不存在向RRC CONNECTED的转变。

图7.3b-1中示出用于控制面CIoT EPS优化的EDT程序。

图7.3b-1：用于控制平面CIoT EPS优化的EDT

0.在请求建立对来自上部层的移动发起数据的连接时，UE发起提前数据传送程序且选择被配置成用于EDT的随机接入前导码。

1.UE在CCCH上发送串接用户数据的RRCEarlyDataRequest消息。

2.eNB发起S1-AP初始UE消息程序以转发NAS消息且建立S1连接。eNB可在此程序中指示针对EDT触发此连接。

3.MME请求S-GW重新激活用于UE的EPS承载。

4.MME将上行链路数据发送到S-GW。

5.如果下行链路数据可获得，则S-GW将下行链路数据发送到MME。

6.如果从S-GW接收到下行链路数据，则MME经由DL NAS传输程序将数据转发到eNB，且还可以指示是否预期进一步数据。否则，MME可触发连接建立指示程序，且还指示是否预期进一步数据。

7.如果不预期进一步数据，则eNB可在CCCH上发送RRCEarlyDataComplete消息且使UE保持在RRC_IDLE中。如果在步骤6中接收到下行链路数据，则将所述下行链路数据串接在RRCEarlyDataComplete消息中。

8.释放S1连接，且撤销激活EPS承载。

注释1：如果MME或eNB决定将UE移到RRC_CONNECTED模式，则在步骤7中发送RRCConnectionSetup消息以回退到旧版RRC连接建立程序；eNB将舍弃在RRCConnectionSetupComplete消息中接收的零长度NAS PDU。

注释2：如果在回退的情况下，未响应于RRCEarlyDataRequest而接收到RRCEarlyDataComplete或RRCConnectionSetup，则UE认为UL数据传送不成功。

7.3b.3用于用户平面CIoT EPS优化的EDT

按照TS 24.301[20]中的定义，用于用户平面CIoT EPS优化的EDT的特征如下：

-UE已具有带有暂停指示的RRCConnectionRelease消息中的NextHopChainingCount；

-上行链路用户数据在DTCH上与CCCH上的UL RRCConnectionResumeRequest消息多路地传送；

-下行链路用户数据视情况在DTCH上与DCCH上的DL RRCConnectionRelease消息多路地传送；

-短恢复MAC-I重新用作RRCConnectionResumeRequest消息的认证令牌，并且使用来自先前连接的完整性密钥进行计算；

-对上行链路及下行链路中的用户数据进行加密。使用先前RRC连接的RRCConnectionRelease消息中提供的NextHopChainingCount导出密钥；

-RRCConnectionRelease消息受到完整性保护且使用新导出的密钥进行加密；

-不存在向RRC CONNECTED的转变。

图7.3b-2中说明用于用户平面CIoT EPS优化的EDT程序。

图7.3b-2：用于用户平面CIoT EPS优化的EDT

0.在请求恢复对来自上部层的移动发起数据的连接时，UE发起提前数据传送程序且选择被配置成用于EDT的随机接入前导码。

1.UE将包含其恢复ID、建立原因及认证令牌的RRCConnectionResumeRequest发送到eNB。UE恢复所有SRB及DRB，使用在先前连接的RRCConnectionRelease消息中所提供的NextHopChainingCount导出新安全密钥，且重新建立AS安全性。用户数据经加密且在DTCH上与CCCH上的RRCConnectionResumeRequest消息多路地传送。

2.eNB发起S1-AP上下文恢复程序以恢复S1连接，且重新激活S1-U承载。

3.MME请求S-GW重新激活用于UE的S1-U承载。

4.MME向eNB确认UE上下文恢复。

5.将上行链路数据递送到S-GW。

6.如果下行链路数据可获得，则S-GW将下行链路数据发送到eNB。

7.如果不从S-GW预期进一步数据，则eNB可发起S1连接的暂停及S1-U承载的撤销激活。

8.eNB发送RRCConnectionRelease消息以使UE保持在RRC_IDLE中。所述消息包含设置为由UE存储的rrc-Suspend、resumeID、NextHopChainingCount及drb-ContinueROHC的releaseCause。如果在步骤6中接收到下行链路数据，则在DTCH上与DCCH上的RRCConnectionRelease消息多路地加密发送所述下行链路数据。

注释1：如果MME或eNB决定将UE移到RRC_CONNECTED模式，则在步骤7中发送RRCConnectionResume消息以回退到RRC连接恢复程序。在此情况下，RRCConnectionResume消息受到完整性保护，且用在步骤1中导出的密钥进行加密，并且UE忽略包含于RRCConnectionResume消息中的NextHopChainingCount。可在DTCH上与RRCConnectionResume消息多路地传送下行链路数据。另外，也可在步骤7中发送RRCConnectionSetup以回退到RRC连接建立程序。

注释2：如果在回退的情况下，未响应于用于EDT的RRCConnectionResumeRequest而接收到RRCConnectionRelease或RRCConnectionResume，则UE认为UL数据传送不成功。

对于用于用户平面CIoT EPS优化的EDT，RRC连接也可在不同于连接被暂停的eNB(旧eNB)的eNB(新eNB)中恢复。使用上下文提取处置eNB间连接恢复，借此新eNB经由X2接口从旧eNB检索UE上下文。新eNB提供由旧eNB用来识别UE上下文的恢复ID。这在图7.3b-3中说明。

图7.3b-3：用于不同eNB中的用户平面CIoT EPS优化的EDT

1.与eNB内连接恢复中的步骤1相同。

2.新eNB使用恢复ID定位旧eNB，且借助于X2-AP检索UE上下文程序检索UE上下文。

3.旧eNB以与恢复ID相关联的UE上下文作出响应。

4.新eNB发起S1-AP路径切换程序以建立到服务MME的S1UE相关联信令连接，且请求MME恢复UE上下文。

5.MME请求S-GW激活用于UE的S1-U承载，且更新下行链路路径。

6.MME确认步骤5。

7.在S1-AP路径切换程序之后，新eNB借助于X2-AP UE上下文释放程序触发在旧eNB处的UE上下文的释放。

8.与eNB内连接恢复中的步骤5相同。

9.与eNB内连接恢复中的步骤6相同。

10.与eNB内连接恢复中的步骤7相同。

11.与eNB内连接恢复中的步骤8相同。

在3GPP RAN1中论述预配置上行链路资源(PUR)中的传送。下文引述来自3GPPRAN1#94***纪要的由RAN1作出的一些协议。

协议

对于拥有有效TA的UE，支持基于空闲模式的预配置UL资源

·FFS：针对TA的验证机制

·FFS：如何获取预配置UL资源

协议

对于在预配置UL资源中的传送，UE可使用可使其有效性得到确认的最新TA

在3GPP RAN1中论述在PUR中的传送。下文引述来自3GPP RAN1#94bis***纪要的由RAN1作出的一些协议。

协议

在空闲模式中，UE在验证TA时将至少考虑以下属性中的一个或多个(允许多个属性的组合)：

·服务小区改变(服务小区是指UE预占的小区)

·用于空闲模式的时间对准定时器

·服务小区RSRP改变(服务小区是指UE预占的小区)

·FFS其它属性：

о相邻小区RSRP改变

о>＝2个eNB的TDOA

оTA历史

о基于预订的UE辨别

о不排除其它属性(例如，对于高迁移率UE需要考虑的属性)

应注意，对于FFS属性应考虑UE功率消耗

协议

专用预配置UL资源被定义为由单个UE使用的PUSCH资源

-PUSCH资源是时频资源

-专用PUR是无争用的

无争用共享预配置UL资源(CFS PUR)定义为由多于一个UE同时使用的PUSCH资源

-PUSCH资源至少为时频资源

-CFS PUR为无争用的

基于争用的共享预配置UL资源(Contention-based shared preconfigured ULresource，CBS PUR)定义为由多于一个UE同时使用的PUSCH资源

-PUSCH资源至少为时频资源

-CBS PUR是基于争用的(CBS PUR可能需要争用解决)

协议

在空闲模式下，支持HARQ以用于专用PUR中的传送

·支持单个HARQ进程

оFFS是否支持多于一个HARQ进程

·FFS：对应MPDCCH搜索空间的设计

协议

对于在预配置资源中的UL传送，支持到RACH/EDT程序的回退机制。

协议

对于在预配置UL资源中的传送，RRC空闲UE可使用符合验证准则的最新TA

协议

用于传送数据的预配置UL资源由RRC信令指示。至少支持UE特定RRC信令。

协议

资源配置至少包含以下

·包含周期性的时域资源

·频域资源

·TBS/MCS

协议

专用预配置UL资源被定义为由单个UE使用的NPUSCH资源

·NPUSCH资源是时频资源

·专用PUR是无争用的

无争用共享预配置UL资源(CFS PUR)定义为由多于一个UE同时使用的NPUSCH资源

·NPUSCH资源至少为时频资源

·CFS PUR为无争用的

基于争用的共享预配置UL资源(CBS PUR)定义为由多于一个UE同时使用的NPUSCH资源

·NPUSCH资源至少为时频资源

·CBS PUR是基于争用的(CBS PUR可能需要争用解决)

在3GPP RAN1中论述在PUR中的传送。下文引述来自3GPP RAN1#95***纪要的由RAN1作出的一些协议。

额外MTC增强

协议

对于处于空闲模式的专用PUR，UE可跳过UL传送。

-FFS：资源释放机制

-FFS：是否支持禁止eNB跳过的机制

协议

如果不启用多TB准予，则专用PUR分配仅关联到单个TB和单个HARQ进程

-FFS：如果启用/支持多TB准予

协议

在空闲模式下，至少支持以下TA验证属性：

-服务小区改变(服务小区是指UE预占的小区)

-用于空闲模式的时间对准定时器

-服务小区RSRP改变(服务小区是指UE预占的小区)

о基于现有Rel-15TS36.214中的RSRP测量定义

包含在LS到RAN2、RAN4中以考虑其工作。

协议

UE可经配置以至少使用这些TA验证属性：

-用于空闲模式的时间对准定时器

-服务小区RSRP改变

-注释：配置应该支持禁用TA验证属性

包含在LS到RAN2、RAN4中

对于进一步研究：

TA验证属性：

-基于预订的UE辨别(或预订中保留的静止指示)

-TA在所述小区内有效的小区特定指示

协议

包含在LS到RAN2、RAN4中：

RAN1假设从EDT转变/连接到空闲模式的UE可使用在处于EDT/连接模式时使用的有效TA。

协议

对于空闲模式下的专用PUR，在MPDCCH搜索空间中传送用于HARQ重传的UL准予

-FFS：关于搜索空间(例如USS、CSS)的详情

协议

对于处于空闲模式的指定PUR，在由eNB成功解码PUR传送时，UE可预期显式ACK

FFS：如果在MPDCCH(层1)和/或PDSCH(层2/3)上发送ACK

包含在LS到RAN2、RAN4中。

协议

对于处于空闲模式的指定PUR，在eNB不能成功解码PUR传送时，UE可预期

-用于在MPDCCH上的重传的UL准予，或

-FFS：NACK，或

-FFS：无显式ACK

包含在LS到RAN2、RAN4中。

用于NB-IoT的额外增强

协议

在空闲模式下，至少支持以下TA验证属性：

-服务小区改变(服务小区是指UE预占的小区)

-用于空闲模式的时间对准定时器

-服务小区NRSRP改变(服务小区是指UE预占的小区)

о基于现有Rel-15TS36.214中的NRSRP测量定义

发送LS到RAN2、RAN4以考虑其工作。这个LS中应捕获用于NB-IoT和eMTC的所有与‘包含在LS到RAN2、RNA4中’的协议。R1-1813778中认可LS

协议

UE可经配置以至少使用这些TA验证属性：

-用于空闲模式的时间对准定时器

-服务小区NRSRP改变

-注释：配置应该支持禁用TA验证属性

包含在LS到RAN2、RAN4中。

对于进一步研究：

TA验证属性：

-基于预订的UE辨别(或预订中保留的静止指示)

-TA在所述小区内有效的小区特定指示

协议

包含在LS到RAN2、RAN4中：

RAN1假设从EDT转变/连接到空闲模式的UE可使用在处于EDT/连接模式时使用的有效TA。

协议

对于处于空闲模式的专用PUR，UE可跳过UL传送。

-FFS：资源释放机制

-FFS：是否支持禁止eNB跳过的机制

协议

在空闲模式下，仅支持一个HARQ以用于专用PUR

协议

对于处于空闲模式的指定PUR，在搜索空间中传送用于HARQ重新传送的UL准予

-FFS：关于搜索空间(例如USS、CSS)的详情

在3GPP RAN1中论述在PUR中的传送。下文引述来自3GPP RAN1#96***纪要的由RAN1作出的一些协议。

额外MTC增强

协议

在空闲模式中，TA验证配置可包含“PUR时间对准定时器”

·其中如果(当前时间-最后TA更新的时间)>PUR时间对准定时器，则UE认为TA无效

·关于如何指定“PUR时间对准定时器”的详情取决于RAN2

协议

在空闲模式中，在UE验证TA时，如果服务小区改变，则UE认为用于先前服务小区的TA无效

·以上适用于UE经配置以使用服务小区改变属性的情况

协议

对于处于空闲模式的专用PUR，专用PUR ACK至少在MPDCCH上发送

·RAN2可决定是否也支持较高层PUR ACK

协议

对于处于空闲模式中的专用PUR，PUR搜索空间配置应包含在PUR配置中。

·PUR搜索空间为UE监视MPDCCH的搜索空间

·FFS：PUR搜索空间为共同的还是UE特定的

协议

在TA被验证且被发现无效并且UE有数据要发送时，UE可获得有效TA，并且可经由旧版RACH或EDT程序发送数据

·FFS，是否仅获取TA且接着支持在PUR上发送的数据

·FFS，获得有效TA的其它方法

协议

在UE经配置以使用若干TA验证准则时，TA仅在满足所有已配置TA验证准则时才有效。

协议

对于处于空闲模式中的专用PUR，PUR资源配置至少包含以下

·包含周期性的时域资源

о注释：还包含重复数目、RU数目、起始位置

·频域资源

·TBS/MCS

·功率控制参数

·旧版DMRS模式

协议

在空闲模式中，在PUR传送之后至少可更新以下PUR配置和PUR参数：

·时序提前调整

·UE TX功率调整

·FFS：用于PUSCH的重复调整

FFS：是否在L1和/或较高层中进行以上更新

协议

在空闲模式中，PUR搜索空间配置至少包含以下：

·MPDCCH窄频位置

·MPDCCH重复和聚集层级

·MPDCCH起始子帧周期性(变量G)

·起始子帧位置(alpha_offset)

协议

对于处于空闲模式中的专用PUR，PUR资源配置至少包含以下

·指示是启用还是停用旧版跳频的PUSCH跳频指示

协议

在空闲模式中，UE可经配置以使得TA在给定小区内始终有效。

·FFS：如何实施取决于RAN2，例如，PUR时间对准定时器＝无限

用于NB-IoT的额外增强

协议

在UE经配置以使用若干TA验证准则时，TA仅在满足所有已配置TA验证准则时才有效。

协议

对于处于空闲模式中的专用PUR，PUR搜索空间配置应包含在PUR配置中。

·PUR搜索空间为UE监视NPDCCH的搜索空间

·FFS：PUR搜索空间为共同的还是UE特定的

协议

在空闲模式中，TA验证配置可包含“PUR时间对准定时器”

·其中如果(当前时间-最后TA更新的时间)>PUR时间对准定时器，则UE认为TA无效

·关于如何指定“PUR时间对准定时器”的详情取决于RAN2

协议

在空闲模式中，在UE验证TA时，如果服务小区改变，则UE认为用于先前服务小区的TA无效

·以上适用于UE经配置以使用服务小区改变属性的情况

协议

对于处于空闲模式的专用PUR，专用PUR ACK至少在NPDCCH上发送

·FFS：是否在DCI中引入新字段或重新使用现有字段

·RAN2可决定是否也支持较高层PUR ACK

协议

在TA被验证且被发现无效并且UE有数据要发送时，UE可获得有效TA，并且可经由旧版RACH或EDT程序发送数据

·FFS，是否仅获取TA且接着支持在PUR上发送的数据

·FFS，获得有效TA的其它方法

协议

在空闲模式中，在PUR传送之后至少可更新以下PUR配置和PUR参数：

·时序提前调整

·UE TX功率调整

·FFS：用于NPUSCH的重复调整

FFS：是否在L1和/或较高层中进行以上更新

协议

在空闲模式中，PUR搜索空间配置至少包含以下：

·NPDCCH重复和聚集层级

·NPDCCH起始子帧周期性(变量G)

·起始子帧位置(alpha_offset)

协议

对于处于空闲模式中的专用PUR，PUR资源配置至少包含以下

·包含周期性的时域资源

о注释：还包含重复数目、RU数目、起始位置

·频域资源

·TBS/MCS

·功率控制参数

·旧版DMRS模式

在3GPP RAN1中论述在PUR中的传送。下文引述来自3GPP RAN1#96bis***纪要的由RAN1作出的一些协议。

额外MTC增强

工作假设#1

在空闲模式中，支持在PUR传送之后经由L1信令更新PUR配置和/或PUR参数

·FFS：将经由L1用信号通知哪些PUR配置和PUR参数

·FFS：PUR配置和PUR参数的定义

如果对于一些情况不需要L2/L3信令，则将自动地确认工作假设。如果RAN2决定对于所有情况都需要L2/L3信令，则将恢复工作假设。

工作假设#2

对于专用PUR

·在PUR搜索空间监视期间，UE监视用RNTI(假定RNTI不与任何其它UE共享)扰乱的DCI

о注释：决定RNTI如何用信号通知UE或被导出取决于RAN2

·FFS(如果UE监视可与其它UE共享的任何额外RNTI)。

·注释：可经由非重叠时间和/或频率资源使用相同RNTI

发送LS到RAN2以包含两个以上工作假设。询问工作假设#2中的第一项目编号是否可行。如果推断工作假设#2可行，则将自动地确认工作假设#2。

协议

UE在PUR传送之后监视MPDCCH达至少一定时间段

·FFS：时间段的详情

·FFS：UE行为，如果未在所述时间段中接收到任何内容

·FFS：UE在其尚未传送的PUR分配之后是否监视MPDCCH以及监视频率

协议

RSRP阈值的值为UE特定的

协议

PUR配置内的功率控制参数应至少包含：

·用于PUR传送的目标UL功率电平(P_0)

协议

对于处于空闲模式中的专用PUR，PUR配置通过UE特定RRC信令来配置。

用于NB-IoT的额外增强

协议

在空闲模式中，UE可经配置以使得TA在给定小区内始终有效。

·如何实施取决于RAN2

о例如，PUR时间对准定时器或NRSRP阈值＝无限

协议

NRSRP阈值的值为UE特定的

协议

UE在PUR传送之后监视NPDCCH达至少一定时间段

·FFS：时间段的详情

·FFS：UE行为，如果未在所述时间段中接收到任何内容

·FFS：UE在其尚未传送的PUR分配之后是否监视NPDCCH以及监视频率

协议

重新使用DCI格式N0的现有字段来传达专用PUR ACK

协议

在PUR上的数据传送之后，在eNB不成功地解码时，UE可预期在NPDCCH上进行重新传送的UL准予。其它行为为FFS。

工作假设#1

在空闲模式中，支持在PUR传送之后经由L1信令更新PUR配置和/或PUR参数

·FFS：将经由L1用信号通知哪些PUR配置和PUR参数

·FFS：PUR配置和PUR参数的定义

如果对于一些情况不需要L2/L3信令，则将自动地确认工作假设。如果RAN2决定对于所有情况都需要L2/L3信令，则将恢复工作假设。

工作假设#2

对于专用PUR

·在PUR搜索空间监视期间，UE监视用RNTI(假定RNTI不与任何其它UE共享)扰乱的DCI

о注释：决定RNTI如何用信号通知UE或被导出取决于RAN2

·FFS(如果UE监视可与其它UE共享的任何额外RNTI)。

·注释：可经由非重叠时间和/或频率资源使用相同RNTI

发送LS到RAN2以包含两个以上工作假设。询问工作假设#2中的第一项目编号是否可行。如果推断工作假设#2可行，则将自动地确认工作假设#2。(在eMTC日程项中批准LS-参见6.2.1.2)

协议

对于处于空闲模式中的专用PUR，PUR配置通过UE特定RRC信令来配置。

在3GPP RAN1中论述在PUR中的传送。下文引述来自3GPP RAN1#97***纪要的由RAN1作出的一些协议。

额外MTC增强

协议

对于给定UE、对于处于空闲模式中的专用PUR且对于给定CE模式，对于用于单播传送的所有DCI消息使用相同大小的DCI、相同PUR M-PDCCH候选项和相同RNTI。

协议

对于处于空闲模式中的专用PUR且对于HD-FDD UE，PUR SS窗的开始为结束PUR传送之后的[x]子讯框

FFS：x的值(并且如果x固定或用信号通知)

FFS：FD-FDD UE、TDD UE

FFS：支持在PUR传送之前监视PUR SS窗

注释：PUR SS窗为UE在PUR传送之后监视MPDCCH达至少一定时间段的时间段

协议

对于处于空闲模式中的专用PUR，

最大mPDDCH重复数，r_max-mPDCCH-PUR，包含在PUR配置中

协议

对于处于空闲模式中的专用PUR，PUR SS窗的持续时间通过eNB来配置

持续时间的配置方式和可能值将由RAN2来决定。

协议

对于处于空闲模式中的专用PUR，CE模式为

选项1：明确地在PUR配置中配置。

选项2：基于最后连接的CE模式

在RAN1#98中下拉选择

协议

在RAN1#98中选择以下各者中的一者

·Alt1：在空闲模式中，PUR搜索空间PRB对配置在{2,2+4,4}PRB之间

·Alt2：在空闲模式中，PUR搜索空间PRB对固定至2+4个PRB

协议

对于处于空闲模式中的专用PUR，如果UE跳过PUR传送，则不强制监视相关联PURSS窗

用于NB-IoT的额外增强

协议

对于处于空闲模式中的专用PUR且对于HD-FDD UE，PUR SS窗的开始为结束PUR传送之后的[x]子讯框

-FFS：x的值(并且如果x固定或用信号通知)

-FFS：支持在PUR传送之前监视PUR SS窗

注释：PUR SS窗为UE在PUR传送之后监视NPDCCH达至少一定时间段的时间段

协议

NPDCCH候选项由如搜索空间的USS确定

-FFS：关于如搜索空间的USS的其它详情

о类型2-也可作为FFS的部分论述CSS

结论

在Rel-16中不支持CBS PUR

留待进一步论述

-与向eNB通知未使用的PUR资源相关的方面。

-对于PUR的功率控制机制的潜在增强。(基线是现有的NB-IoT开环功率控制。)

用于随机接入(RA)前导码的时间和频率结构描述于3GPP TS 36.211V15.5.0中。值得注意的是，3GPP TS 36.211 V15.5.0的标题为“随机接入前导码格式(Random accesspreamble format)”的章节5.7.1的图5.7.1-1在本文中再现为图12。3GPP TS 36.211V15.5.0的标题为“上行链路-下行链路时序关系(Uplink-downlink timing relation)”的章节8.1的图8.1-1在本文中再现为图13。3GPP TS 36.211 V15.5.0的部分引述如下：

5.7物理随机接入信道(Physical Random Access Channel)

5.7.1时间和频率结构

图5.7.1-1中所说明的物理层随机接入前导码由长度为T_CP的循环首码和长度为T_SEQ的序列部分组成。参数值在表5.7.1-1中列出，且取决于帧结构和随机接入配置。较高层控制前导码格式。

图5.7.1-1：随机接入前导码格式

表5.7.1-1：随机接入前导码参数

如果由MAC层触发，则随机接入前导码的传送局限于特定时间和频率资源。这些资源以子帧号的递增次序列举于频域中的无线电帧和物理资源块内，使得索引0对应于无线电帧内的最低编号的物理资源块和子帧。无线电帧内的PRACH资源由PRACH配置索引指示，其中索引是按表5.7.1-2和表5.7.1-4中的次序出现。

对于非BL/CE UE，小区中存在至多两个PRACH配置。第一PRACH配置由较高层通过PRACH配置索引(prach-ConfigurationIndex)和PRACH频率偏移

(prach-FrequencyOffset)加以配置。第二PRACH配置(如果存在)由较高层通过PRACH配置索引(prach-ConfigurationIndexHighSpeed)和PRACH频率偏移

(PRACH-FrequencyOffsetHighSpeed)加以配置。

对于BL/CE UE，对于每一PRACH覆盖增强层级，存在由较高层通过PRACH配置索引(prach-ConfigurationIndex)、PRACH频率偏移

(prach-FrequencyOffset)、每尝试PRACH重复数

(numRepetitionPerPreambleAttempt)和视情况PRACH起始子帧周期性

(prach-StartingSubframe)配置的PRACH配置。前导码格式0-3的PRACH传送

次，而前导码格式4的PRACH仅传送一次。

对于BL/CE UE并且对于每一PRACH覆盖增强层级，如果通过较高层参数prach-HoppingConfig针对PRACH配置启用跳频，那么参数

的值取决于SFN和PRACH配置索引，并通过以下给出：

-在PRACH配置索引使得PRACH资源在每一无线电帧中出现的情况下，在从表5.7.1-2或表5.7.1-4如下计算时，

-否则

其中n_f为对于每一PRACH重复对应于第一子帧的***帧号，

对应于小区特定较高层参数prach-HoppingOffset。如果对于PRACH配置不启用跳频，则

对于具有前导码格式0-3的帧结构类型1，针对PRACH配置中的每一者，每一子帧存在最多一个随机接入资源。

表5.7.1-2列出根据表5.7.1-1和其中对于帧结构类型1中的给定配置允许随机接入前导码传送的子帧的前导码格式。假定N_TA＝0(其中N_TA在条款8.1中界定)，随机接入前导码的开始应与UE处的对应上行链路子帧的开始对准。对于PRACH配置0、1、2、15、16、17、18、31、32、33、34、47、48、49、50和63，UE可出于切换目的而假定当前小区与目标小区中的无线电帧i之间的相对时间差的绝对值小于153600·T_s。

分配给PRACH机会的考虑用于前导码格式0、1、2和3的第一物理资源块

被界定为

表5.7.1-2：用于前导码格式0-3的帧结构类型1随机接入配置

对于具有前导码格式0-4的帧结构类型2，对于PRACH配置中的每一者，取决于UL/DL配置[参见表4.2-2]，UL子帧中可能存在多个随机接入资源(或用于前导码格式4的UpPTS)。表5.7.1-3列出帧结构类型2所允许的PRACH配置，其中配置索引对应于前导码格式、PRACH密度值D_RA和版本索引r_RA的特定组合。对于UL/DL配置3、4、5中的具有PRACH配置索引0、1、2、20、21、22、30、31、32、40、41、42、48、49、50或具有PRACH配置索引51、53、54、55、56、57的帧结构类型2，UE可出于切换目的而假定当前小区和目标小区中的无线电帧之间的相对时间差的绝对值小于153600·T_s。

表5.7.1-3：用于前导码格式0-4的帧结构类型2随机接入配置

表5.7.1-4列出对于特定PRACH密度值D_RA所需要的不同随机接入机会的到物理资源的映射。具有格式

的每一四元组指示特定随机接入资源的位置，其中f_RA为所考虑时间点内的频率资源索引，

指示资源在所有无线电帧中(分别在偶数无线电帧或奇数无线电帧中)重复出现，

分别指示随机接入资源位于第一半帧还是第二半帧中，且其中

为前导码开始处的上行链路子帧号，在2个连续下行链路至上行链路切换点之间在第一上行链路子帧处从0开始计数，前导码格式4除外，其中

表示为(*)。假定N_TA＝0，随机接入前导码格式0-3的开始应与在UE处的对应的上行链路子帧的开始对准，并且假定N_TA＝0，随机接入前导码格式4应在UE处的UpPTS结束之前开始4832·T_s，其中UpPTS指代UE的上行链路帧时序。

当且仅当时分多路复用在不在时间上重叠的情况下不足以抓住特定密度值D_RA所需要的PRACH配置的所有机会时，用于每一PRACH配置的随机接入机会才应首先在时间上且接着在频率上分配。对于前导码格式0-3，频率复用应根据下式进行：

其中

为上行链路资源块的编号，

为分配给所考虑PRACH机会的第一物理资源块，且其中

为可用于PRACH的第一物理资源块。

对于前导码格式4，频率复用应根据下式进行：

其中n_f为***帧号，且其中N_SP为无线电帧内DL到UL切换点的编号。

对于BL/CE UE，对于

次重复，仅允许前导码传送所允许的子帧的子集作为起始子帧。PRACH配置所允许的起始子帧确定如下：

-将允许用于前导码传送的PRACH配置的子帧列举为

其中

和

分别对应于允许用于前导码传送的具有最小和最大绝对子帧号

的两个子帧。

-如果较高层不提供PRACH起始子帧周期性

则在前导码传送所允许的子帧方面所允许的起始子帧的周期性为

经由

界定的所允许起始子帧由

给出，其中j＝0,1,2,...

-如果较高层提供PRACH起始子帧周期性

则其指示在前导码传送所允许的子帧方面所允许的起始子帧的周期性。经由

界定的所允许起始子帧由

给出，其中j＝0,1,2,...

-不允许经由

界定的起始子帧使得

针对两种帧结构，每一随机接入前导码占用对应于6个连续资源块的带宽。

8时序

8.1上行链路-下行链路帧时序

从UE传送上行链路无线电帧号ⁱ应在于UE处开始对应下行链路无线电帧之前(N_TA+N_TAoffset)×T_s秒开始。

图8.1-1：上行链路-下行链路时序关系

除了在表8.1-1、表8.1-2和表8.1-3中提及的情况之外，N_TA的范围为0≤N_TA≤20512。

对于帧结构类型1，N_TAoffset＝0，且对于帧结构类型2，N_TAoffset＝624，除非在[4]中另有规定。应注意，并非可传送无线电帧中的全部时隙。其一个实例为TDD，其中仅传送无线电帧中的时隙的子集。

根据表8.1-1、表8.1-2和表8.1-3，N_TA取决于UE配置而界定为不同范围。在基于子时隙的传送(表8.1-2和表8.1-3)的情况下，UE通过较高层以信号通知处理时间线和时序提前的相关联范围来加以配置。

表8.1-1：配置有SCG、短处理时间或在DL和UL两者中皆配置有基于时隙的传送的UE的N_TA范围

表8.1-2：在DL和UL两者中皆配置有基于子时隙的传送的UE的范围(dl-TTI-Length和ul-TTI-Length，参见3GPP TS 36.331[9]。设置到‘子时隙’)

表8.1-3：在DL中配置有基于子时隙的传送且在UL中配置有基于时隙的传送的UE的N_TA范围(dl-TTI-Length和ul-TTI-Length，参见3GPP TS 36.331[9]，分别设置到‘子时隙’和‘时隙’)

在所有其它情况下，N_TA的范围为0≤N_TA≤20512。

如本文中所使用，术语“机器型通信UE(Machine-Type Communications UE，MTCUE)”可指“带宽减小的低复杂性UE(Bandwidth reduced and Low complexity UE，BL UE)”和/或“增强涵盖范围中的UE(EC中的UE、CE中的UE、CE UE)”。如本文中所使用，术语“UE”可指MTC UE和/或窄带物联网(Narrow Band Internet of Things，NB-IoT)UE和/或不同类型的UE。在RRC_IDLE模式(例如，无线电资源控制(RRC)空闲模式)中，如果UE发起随机接入(RA)程序，则RA程序可用于提前数据传送(EDT)和/或RA程序可能并不用于EDT。在RRC_IDLE模式中，如果UE发起RA程序，则RA程序可能用于移动终止EDT(Mobile-terminated EDT，MT-EDT)和/或可能并不用于MT-EDT。基于争用的RA程序可包括四个步骤，其中在四个步骤中的每一步骤中传送和/或接收的消息分别称为“Msg1”、“Msg2”、“Msg3”和/或“Msg4”。非基于争用的RA程序可包括两个步骤，其中在两个步骤中的每一步骤中传送和/或接收的消息分别称为“Msg1”和/或“Msg2”。如本文中所使用，术语“物理下行链路控制信道(PDCCH)”可指用于MTC UE的机器型通信PDCCH(Machine-Type Communications PDCCH，MPDCCH)和/或用于NB-IoT UE的窄频PDCCH(Narrowband PDCCH，NPDCCH)。如本文中所使用，术语“物理随机接入信道(PRACH)”可指用于MTC UE的PRACH和/或用于NB-IoT UE的窄频PRACH(NarrowbandPRACH，NPRACH)。上文在此段中所描述的表述通常可适用于以下段落，除非另有指定。

在LTE版本15中，为了提高MTC UE和/或NB-IoT UE的传送效率且降低其功率消耗，引入EDT。EDT可适用于MTC UE和/或NB-IoT UE。可在RRC_IDLE模式中触发EDT。在触发EDT之后，上行链路用户数据(例如，移动发起数据)可在RA程序期间包含在Msg3中(例如，Msg3可对应于RA程序的第三消息)，且网络可在RA程序期间在Msg4中包含下行链路用户数据(例如，Msg4可对应于RA程序的第四消息)。EDT的一个益处为上行链路用户数据可通过UE传送而不需要UE进入RRC_CONNECTED模式(例如，RRC连接模式)。还有可能EDT回退到旧版RRC连接建立/恢复程序，和/或在UE进入RRC_CONNECTED模式之后传送上行链路用户数据。版本15EDT也可称为“移动发起EDT(Mobile-originated EDT，MO-EDT)”。

存在至少两种类型的EDT(或MO-EDT)。

第一类型的EDT(或第一类型的MO-EDT)为控制平面EDT(CP-EDT)(例如，用于控制平面蜂窝式物联网(CIoT)演进型分组***(EPS)优化的EDT)。在CP-EDT中，上行链路用户数据在共同控制信道(Common Control Channel，CCCH)上在串接于上行链路RRCEarlyDataRequest消息中的非接入层(Non-Access Stratum，NAS)消息中传送。上行链路RRCEarlyDataRequest消息可在RA程序期间包含在Msg3中(例如，Msg3可对应于RA程序的第三消息，其中Msg3通过UE传送到eNB)。下行链路用户数据可在CCCH上在串接于下行链路RRCEarlyDataComplete消息中的NAS消息中传送。下行链路RRCEarlyDataComplete消息可在RA程序期间包含在Msg4中(例如，Msg4可对应于RA程序的第四消息，其中Msg4通过eNB传送到UE)。如果移动性管理实体(Mobility Management Entity，MME)和/或eNB决定将UE改变到RRC_CONNECTED模式(例如，将UE从RRC_IDLE模式改变到RRC_CONNECTED模式)，则可在Msg4中发送(到UE)RRCConnectionSetup消息以回退到旧版RRC连接建立程序。

第二类型的EDT(或第二类型的MO-EDT)为用户平面EDT(user plane EDT，UP-EDT)(例如，用于用户平面CIoT EPS优化的EDT)。在UP-EDT中，上行链路用户数据与CCCH上的上行链路RRCConnectionResumeRequest消息在专用业务信道(Dedicated Traffic Channel，DTCH)上多路地传送。在一些实施例中，DTCH服务数据单元(Service Data Unit，SDU)和/或CCCH SDU在RA程序期间包含在Msg3中(例如，Msg3可对应于RA程序的第三消息，其中Msg3通过UE传送到eNB)。下行链路用户数据可在DTCH上与专用控制信道(DCCH)上的下行链路RRCConnectionRelease消息多路地传送。DTCH SDU和/或DCCH SDU可在RA程序期间包含在Msg4中。如果MME和/或eNB决定将UE改变到RRC_CONNECTED模式(例如，将UE从RRC_IDLE模式改变到RRC_CONNECTED模式)，则可在Msg4中发送(到UE)RRCConnectionResume消息(和/或下行链路用户数据)以回退到RRC连接恢复程序。

在LTE版本16中，为了进一步改进MTC UE和/或NB-IoT UE的传送效率和/或降低其功率消耗，可引入在预配置上行链路资源(PUR)中的传送。根据RAN1协议(在前述描述中引述其中的至少一些)，如果满足准则，则UE可使用RRC_IDLE模式的一个或多个专用PUR。如本文中所使用，术语“专用PUR”可对应于UE采用的不与其它UE共享的一或多个资源。所述准则至少包含有效时间对准。用于时间对准的验证机制(例如，用于确定时间对准是否有效的机制)仍在讨论中。验证机制可包含用于空闲模式(和/或用于PUR)的时间对准定时器。UE可认为如果时间对准定时器(对于空闲模式和/或PUR)在运行中，则与UE相关联的时间对准有效。

在一些实施例中，UE在PUR时机执行PUR传送(例如，经由一个或多个PUR将数据传送到网络)。在一些实施例中，UE基于在UE的专用PUR配置中配置的一个或多个PUR的时间和频率信息确定PUR时机。对于使用专用PUR的一个或多个传送支持HARQ以改进可靠性。在UE执行PUR传送之后，UE在可配置时间段(例如，PUR搜索空间窗)期间监视PDCCH。网络可包含在专用PUR配置中的PUR搜索空间配置，和/或UE可在PUR传送之后基于PUR搜索空间配置监视PDCCH(例如，PUR搜索空间配置可对应于可配置时间段)。另外，还可支持到RACH和/或EDT程序的一个或多个回退机制。一个或多个回退机制的详情在讨论中。

可在UE处于RRC_CONNECTED模式时在专用信令中将专用PUR配置提供给UE。在UE处于RRC_IDLE模式时，一个或多个已配置PUR(例如，通过专用PUR配置而配置的一个或多个PUR)可为有效的。一个或多个已配置PUR可能不需要下部层激活。如果无数据可用于传送，则UE可能不使用所述一个或多个已配置PUR。对于一个或多个专用PUR，因为网络可识别哪一UE正使用所述一个或多个专用PUR执行传送，因此可能并不需要争用解决方案。在一些实施例中，UE可执行两个步骤。所述两个步骤中的第一步骤包括使用PUR的传送，且两个步骤中的第二步骤包括接收与所述传送相关联的网络响应(例如，网络响应也称为“对PUR的响应”和/或“PUR响应”)。网络响应可为对传送成功与否的确认(例如，网络响应可包括HARQ反馈)。网络响应可为对重新传送的动态上行链路准予(例如，如果传送不成功，则网络响应可为对重新传送的动态上行链路准予)。网络响应可为下行链路用户数据和/或RRC消息(例如，RRCEarlyDataComplete消息、RRCConnectionRelease消息等中的至少一者)。下行链路用户数据和/或RRC消息可通过动态下行链路指派来调度。动态上行链路准予可寻址到第一特定RNTI(例如，C-RNTI、临时C-RNTI和/或新RNTI)。动态下行链路指派可寻址到第二特定RNTI(例如，C-RNTI、临时C-RNTI和/或新RNTI)。第一特定RNTI和/或第二特定RNTI可提供于专用PUR配置中。在UE处于RRC_CONNECTED模式时，可提供第一特定RNTI和/或第二特定RNTI。第一特定RNTI与第二特定RNTI可相同(即，第一特定RNTI和第二特定RNTI两者可对应于单个RNTI)。替代地和/或另外，第一特定RNTI可不同于第二特定RNTI。如果需要重新传送，例如在传送不成功的情况下，UE可在下一PUR时机和/或基于动态上行链路准予(在第二步骤中接收)执行重新传送。UE在可配置时间段(例如，PUR搜索空间窗)期间监视PDCCH以用于接收网络响应。

版本15EDT(例如，MO-EDT)可通过来源于UE的上行链路数据(例如，UE侧发起上行链路数据)来发起。在一些实施例中，如果存在可用于UE的下行链路数据，则网络可使用寻呼来触发UE发起RRC程序，例如RRC连接建立程序和/或RRC连接恢复程序。下行链路数据可在建立、设置和/或恢复RRC连接之后传送到UE(例如，网络可在建立、设置和/或恢复RRC连接的RA程序成功完成之后将下行链路数据传送到UE)。为了改进来源于网络的下行链路数据传送(例如，网络侧发起的下行链路数据传送)的效率，可引入MT-EDT。在以下段落中，除非另外指定，否则术语“EDT”可不同于MT-EDT和/或可对应于MO-EDT和/或不为MT-EDT的一个或多个其它类型的EDT。

存在MT-EDT程序的至少两个可能候选项。MT-EDT程序候选项使用RA程序作为基线，且网络可使用寻呼消息(例如，Msg0)来触发UE发起MT-EDT程序(例如，寻呼消息可指示MT-EDT)。

第一候选MT-EDT程序称作基于Msg2的MT-EDT。下文概述第一候选MT-EDT程序的动作。可例如相对于实施方案进一步研究和/或探究第一候选MT-EDT程序的一个或多个动作的详情。

在一些实施例中，在发起MT-EDT之后，UE在PRACH上将RA前导码传送到网络(例如，UE传送RA程序的Msg1，其中Msg1指示RA前导码)。MT-EDT可响应于接收到指示MT-EDT的寻呼消息而发起。专用前导码和/或PRACH资源可提供于寻呼消息中(例如，寻呼消息可指示专用前导码和/或PRACH资源)。UE可使用专用前导码，以使得网络可在接收到Msg1之后识别UE。举例来说，Msg1和/或RA前导码可指示专用前导码。因此，网络可基于确定Msg1和/或RA前导码指示网络在寻呼消息中提供到UE的专用前导码而识别UE(和/或确定Msg1和/或RA前导码与UE相关联)。在一些实施例中，RA前导码可用于EDT(例如，RA前导码可用于MO-EDT)。替代地和/或另外，RA前导码可能并不用于EDT(例如，RA前导码可能并不用于MO-EDT)。在一些实施例中，RA前导码可用于MT-EDT。替代地和/或另外，RA前导码可能并不用于MT-EDT。

在一些实施例中，UE在RA响应窗期间(和/或在预定义时间段期间)监视PDCCH。UE可从网络接收RA程序的Msg2(例如，Msg2可包括RA响应)。在一些实施例中，在RA响应窗期间接收Msg2。在一些实施例中，Msg2包括来自网络的下行链路数据。在一些实施例中，Msg2寻址到RA-RNTI。替代地和/或另外，Msg2寻址到特定RNTI。Msg2寻址到RA-RNTI还是特定RNTI仍在讨论中。在一些实施例中，寻呼消息指示RNTI(例如，RA-RNTI和/或特定RNTI)。替代地和/或另外，寻呼消息不指示RNTI。RNTI是否提供于寻呼消息中仍在讨论中。Msg2可包括RRC消息。RRC消息可包括下行链路数据。在一些实施例中，下行链路数据可包封于RRC消息中。替代地和/或另外，下行链路数据可与RRC消息多路复用。替代地和/或另外，Msg2可不包括RRC消息(和/或在Msg2中可能不存在RRC消息)。

在一些实施例中，UE可将第三消息传送到网络。在一些实施例中，可传送第三消息，使得网络可确认UE成功地接收Msg2和/或下行链路数据。替代地和/或另外，第三消息可包括由UE响应于下行链路数据而传送的上行链路数据。UE如何将第三消息传送到网络仍在讨论中。在一些实施例中，上行链路准予可提供于Msg2中(例如，Msg2可指示上行链路准予)。UE可使用在Msg2中提供的上行链路准予来传送第三消息(例如，UE可使用由上行链路准予指示的一或多个资源来传送第三消息)。在一些实施例中，第三消息可包含响应于在Msg2中接收的下行链路数据的第一上行链路数据。替代地和/或另外，第三消息可包含并非响应于在Msg2中接收的下行链路数据的第二上行链路数据(例如，第二上行链路数据可包括不同于下行链路数据和/或与下行链路数据分离的信息)。

第二候选MT-EDT程序称作基于Msg4的MT-EDT。下文概述第二候选MT-EDT程序的动作。可例如相对于实施方案进一步研究和/或探究第二候选MT-EDT程序的一个或多个动作的详情。

在一些实施例中，在发起MT-EDT之后，UE在PRACH上将RA前导码传送到网络(例如，UE传送RA程序的Msg1，其中Msg1指示RA前导码)。MT-EDT可响应于接收到指示MT-EDT的寻呼消息而发起。在第二候选MT-EDT程序中，寻呼消息可包括专用前导码。替代地和/或另外，在第二候选MT-EDT程序中，寻呼消息可不包括专用前导码(和/或在寻呼消息可能不存在专用前导码)。在一些实施例中，RA前导码可用于EDT(例如，RA前导码可用于MO-EDT)。替代地和/或另外，RA前导码可能并不用于EDT(例如，RA前导码可能并不用于MO-EDT)。在一些实施例中，RA前导码可用于MT-EDT。替代地和/或另外，RA前导码可能并不用于MT-EDT。

在一些实施例中，UE在RA响应窗期间(和/或在预定义时间段期间)监视PDCCH。UE可从网络接收RA程序的Msg2(例如，Msg2可包括RA响应)。在一些实施例中，在RA响应窗期间接收Msg2。在一些实施例中，Msg2可包括上行链路准予。在一些实施例中，上行链路准予为旧版上行链路准予(例如，并非用于EDT的上行链路准予)。替代地和/或另外，上行链路准予可为用于EDT的上行链路准予(例如，用于MO-EDT的上行链路准予)。替代地和/或另外，上行链路准予可为用于MT-EDT的上行链路准予。

在一些实施例中，在接收到Msg2之后，UE使用在Msg2中提供的上行链路准予将RA程序的Msg3传送到网络(例如，UE可使用由Msg2中提供的上行链路准予指示的一或多个资源传送Msg3)。在一些实施例中，Msg3可包括RRC消息。在一些实施例中，如果UE具有可用于传送到网络的上行链路数据，则上行链路数据可包含在Msg3中(例如，上行链路数据可能并不响应于经由RA程序的Msg4接收的下行链路数据)。RRC消息可包括上行链路数据。在一些实施例中，上行链路数据可包封于RRC消息中。替代地和/或另外，上行链路数据可与RRC消息多路复用。替代地和/或另外，Msg3可不包括RRC消息(和/或在Msg3中可能不存在RRC消息)。

在一些实施例中，UE在争用解决定时器期间监视PDCCH(例如，UE可在争用解决定时器在运行中时监视PDCCH)。在一些实施例中，UE从网络接收RA程序的Msg4。在一些实施例中，Msg4包括由网络提供的下行链路数据。UE可在争用解决定时器在运行中时接收Msg4。Msg4可包括RRC消息。RRC消息可包括下行链路数据。在一些实施例中，下行链路数据可包封于RRC消息中。替代地和/或另外，下行链路数据可与RRC消息多路复用。替代地和/或另外，Msg4可不包括RRC消息(和/或在Msg4中可能不存在RRC消息)。

在一些实施例中，UE可将第五消息传送到网络。在一些实施例中，可传送第五消息，使得网络可确认UE成功地接收Msg4和/或下行链路数据。替代地和/或另外，第五消息可包括由UE响应于下行链路数据而传送的上行链路数据。UE如何将第五消息传送到网络仍在讨论中。在一些实施例中，上行链路准予可提供于Msg4中(例如，Msg4可指示上行链路准予)。UE可使用在Msg4中提供的上行链路准予来传送第五消息(例如，UE可使用由上行链路准予指示的一或多个资源传送第五消息)。在一些实施例中，第五消息可包含响应于在Msg4中接收的下行链路数据的第一上行链路数据。替代地和/或另外，第五消息可包含并非响应于在Msg4中接收的下行链路数据的第二上行链路数据(例如，第二上行链路数据可包括不同于下行链路数据和/或与下行链路数据分离的信息)。

在一些实施例中，包含在Msg3中的上行链路数据可不同于包含在第五消息中的上行链路数据。替代地和/或另外，包含在Msg3中的上行链路数据可与包含在第五消息中的上行链路数据相同。

在一些实施例中，可能存在至少两种类型的MT-EDT。第一类型的MT-EDT可为控制平面MT-EDT(control plane MT-EDT，CP-MT-EDT)，且第二类型的MT-EDT可为用户平面MT-EDT(user plane MT-EDT，UP-MT-EDT)。CP-MT-EDT和UP-MT-EDT的详情仍在讨论中。

在UE处于RRC_IDLE模式时，如果UE接收到指示MT-EDT的寻呼消息，则UE可发起MT-EDT程序。MT-EDT程序可被看作是特殊类型的RA程序。根据3GPP TS 36.211 V15.5.0，在UE执行RA前导码传送时，UE假定不存在时序提前(例如UE假定N_TA＝0，其中N_TA对应于时序提前值)，和/或UE不使用所维护的时序提前值(其可能为非零)用于RA前导码传送。UE可在MT-EDT程序的Msg2中获得新时序提前。UE可使用所述新时序提前用于进一步上行链路传送。举例来说，UE可使用新时序提前来将MT-EDT程序的Msg3传送到与MT-EDT程序相关联的网络。在其中UE配置有PUR的实例中，UE在RRC_IDLE模式期间维护时序提前值。在存在可用于传送到网络的上行链路数据时，UE基于由网络配置的一些准则确定时序提前值是否有效(例如，UE可基于用于PUR的时序提前定时器、一个或多个服务小区RSRP改变等中的至少一者确定时序提前值是否有效)。如果确定时序提前有效，则UE使用PUR以所维护的时序提前值(例如，N_TA)执行传送。如果确定时序提前无效，则UE可发起RA程序(例如，用于EDT的RA程序和/或并非用于EDT的RA程序)。在发起RA程序时，UE可能释放PUR配置，且网络可能接着需要再次提供PUR配置，从而导致额外信令开销。

有可能配置有PUR的UE接收指示MT-EDT的寻呼消息。UE可接着发起RA程序和/或MT-EDT程序，和/或UE可执行RA前导码传送而不顾及UE是否具有有效时序提前。另外，RA前导码的传送功率可以相对较小值开始(例如，RA前导码的传送功率可随着执行RA前导码的一个或多个传送而增大)。因此，RA程序和/或MT-EDT程序的Msg1和/或Msg3的传送可能不会以单个尝试就成功(例如，在RA程序和/或MT-EDT程序期间可能需要执行Msg1和/或Msg3的一个或多个重新传送)。此可能导致执行RA程序和/或MT-EDT程序时的额外功率消耗、信令开销和/或调度延迟。另外，发起RA程序和/或MT-EDT程序可能导致UE释放PUR配置，且网络可能接着需要再次提供PUR配置，从而导致额外信令开销。

本文中提供的技术解决了前述问题。本公开的实施例1和实施例2可实施于以下情形中：配置有一个或多个PUR(例如，一个或多个专用PUR)的UE接收到指示MT-EDT的寻呼消息。

实施例1

在实施例1中，UE在起始用于MT-EDT的RA程序时可不释放对应于一个或多个PUR的PUR配置(例如，专用PUR配置)(例如，用于MT-EDT的RA程序可对应于MT-EDT程序)。

在一些实施例中，响应于接收到指示MT-EDT的寻呼消息，UE在发起用于MT-EDT的RA程序时不释放PUR配置。举例来说，响应于接收到寻呼消息和/或确定寻呼消息指示MT-EDT，UE可发起用于MT-EDT的RA程序，和/或UE可基于确定寻呼消息指示MT-EDT而不释放PUR配置。

在一些实施例中，如果寻呼消息不指示MT-EDT，则UE在发起并非用于MT-EDT的RA程序时释放PUR配置。举例来说，响应于接收到寻呼消息和/或确定寻呼消息不指示MT-EDT，UE可发起并非用于MT-EDT的RA程序，和/或UE可基于确定寻呼消息不指示MT-EDT而释放PUR配置。

替代地和/或另外，指示MT-EDT的寻呼消息可指示UE是否应释放PUR配置。在一些实施例中，UE响应于确定寻呼消息指示(indicate和/或instruct)PUR配置的释放而释放PUR配置。在一些实施例中，UE响应于确定寻呼消息不指示PUR配置的释放而不释放PUR配置。

实施例2

在实施例2中，UE可响应于接收到指示MT-EDT的寻呼消息而确定时序提前(例如，用于PUR的时序提前)是否有效。

在一些实施例中，UE可能确定时序提前有效。基于确定时序提前有效，UE可不响应于接收到指示MT-EDT的寻呼消息而发起用于MT-EDT的RA程序。

在一些实施例中，UE可能确定时序提前无效。基于确定时序提前无效，UE可响应于接收到指示MT-EDT的寻呼消息而发起用于MT-EDT的RA程序。

在一些实施例中，UE可基于时序提前验证准则而确定时序提前是否有效。在一些实施例中，时序提前验证准则由网络配置。在一些实施例中，时序提前验证准则可与用于PUR的时序提前定时器相关联。在一些实施例中，时序提前验证准则可包括时序提前定时器、用于PUR的时序提前定时器是否在运行中和/或其它准则。在一实例中，UE可基于确定用于PUR的时序提前定时器不在运行中(和/或基于时序提前验证准则中的其它准则)而确定时序提前无效。替代地和/或另外，UE可基于确定用于PUR的时序提前定时器在运行中(和/或基于时序提前验证准则中的其它准则)而确定时序提前有效。

替代地和/或另外，在其中UE确定时序提前有效的实例中，UE可确定PUR时机(例如，即将到来PUR时机和/或用于UE的下一可用PUR时机)之前的持续时间。在一些实施例中，所述持续时间可对应于接收到寻呼消息与PUR时机之间的持续时间。举例来说，所述持续时间可对应于接收到寻呼消息的第一子帧T1与和PUR时机相关联的第二子帧T2(例如，PUR时机可经调度用于第二子帧T2)之间的持续时间。在一些实施例中，所述持续时间的单位为帧、子帧、时隙、秒、毫秒、微秒等中的至少一者。在一些实施例中，所述持续时间可对应于第一子帧T1与第二子帧T2之间的子帧差(例如，所述持续时间可对应于T2-T1)。替代地和/或另外，所述持续时间可对应于第一子帧T1的时间与第二子帧T2的时间之间的时间差。在一些实施例中，所述持续时间与阈值进行比较。响应于确定所述持续时间大于阈值，UE可发起用于MT-EDT的RA程序。响应于确定所述持续时间小于(和/或不大于)阈值，UE可不发起用于MT-EDT的RA程序。在一些实施例中，阈值可预定义(例如，阈值可预定义为10子帧、一毫秒，等)。在一些实施例中，阈值可以是可配置的(例如，阈值在PUR配置或MT-EDT配置中加以配置)。

图14说明其中UE确定与PUR时机1404(例如，用于UE的即将到来的PUR时机和/或下一可用PUR时机)相关联的持续时间1408的示例性情形。在一些实施例中，UE在第一子帧T1接收指示MT-EDT的寻呼消息1402。响应于接收到寻呼消息1402，UE可执行一个或多个UE动作1410。所述一个或多个UE动作1410可包括确定与UE相关联的时序提前是否有效的动作1412。所述一个或多个UE动作1410可包括基于持续时间1408确定是否发起用于MT-EDT的RA程序的动作1414。在一些实施例中，持续时间1408对应于与PUR时机1404相关联的第一子帧T1与第二子帧T2之间的子帧差(例如，持续时间1408可对应于T2-T1)。替代地和/或另外，持续时间1408可对应于第一子帧T1的时间与第二子帧T2的时间之间的时间差。在一些实施例中，持续时间1408与阈值1406进行比较。UE可基于确定时序提前无效而确定发起RA程序和/或发起用于MT-EDT的RA程序。如果UE确定时序提前有效，则UE可基于确定持续时间1408大于阈值1406而确定发起RA程序和/或发起用于MT-EDT的RA程序。

替代地和/或另外，指示MT-EDT的寻呼消息可指示UE是否应发起用于MT-EDT的RA程序。在一些实施例中，UE响应于确定寻呼消息指示UE发起用于MT-EDT的RA程序而确定发起用于MT-EDT的RA程序(和/或UE发起用于MT-EDT的RA程序)。在一些实施例中，UE响应于确定寻呼消息不指示UE发起用于MT-EDT的RA程序而确定不发起用于MT-EDT的RA程序(和/或UE不发起用于MT-EDT的RA程序)。

本公开的实施例3和实施例4可实施于以下情形中：UE不发起用于MT-EDT的RA程序，例如基于根据实施例1和/或实施例2执行的一个或多个动作，UE不发起用于MT-EDT的RA程序。

实施例3

在实施例3中，UE在PUR时机(例如，用于UE的即将到来的PUR时机和/或下一可用PUR时机)上执行PUR传送(例如，经由一个或多个PUR将数据传送到网络)。

在一些实施例中，在UE执行PUR传送之后，UE在可配置时间段(例如，PUR搜索空间窗)期间监视PDCCH。可配置时间段可基于例如在前述描述中描述的与UE相关联的PUR配置(例如专用PUR配置)而确定。UE可在可配置时间段期间接收与传送相关联的网络响应。对于PUR的网络响应可包括例如在前述描述中描述的下行链路数据和/或RRC消息。

在一实例中，PUR时机在第一子帧T2处。所述可配置时间段(例如，PUR搜索空间窗)可开始于第二子帧(T2+start_offset)，和/或所述可配置时间段可结束于第三子帧(T2+start_offset+window_length-1)。UE可在第一子帧T2执行PUR传送，且UE可在第二子帧(T2+start_offset)开始监视PDCCH和/或继续监视PDCCH直至第三子帧(T2+start_offset+window_length-1)。在一些实施例中，响应于在可配置时间段期间接收到网络响应，UE可停止监视PDCCH。替代地和/或另外，响应于在可配置时间段期间接收到网络响应，UE可继续监视PDCCH直至第三子帧(T2+start_offset+window_length-1)。

图15说明其中UE在可配置时间段1508(例如，PUR搜索空间窗)期间监视PDCCH的示例性情形。在一些实施例中，UE在第一子帧T1接收指示MT-EDT的寻呼消息1502。响应于接收到寻呼消息1502，UE可执行一个或多个UE动作1510。所述一个或多个UE动作1510可包括确定与UE相关联的时序提前是否有效的动作1512。一个或多个UE动作1510可包括在PUR时机1504(例如，用于UE的即将到来的PUR时机和/或下一可用PUR时机)上执行PUR传送的动作1514。在一些实施例中，可基于确定时序提前有效而执行PUR传送。在一些实施例中，一个或多个UE动作1510可包括在可配置时间段1508期间监视PDCCH以接收网络响应(响应于PUR传送)的动作1516。在一些实施例中，可配置时间段1508可基于偏移1506、PUR时机的第二子帧T2和/或可配置时间段1508的窗长度而确定。举例来说，可配置时间段1508可在第三子帧(例如，第二子帧T2+偏移1506)开始，且在第四子帧(例如，第二子帧T2+偏移1506+窗长度-1)结束。在一些实施例中，响应于在可配置时间段1508期间接收到网络响应，UE可停止监视PDCCH。替代地和/或另外，响应于在可配置时间段1508期间接收到网络响应，UE可继续监视PDCCH直至第四子帧。

在一些实施例中，start_offset可等于零(例如，零子帧、零秒等中的至少一者)。在一些实施例中，start_offset可为正值(例如，可配置时间段可在PUR时机之后开始)。在一些实施例中，start_offset可为负值(例如，可配置时间段可在PUR时机之前开始)。在一些实施例中，start_offset可预定义。在一些实施例中，start_offset可在PUR配置和/或配置于PUR配置中的PUR搜索空间配置中配置。window_length可为可配置时间段(例如，PUR搜索空间窗)的持续时间(和/或长度)。window_length可配置于PUR配置和/或PUR搜索空间配置中。

在一些实施例中，PUR时机可为下一可用PUR时机。PUR时机可为在UE接收到指示MT-EDT的寻呼消息之后在时间上最接近的PUR时机(例如，接收到寻呼消息之后的初始PUR时机)。举例来说，在UE接收到寻呼消息的时间与PUR时机的时间之间可能不存在与UE相关联的其它PUR时机。

UE可基于配置于PUR配置中的PUR搜索空间配置而监视PDCCH。

在一些实施例中，PUR传送可包括传送RRC消息(例如，RRC消息可包含在PUR传送中)。在一些实施例中，RRC消息可为RRCEarlyDataRequest消息。替代地和/或另外，RRC消息可为RRCConnectionResumeRequest消息。替代地和/或另外，RRC消息可为经设计用于MT-EDT的新RRC消息，例如RRCEarlyDLDataRequest消息。在其中UE具有可用于传送的上行链路数据的一些实施例中，PUR传送可包括传送上行链路数据(例如，上行链路数据可包含在PUR传送中)。在一些实施例中，上行链路数据可能并不为对网络响应和/或网络响应中的下行链路数据的响应。举例来说，上行链路数据可包括不同于网络响应和/或网络响应中的下行链路数据和/或与之分离的信息。在一些实施例中，RRC消息可包括上行链路数据。在一些实施例中，上行链路数据可包封于RRC消息中。替代地和/或另外，上行链路数据可与RRC消息多路复用。在一些实施例中，PUR传送可不包括传送RRC消息(和/或在PUR传送中可能不存在RRC消息)。

在一些实施例中，网络响应可包括RRC消息。在一些实施例中，RRC消息可为RRCEarlyDataComplete消息。替代地和/或另外，RRC消息可为RRCConnectionResume消息。替代地和/或另外，RRC消息可为RRCConnectionRelease消息。替代地和/或另外，RRC消息可为RRCConnectionSetup消息。替代地和/或另外，RRC消息可为经设计用于MT-EDT的新RRC消息，例如RRCEarlyDLDataComplete消息。在一些实施例中，RRC消息可包括下行链路数据。在一些实施例中，下行链路数据可包封于RRC消息中。替代地和/或另外，下行链路数据可与RRC消息多路复用。在一些实施例中，网络响应可不包括RRC消息(和/或在网络响应中可能不存在RRC消息)。

在其中响应于网络响应和/或(网络响应的)下行链路数据的上行链路数据可用(和/或其中指示UE响应于网络响应和/或下行链路数据而传送上行链路数据)的实例中，UE可使用提供于网络响应中的上行链路准予来传送上行链路数据。举例来说，UE可使用由网络响应中的上行链路准予指示的一或多个资源来传送上行链路数据。替代地和/或另外，UE可使用下一PUR时机(例如，在接收到网络响应之后的用于UE的即将到来的PUR时机和/或下一可用PUR时机)来传送上行链路数据。替代地和/或另外，UE可发起用于EDT的RA程序(例如，用于MO-EDT的RA程序)以传送上行链路数据(例如，UE可在RA程序中传送上行链路数据)。替代地和/或另外，UE可发起并非用于EDT的RA程序(例如，并非用于MO-EDT的RA程序)以传送上行链路数据(例如，UE可在RA程序中传送上行链路数据)。

在一些实施例中，如果未在可配置时间段期间接收到网络响应(和/或未在可配置时间段期间接收到网络响应)，则UE可发起用于MT-EDT的RA程序。替代地和/或另外，如果未在可配置时间段期间接收到网络响应(和/或未在可配置时间段期间接收到网络响应)，则UE可发起用于EDT的RA程序(例如，用于MO-EDT的RA程序)。替代地和/或另外，如果未在可配置时间段期间接收到网络响应(和/或未在可配置时间段期间接收到网络响应)，则UE可发起RA程序，其中RA程序既不用于MT-EDT也不用于EDT。

在实施例3中，在其中存在重复传送(例如上行链路传送(例如，上行链路数据)和/或下行链路传送(例如，寻呼消息))的实例中，相对于实施例3描述的与传送相关联的子帧时序(例如，子帧时序可对应于与寻呼消息的接收相关联的子帧T1和/或与PUR传送相关联的子帧T2)可对应于与传送的第一重复或传送的最后重复相关联的子帧。在一些实施例中，与寻呼消息的接收相关联的子帧T1对应于网络到UE的寻呼消息的传送的最后重复(例如，可能在子帧T1执行网络到UE的寻呼消息的传送的最后重复)。在一些实施例中，与PUR传送相关联的子帧T2对应于PUR传送的第一重复(例如，可能在子帧T2执行UE到网络的PUR传送的第一重复)。

实施例4

在实施例4中，UE不在PUR时机(例如，用于UE的即将到来的PUR时机和/或下一可用PUR时机)执行PUR传送。

在一些实施例中，UE在可配置时间段(例如PUR搜索空间窗)期间监视PDCCH，而不在PUR时机执行PUR传送。在一实例中，PUR时机可在第一子帧T2，且可配置时间段可从第二子帧(T2+start_offset)开始和/或可在第三子帧(T2+start_offset+window_length-1)结束。UE可不在第一子帧T2(例如，PUR时机)执行PUR传送，且UE可在第二子帧(T2+start_offset)开始监视PDCCH和/或继续监视PDCCH直至第三子帧(T2+start_offset+window_length-1)。在一些实施例中，响应于在可配置时间段期间接收到网络响应，UE可停止监视PDCCH。替代地和/或另外，响应于在可配置时间段期间接收到网络响应，UE可继续监视PDCCH直至第三子帧(T2+start_offset+window_length-1)。

图16说明其中UE在可配置时间段1608(例如，PUR搜索空间窗)期间监视PDCCH的示例性情形。在一些实施例中，UE在第一子帧T1接收指示MT-EDT的寻呼消息1602。响应于接收到寻呼消息1602，UE可执行一个或多个UE动作1610。所述一个或多个UE动作1610可包括确定与UE相关联的时序提前是否有效的动作1612。在一些实施例中，一个或多个UE动作1610可包括在可配置时间段1608期间监视PDCCH以接收网络响应的动作1614。在一些实施例中，可基于确定时序提前有效而执行在可配置时间段1608期间监视PDCCH。替代地和/或另外，可执行在可配置时间段1608期间监视PDCCH而不顾及时序提前是否有效。在一些实施例中，可配置时间段1608可基于偏移1606、PUR时机1604(例如，用于UE的即将到来的PUR时机和/或下一可用PUR时机)的第二子帧T2和/或可配置时间段1608的窗长度而确定。举例来说，可配置时间段1608可在第三子帧(例如，第二子帧T2+偏移1606)开始，且在第四子帧(例如，第二子帧T2+偏移1606+窗长度-1)结束。在一些实施例中，响应于在可配置时间段1608期间接收到网络响应，UE可停止监视PDCCH。替代地和/或另外，响应于在可配置时间段1608期间接收到网络响应，UE可继续监视PDCCH直至第四子帧。

替代地和/或另外，UE可在接收到指示MT-EDT的寻呼消息之后和/或在即将到来的PUR时机之前开始监视PDCCH。在一实例中，UE可在第一子帧T1接收寻呼消息。UE监视PDCCH的可配置时间段(例如，PUR搜索空间窗)可开始于第二子帧(T1+start_offset)，和/或可结束于第三子帧(T1+start_offset+window_length-1)。举例来说，UE可在第二子帧(T1+start_offset)开始监视PDCCH，和/或继续监视PDCCH直至第三子帧(T1+start_offset+window_length-1)。在一些实施例中，响应于在可配置时间段期间接收到网络响应，UE可停止监视PDCCH。替代地和/或另外，响应于在可配置时间段期间接收到网络响应，UE可继续监视PDCCH直至第三子帧(T1+start_offset+window_length-1)。

图17说明其中UE在可配置时间段1708(例如，PUR搜索空间窗)期间监视PDCCH的示例性情形。在一些实施例中，UE在第一子帧T1接收指示MT-EDT的寻呼消息1702。响应于接收到寻呼消息1702，UE可执行一个或多个UE动作1710。所述一个或多个UE动作1710可包括确定与UE相关联的时序提前是否有效的动作1712。在一些实施例中，一个或多个UE动作1710可包括在可配置时间段1708期间监视PDCCH以接收网络响应的动作1714。在一些实施例中，可基于确定时序提前有效而执行在可配置时间段1708期间监视PDCCH。替代地和/或另外，可执行在可配置时间段1708期间监视PDCCH而不顾及时序提前是否有效。在一些实施例中，可配置时间段1708可基于偏移1706、第一子帧T1和/或可配置时间段1708的窗长度而确定。在一些实施例中，可配置时间段1708可在PUR时机1704(例如，用于UE的即将到来的PUR时机和/或下一可用PUR时机)之前开始。举例来说，可配置时间段1708可在第三子帧(例如，第一子帧T1+偏移1706)开始，且在第四子帧(例如，第一子帧T1+偏移1706+窗长度-1)结束。在一些实施例中，响应于在可配置时间段1708期间接收到网络响应，UE可停止监视PDCCH。替代地和/或另外，响应于在可配置时间段1708期间接收到网络响应，UE可继续监视PDCCH直至第四子帧。

在一些实施例中，start_offset可等于零(例如，零子帧、零秒等中的至少一者)。在一些实施例中，start_offset可为正值(例如，可配置时间段可在接收到寻呼消息之后开始)。在一些实施例中，start_offset可为负值(例如，可配置时间段可在接收到寻呼消息之前开始)。在一些实施例中，start_offset可预定义。在一些实施例中，start_offset可在PUR配置和/或配置于PUR配置中的PUR搜索空间配置中配置。window_length可为可配置时间段(例如，PUR搜索空间窗)的持续时间(和/或长度)。window_length可配置于PUR配置和/或PUR搜索空间配置中。

在一些实施例中，PUR时机可为下一可用PUR时机。PUR时机可为在UE接收到指示MT-EDT的寻呼消息之后在时间上最接近的PUR时机(例如，接收到寻呼消息之后的初始PUR时机)。举例来说，在UE接收到寻呼消息的时间与PUR时机的时间之间可能不存在与UE相关联的其它PUR时机。

在一些实施例中，UE可在可配置时间段期间接收网络响应。网络响应可包括下行链路数据。UE可基于配置于PUR配置中的PUR搜索空间配置而监视PDCCH。在一些实施例中，UE可经由PDCCH接收网络响应，和/或UE可在可配置时间段期间在UE监视PDCCH的同时接收网络响应。

在一些实施例中，网络响应可包括RRC消息。在一些实施例中，RRC消息可为RRCEarlyDataComplete消息。替代地和/或另外，RRC消息可为RRCConnectionResume消息。替代地和/或另外，RRC消息可为RRCConnectionRelease消息。替代地和/或另外，RRC消息可为RRCConnectionSetup消息。替代地和/或另外，RRC消息可为经设计用于MT-EDT的新RRC消息，例如RRCEarlyDLDataComplete消息。在一些实施例中，RRC消息可包括下行链路数据。在一些实施例中，下行链路数据可包封于RRC消息中。替代地和/或另外，下行链路数据可与RRC消息多路复用。在一些实施例中，网络响应可不包括RRC消息(和/或在网络响应中可能不存在RRC消息)。

在其中响应于网络响应和/或(网络响应的)下行链路数据的上行链路数据可用(和/或其中指示UE响应于网络响应和/或下行链路数据而传送上行链路数据)的实例中，UE可使用提供于网络响应中的上行链路准予来传送上行链路数据。举例来说，UE可使用由网络响应中的上行链路准予指示的一或多个资源来传送上行链路数据。替代地和/或另外，UE可使用下一PUR时机(例如，在接收到网络响应之后的用于UE的即将到来的PUR时机和/或下一可用PUR时机)来传送上行链路数据。替代地和/或另外，UE可发起用于EDT的RA程序(例如，用于MO-EDT的RA程序)以传送上行链路数据(例如，UE可在RA程序中传送上行链路数据)。替代地和/或另外，UE可发起并非用于EDT的RA程序(例如，并非用于MO-EDT的RA程序)以传送上行链路数据(例如，UE可在RA程序中传送上行链路数据)。

在一些实施例中，如果未在可配置时间段期间接收到网络响应(和/或未在可配置时间段期间接收到网络响应)，则UE可发起用于MT-EDT的RA程序。替代地和/或另外，如果未在可配置时间段期间接收到网络响应(和/或未在可配置时间段期间接收到网络响应)，则UE可发起用于EDT的RA程序(例如，用于MO-EDT的RA程序)。替代地和/或另外，如果未在可配置时间段期间接收到网络响应(和/或未在可配置时间段期间接收到网络响应)，则UE可发起RA程序，其中RA程序既不用于MT-EDT也不用于EDT。

在实施例4中，在其中存在重复传送(例如上行链路传送(例如，上行链路数据)和/或下行链路传送(例如，寻呼消息))的实例中，相对于实施例4描述的与传送相关联的子帧时序(例如，在上行链路数据经由PUR时机传送的实施例中，子帧时序可对应于与寻呼消息的接收相关联的子帧T1和/或与上行链路数据的传送相关联的子帧T2)可对应于与传送的第一重复或传送的最后重复相关联的子帧。在一些实施例中，与寻呼消息的接收相关联的子帧T1对应于网络到UE的寻呼消息的传送的最后重复(例如，可能在子帧T1执行网络到UE的寻呼消息的传送的最后重复)。在其中上行链路数据经由PUR时机传送的实施例中，与上行链路数据相关联的子帧T2可对应于上行链路数据的传送的第一重复(例如，可在子帧T2执行UE到网络的上行链路数据的传送的第一重复)。

以上技术和/或实施例中的一个、一些和/或全部可以形成为新实施例。

在一些实例中，可独立地和/或单独地实施本文中所公开的实施例，例如相对于实施例1、实施例2、实施例3和实施例4描述的实施例。替代地和/或另外，可实施本文中所公开的实施例(例如相对于实施例1、实施例2、实施例3和/或实施例4描述的实施例)中的两者或更多者的组合。替代地和/或另外，可并行和/或同时实施本文中所公开的实施例(例如相对于实施例1、实施例2、实施例3和/或实施例4描述的实施例)中的两者或更多者的组合。

本公开的各种技术可以独立地和/或彼此单独地执行。替代地和/或另外，本公开的各种技术可以组合和/或使用单个***实施。替代地和/或另外，本公开的各种技术可以并行和/或同时实施。

UE可在接收到指示MT-EDT的寻呼消息时基于是否存在可用于传送的上行链路数据而确定实施实施例3或实施例4中的至少一者。举例来说，如果在接收到指示MT-EDT的寻呼消息时存在可用于传送的上行链路数据，则UE可执行包括上行链路数据的PUR传送，和/或UE可监视PDCCH以用于接收包括下行链路数据的网络响应，例如根据实施例3。替代地和/或另外，如果在接收到指示MT-EDT的寻呼消息时不存在可用于传送的上行链路数据，则UE可不执行PUR传送，和/或UE可监视PDCCH以用于接收包括下行链路数据的网络响应而不执行PUR传送，例如根据实施例4。

可组合实施例1与实施例2的各种技术。在其中UE正根据实施例2执行一个或多个动作的实例中，响应于UE确定发起用于MT-EDT的RA程序，UE可不释放PUR配置(例如，专用PUR配置)，例如根据实施例1。

相对于实施例1、实施例2、实施例3和/或实施例4描述的前述技术和/或实施例中的一个、一些和/或全部可适用于MTC UE、NB-IoT UE和/或其它类型的UE。可由MTC UE、NB-IoT UE和/或其它类型的UE实施和/或执行相对于实施例1、实施例2、实施例3和/或实施例4描述的前述技术和/或动作中的一个、一些和/或全部。

图18是从UE的角度看的根据一个示例性实施例的流程图1800。在步骤1805中，UE从网络节点接收指示MT-EDT的寻呼消息。在步骤1810中，响应于接收到寻呼消息，UE确定与一个或多个PUR相关联的时序参数的有效性。在步骤1815中，UE基于所述有效性确定是发起用于MT-EDT的RA程序还是发起使用一个或多个PUR的传送。

在一个实施例中，确定时序参数的有效性包括确定时序参数无效。

在一个实施例中，UE基于确定所述时序参数无效而发起用于MT-EDT的RA程序。在一个实施例中，UE在用于MT-EDT的RA程序期间将上行链路消息传送到网络节点。

在一个实施例中，确定时序参数的有效性包括确定时序参数有效。

在一个实施例中，UE基于确定时序参数有效而使用一个或多个PUR将第一上行链路消息传送到网络节点。在一个实施例中，UE在一定时间段期间监视PDCCH。在一个实施例中，UE在所述时间段期间从网络节点接收第一下行链路消息。举例来说，UE可经由PDCCH接收第一下行链路消息，和/或UE可在所述时间段期间在UE监视PDCCH的同时接收第一下行链路消息。

在一个实施例中，响应于接收到所述第一下行链路消息，UE将第二上行链路消息传送到所述网络节点，其中所述第二上行链路消息包括响应于包括在所述第一下行链路消息中的下行链路数据的上行链路数据。举例来说，第二上行链路消息中的上行链路数据可为对第一下行链路消息中的下行链路数据的响应。

在一个实施例中，在接收寻呼消息之前，UE从网络节点接收与一个或多个PUR相关联的第一PUR配置。

在一个实施例中，时序参数为时序提前或时序调整。在一个实施例中，确定时序参数的有效性是基于第一PUR配置中的验证准则而执行。所述验证准则可与时序参数相关联。举例来说，验证准则可为时序提前验证准则。替代地和/或另外，验证准则可为时序调整验证准则。

在一个实施例中，验证准则包括与一个或多个PUR相关联的定时器。举例来说，定时器可为时序提前定时器。替代地和/或另外，定时器可为时序调整定时器。替代地和/或另外，定时器可为时间对准定时器。在一个实施例中，确定时序参数的有效性包括基于确定定时器在运行中而确定时序参数有效。在一个实施例中，确定时序参数的有效性包括基于确定定时器不在运行中而确定时序参数无效。

在一个实施例中，基于第一PUR配置监视PDCCH。

在一个实施例中，所述时间段为PUR搜索空间窗，和/或所述时间段的时长配置于第一PUR配置中。

在一个实施例中，第一上行链路消息的传送是在第一PUR时机执行，和/或第一PUR时机为接收到寻呼消息时的下一可用PUR时机。举例来说，在接收到寻呼消息的时间与第一PUR时机之间可能不存在与UE相关联的其它PUR时机。

在一个实施例中，第一上行链路消息包括第一RRC消息，和/或第一下行链路消息包括第二RRC消息。

返回参考图3和4，在UE的一个示例性实施例中，装置300包含存储在存储器310中的程序代码312。CPU 308可执行程序代码312以使得UE能够：(i)从网络节点接收指示MT-EDT的寻呼消息；(ii)响应于接收到寻呼消息而确定与一个或多个PUR相关联的时序参数的有效性；以及(iii)基于所述有效性确定是发起用于MT-EDT的RA程序还是发起使用一个或多个PUR的传送。此外，CPU 308可以执行程序代码312，以执行上述动作和步骤和/或本文中描述的其它动作和步骤中的一个、一些和/或全部。

图19是从UE的角度看的根据一个示例性实施例的流程图1900。在步骤1905中，UE从网络节点接收指示MT-EDT的寻呼消息。在步骤1910中，响应于接收到寻呼消息，UE确定与一个或多个PUR相关联的时序参数有效。在步骤1915中，UE基于确定时序参数有效而使用一个或多个PUR将第一上行链路消息传送到网络节点。在步骤1920中，UE在一定时间段期间监视PDCCH。在步骤1925中，UE在所述时间段期间从网络节点接收第一下行链路消息。举例来说，UE可经由PDCCH接收第一下行链路消息，和/或UE可在所述时间段期间在UE监视PDCCH的同时接收第一下行链路消息。

在一个实施例中，响应于接收到所述第一下行链路消息，UE将第二上行链路消息传送到所述网络节点，其中所述第二上行链路消息包括响应于包括在所述第一下行链路消息中的下行链路数据的上行链路数据。举例来说，第二上行链路消息中的上行链路数据可为对第一下行链路消息中的下行链路数据的响应。

在一个实施例中，在接收寻呼消息之前，UE从网络节点接收与一个或多个PUR相关联的第一PUR配置。

在一个实施例中，时序参数为时序提前或时序调整。

在一个实施例中，确定时序参数有效是基于第一PUR配置中的验证准则而执行。所述验证准则可与时序参数相关联。举例来说，验证准则可为时序提前验证准则。替代地和/或另外，验证准则可为时序调整验证准则。

在一个实施例中，验证准则包括与一个或多个PUR相关联的定时器。举例来说，定时器可为时序提前定时器。替代地和/或另外，定时器可为时序调整定时器。替代地和/或另外，定时器可为时间对准定时器。

在一个实施例中，确定时序参数有效是基于确定定时器在运行中。

在一个实施例中，基于第一PUR配置监视PDCCH。

在一个实施例中，所述时间段为PUR搜索空间窗，和/或所述时间段的时长配置于第一PUR配置中。

在一个实施例中，第一上行链路消息的传送是在第一PUR时机执行，和/或第一PUR时机为接收到寻呼消息时的下一可用PUR时机。举例来说，在接收到寻呼消息的时间与第一PUR时机之间可能不存在与UE相关联的其它PUR时机。

在一个实施例中，第一上行链路消息包括第一RRC消息，和/或第一下行链路消息包括第二RRC消息。

返回参考图3和4，在UE的一个示例性实施例中，装置300包含存储在存储器310中的程序代码312。CPU 308可执行程序代码312以使得UE能够：(i)从网络节点接收指示MT-EDT的寻呼消息；(ii)响应于接收到寻呼消息而确定与一个或多个PUR相关联的时序参数有效；(iii)基于确定时序参数有效而使用一个或多个PUR将第一上行链路消息传送到网络节点；(iv)在一定时间段期间监视PDCCH；以及(v)在所述时间段期间从网络节点接收第一下行链路消息。此外，CPU 308可以执行程序代码312，以执行上述动作和步骤和/或本文中描述的其它动作和步骤中的一个、一些和/或全部。

提供一种通信装置(例如，UE、基站、网络节点等)，其中所述通信装置可以包括控制电路、安装在控制电路中的处理器和/或安装在控制电路中并且耦合到处理器的存储器。处理器可经配置以执行存储于所述存储器中的程序代码以执行图18到19中说明的一个、一些和/或全部的方法步骤。此外，处理器可以执行程序代码以执行上述动作和步骤和/或本文中描述的其它动作和步骤中的一个、一些和/或全部。

可以提供计算机可读媒体。所述计算机可读媒体可以是非暂时性计算机可读媒体。计算机可读媒体可包括快闪存储器装置、硬盘驱动器、盘(例如，磁盘和/或光盘，例如数字多功能盘(digital versatile disc，DVD)、压缩盘(compact disc，CD)等中的至少一者)，和/或存储器半导体，例如静态随机存取存储器(static random access memory，SRAM)、动态随机存取存储器(dynamic random access memory，DRAM)、同步动态随机存取存储器(synchronous dynamic random access memory，SDRAM)等中的至少一者。计算机可读媒体可包括处理器可执行指令，所述处理器可执行指令在被执行时致使执行图18到19中所说明的一个、一些和/或全部的方法步骤，和/或上述动作和步骤和/或本文中描述的其它动作和步骤中的一个、一些和/或全部。

可了解，由于以下操作中的至少一者：基于时序参数是否有效确定是发起RA程序还是发起PUR传送、基于确定时序参数有效而确定发起PUR传送而非RA程序，并且由于如果用于MT-EDT的RA程序发起则不释放PUR配置，使得网络可能不需要再次提供PUR配置等，应用本文中呈现的技术中的一或多者可导致一个或多个益处，包含但不限于在其中配置有一个或多个PUR(例如，一个或多个专用PUR)的UE接收指示MT-EDT的寻呼消息的情形中改进效率和/或降低功率消耗、信令开销和/或调度延迟。

上文已经描述了本发明的各种方面。应明白，本文中的教示可以通过多种多样的形式实施，且本文中所公开的任何具体结构、功能或这两者仅是代表性的。基于本文中的教示，所属领域的技术人员应了解，本文公开的方面可以独立于任何其它方面而实施，且可以各种方式组合这些方面中的两个或多于两个方面。举例来说，可使用本文中所阐述的任何数目个方面来实施设备或实践方法。另外，通过使用除了在本文中所阐述的方面中的一个或多个之外或不同于在本文中所阐述的方面中的一个或多个的其它结构、功能性或结构和功能性可以实施此设备或可以实践此方法。作为一些上述概念的示例，在一些方面，可基于脉冲重复频率来建立并行信道。在一些方面中，可以基于脉冲位置或偏移建立并行信道。在一些方面中，可以基于时间跳频序列建立并行信道。在一些方面中，可基于脉冲重复频率、脉冲位置或偏移以及时间跳频序列而建立并行信道。

所属领域的技术人员将理解，可以使用多种不同技术及技艺中的任一者来表示信息和信号。举例来说，可通过电压、电流、电磁波、磁场或磁粒子、光场或光粒子或其任何组合来表示在整个上文描述中可能参考的数据、指令、命令、信息、信号、位、符号和码片。

所属领域的技术人员将进一步了解结合本文公开的方面描述的各种说明性逻辑块、模块、处理器、构件、电路和算法步骤可以被实施为电子硬件(例如，数字实施方案、模拟实施方案或两者的组合，其可以使用信源编码或某种其它技术来设计)、各种形式的并入有指令的程序或设计代码(为方便起见，本文可以称为“软件”或“软件模块”)，或两者的组合。为清晰地说明硬件与软件的此可互换性，上文已大体就各种说明性组件、块、模块、电路和步骤的功能性加以描述。这类功能性是以硬件来实施还是以软件来实施取决于特定应用和强加于整个***的设计约束。所属领域的技术人员可针对每一具体应用以不同方式来实施所描述的功能性，但这样的实施决策不应被解释为会引起脱离本发明的范围。

另外，结合本文公开的方面描述的各种说明性逻辑块、模块和电路可以实施于集成电路(integrated circuit，“IC”)、接入终端或接入点内或者由集成电路、接入终端或接入点执行。IC可以包括通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或其它可编程逻辑装置、离散门或晶体管逻辑、离散硬件组件、电气组件、光学组件、机械组件，或其经设计以执行本文中所描述的功能的任何组合，且可以执行驻留在IC内、在IC外或两种情况下的代码或指令。通用处理器可以是微处理器，但在替代方案中，处理器可以是任何的常规处理器、控制器、微控制器或状态机。处理器还可实施为计算装置的组合，例如，DSP与微处理器的组合、多个微处理器、一个或多个微处理器结合DSP核心，或任何其它此类配置。

应理解，在任何所公开的过程中的步骤的任何具体次序或层次都是样本方法的实例。应理解，基于设计偏好，过程中的步骤的具体次序或层次可以重新布置，同时保持在本发明的范围内。随附的方法权利要求以样本次序呈现各种步骤的元素，且并不有意限于所呈现的特定次序或阶层。

结合本文中公开的方面所描述的方法或算法的步骤可直接用硬件、用处理器执行的软件模块或用这两者的组合体现。软件模块(例如，包含可执行指令和相关数据)和其它数据可以驻留在数据存储器中，例如RAM存储器、快闪存储器、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移除式磁盘、CD-ROM或此项技术中已知的任何其它形式的计算机可读存储媒体。样本存储媒体可以耦合到例如计算机/处理器等机器(为方便起见，所述机器在本文中可以称为“处理器”)，使得所述处理器可以从存储媒体读取信息(例如，代码)且将信息写入到存储媒体。样本存储媒体可与处理器形成一体。处理器及存储媒体可驻留在ASIC中。ASIC可以驻留在用户设备中。在替代方案中，处理器和存储媒体可以作为离散组件驻留于用户设备中。替代地和/或另外，在一些方面中，任何合适的计算机程序产品可以包括计算机可读媒体，所述计算机可读媒体包括与本发明的方面中的一或多者相关的代码。在一些方面中，计算机程序产品可以包括封装材料。

虽然已经结合各个方面描述了所公开的主题，但应理解，所公开的主题能够进一步修改。本申请案意欲涵盖一般遵循所公开主题的原理的所公开主题的任何变化、使用或调适，并且包含所公开主题所涉及领域内已知和惯常的实践范围内出现的对本公开的偏离。

Claims (20)

1.一种用户设备的方法，其特征在于，所述方法包括：

从网络节点接收指示移动终止提前数据传送的寻呼消息；

响应于接收到所述寻呼消息，确定与一个或多个预配置上行链路资源相关联的时序参数的有效性；以及

基于所述有效性，确定是发起用于移动终止提前数据传送的随机接入程序还是发起使用所述一个或多个预配置上行链路资源的传送。

2.根据权利要求1所述的方法，其特征在于，进一步包括：

基于确定所述时序参数无效而发起用于移动终止提前数据传送的所述随机接入程序；以及

在用于移动终止提前数据传送的所述随机接入程序期间将第一上行链路消息传送到所述网络节点。

3.根据权利要求1所述的方法，其特征在于，进一步包括：

基于确定所述时序参数有效，使用所述一个或多个预配置上行链路资源将第一上行链路消息传送到所述网络节点；

在某一时间段期间监视物理下行链路控制信道；以及

在所述时间段期间从所述网络节点接收第一下行链路消息。

4.根据权利要求3所述的方法，其特征在于，进一步包括：

响应于接收到所述第一下行链路消息，将第二上行链路消息传送到所述网络节点，其中所述第二上行链路消息包括响应于包括在所述第一下行链路消息中的下行链路数据的上行链路数据。

5.根据权利要求1所述的方法，其特征在于，进一步包括：

在接收所述寻呼消息之前，从所述网络节点接收与所述一个或多个预配置上行链路资源相关联的第一预配置上行链路资源配置。

6.根据权利要求5所述的方法，其特征在于：

所述时序参数为时序提前或时序调整；

所述确定所述时序参数的所述有效性是基于包含在所述第一预配置上行链路资源配置中的验证准则而执行；且

所述验证准则与所述时序参数相关联。

7.根据权利要求6所述的方法，其特征在于：

所述验证准则包括与所述一个或多个预配置上行链路资源相关联的定时器；且

所述确定所述时序参数的所述有效性包括：

基于确定所述定时器在运行中而确定所述时序参数有效；或

基于确定所述定时器不在运行中而确定所述时序参数无效。

8.根据权利要求3所述的方法，其特征在于，进一步包括：

在接收所述寻呼消息之前，从所述网络节点接收与所述一个或多个预配置上行链路资源相关联的第一预配置上行链路资源配置，其中：

所述监视所述物理下行链路控制信道是基于所述第一预配置上行链路资源配置而执行；

所述时间段为预配置上行链路资源搜索空间窗；且

所述时间段的时长配置于所述第一预配置上行链路资源配置中。

9.根据权利要求3所述的方法，其特征在于：

所述传送所述第一上行链路消息是在第一预配置上行链路资源时机执行；且

所述第一预配置上行链路资源时机是在接收到所述寻呼消息时的下一可用预配置上行链路资源时机。

10.根据权利要求3所述的方法，其特征在于：

所述第一上行链路消息包括第一无线电资源控制消息；且

所述第一下行链路消息包括第二无线电资源控制消息。

11.一种通信装置，其特征在于，包括：

处理器；以及

包括处理器可执行指令的存储器，所述处理器可执行指令在由所述处理器执行时使操作得以执行，所述操作包括：

从网络节点接收指示移动终止提前数据传送的寻呼消息；

响应于接收到所述寻呼消息，确定与一个或多个预配置上行链路资源相关联的时序参数的有效性；以及

基于所述有效性，确定是发起用于移动终止提前数据传送的随机接入程序还是发起使用所述一个或多个预配置上行链路资源的传送。

12.根据权利要求11所述的通信装置，其特征在于，所述操作进一步包括：

基于确定所述时序参数无效而发起用于移动终止提前数据传送的所述随机接入程序；以及

在用于移动终止提前数据传送的所述随机接入程序期间将第一上行链路消息传送到所述网络节点。

13.根据权利要求11所述的通信装置，其特征在于，所述操作进一步包括：

基于确定所述时序参数有效，使用所述一个或多个预配置上行链路资源将第一上行链路消息传送到所述网络节点；

在某一时间段期间监视物理下行链路控制信道；以及

在所述时间段期间从所述网络节点接收第一下行链路消息。

14.根据权利要求13所述的通信装置，其特征在于，所述操作进一步包括：

响应于接收到所述第一下行链路消息，将第二上行链路消息传送到所述网络节点，其中所述第二上行链路消息包括响应于包括在所述第一下行链路消息中的下行链路数据的上行链路数据。

15.根据权利要求11所述的通信装置，其特征在于，所述操作进一步包括：

在接收所述寻呼消息之前，从所述网络节点接收与所述一个或多个预配置上行链路资源相关联的第一预配置上行链路资源配置。

16.根据权利要求15所述的通信装置，其特征在于：

所述时序参数为时序提前或时序调整；

所述确定所述时序参数的所述有效性是基于包含在所述第一预配置上行链路资源配置中的验证准则而执行；且

所述验证准则与所述时序参数相关联。

17.根据权利要求16所述的通信装置，其特征在于：

所述验证准则包括与所述一个或多个预配置上行链路资源相关联的定时器；且

所述确定所述时序参数的所述有效性包括：

基于确定所述定时器在运行中而确定所述时序参数有效；或

基于确定所述定时器不在运行中而确定所述时序参数无效。

18.根据权利要求13所述的通信装置，其特征在于，所述操作进一步包括：

在接收所述寻呼消息之前，从所述网络节点接收与所述一个或多个预配置上行链路资源相关联的第一预配置上行链路资源配置，其中：

所述监视所述物理下行链路控制信道是基于所述第一预配置上行链路资源配置而执行；

所述时间段为预配置上行链路资源搜索空间窗；且

所述时间段的时长配置于所述第一预配置上行链路资源配置中。

19.根据权利要求13所述的通信装置，其特征在于：

所述传送所述第一上行链路消息是在第一预配置上行链路资源时机执行；且

所述第一预配置上行链路资源时机是在接收到所述寻呼消息时的下一可用预配置上行链路资源时机。

20.根据权利要求13所述的通信装置，其特征在于：

所述第一上行链路消息包括第一无线电资源控制消息；且

所述第一下行链路消息包括第二无线电资源控制消息。

Images