用户设备及其执行的方法、基站及其执行的方法
阅读：274发布：2020-05-11
专利汇可以提供用户设备及其执行的方法、基站及其执行的方法专利检索，专利查询，专利分析的服务。并且本 发明 提供一种用户设备执行的方法、用户设备、基站执行的方法以及基站。所述用户设备执行的方法包括：所述UE从基站接收寻呼消息；和所述UE在基于所述寻呼消息发起RRC连接建立过程或RRC连接恢复过程时，基于下行早期数据传输EDT指示信息来判断是否执行下行EDT准备操作。，下面是用户设备及其执行的方法、基站及其执行的方法专利的具体信息内容。
1.一种用户设备UE执行的方法，包括：
所述UE从基站接收寻呼消息；和
所述UE在基于所述寻呼消息发起RRC连接建立过程或RRC连接恢复过程时，基于下行早期数据传输EDT指示信息来判断是否执行下行EDT准备操作。
2.根据权利要求1所述的方法，其中，
所述下行EDT指示信息包含在系统信息中或者所述寻呼消息中。
3.根据权利要求2所述的方法，其中，
在所述下行EDT指示信息存在时，执行所述下行EDT准备操作，在所述下行EDT指示信息不存在时，不执行所述下行EDT准备操作；
或者，
在所述下行EDT指示信息的值为1或TURE时，执行所述下行EDT准备操作，在所述下行EDT指示信息的值为0或FALSE时，不执行所述下行EDT准备操作。
4.根据权利要求2所述的方法，其中，
所述下行EDT指示信息包含增强覆盖等级信息，所述UE基于所述增强覆盖等级信息来判断是否执行所述下行EDT准备操作。
5.根据权利要求1所述的方法，其中，
所述下行EDT指示信息为所述寻呼消息中包含的下行EDT UE标识列表，
在所述UE的UE标识包含在所述下行EDT UE标识列表时，所述UE执行所述下行EDT准备操作。
6.根据权利要求1所述的方法，其中，
所述下行EDT指示信息是用M比特表示的一个整数，且对应于所述寻呼消息中包含的UE标识列表中的对应的条目。
7.根据权利要求1所述的方法，其中，
所述下行EDT准备操作包含以下操作的至少一种操作：
恢复DRB和/或SRB对应的PDCP状态；
重建DRB和/或SRB的PDCP实体；
若最近之前的RRC连接释放消息中提供了drb-continueROHC指示，且所述UE在同一个小区内恢复或建立RRC连接，则指示下层使用所保存的UE接入层上下行且配置了drb-continueROHC，对配置了头压缩协议的DRB继续头压缩协议上下文，若最近之前的RRC连接释放消息中未提供drb-continueROHC指示，或者UE在不同小区内恢复或建立RRC连接，则指示下层使用所保存的UE接入层上下文，对配置了头压缩协议的DRB重置其头压缩协议上下文；
恢复DRB和/或SRB；
使用所保存的NCC的值，并基于当前密钥KeNB所关联的KASME密钥派生出KeNB密钥；
派生出先前配置的完整性算法所关联的KRRCint密钥；
派生出先前配置的加密算法所关联KRRCenc密钥和KUPenc密钥；
配置下层使用先前配置的完整性算法和派生出来的KRRCint密钥对后续所述UE接收和发送的消息恢复完整性保护；
配置下层使用先前配置的加密算法和派生出来的KRRCenc密钥对后续所述UE接收和发送的消息恢复加密/解密；
配置下层使用先前配置的加密算法和派生出来的KUPenc密钥立即对所述UE所发送或接收的用户数据恢复加密/解密；
恢复安全；和
配置下层使用EDT。
8.一种用户设备UE，包括：
处理器；以及
存储器，存储有指令；
其中，所述指令在由所述处理器运行时执行根据权利要求1至7中任一项所述的方法。
9.一种基站执行的方法，包括：
所述基站向用户设备UE发送寻呼消息；和
通过下行早期数据传输EDT指示信息，向所述UE指示在基于所述寻呼消息发起RRC连接建立过程或RRC连接恢复过程时是否执行下行EDT准备操作。
10.一种基站，包括：
处理器；以及
存储器，存储有指令；
其中，所述指令在由所述处理器运行时执行根据权利要求9所述的方法。
用户设备及其执行的方法、基站及其执行的方法
技术领域
[0001] 本公开涉及无线通信技术领域，更具体地，本公开涉及一种用户设备执行的方法、用户设备、基站执行的方法以及基站。
背景技术
[0002] 2017年3月，在第三代合作伙伴计划(3rd Generation Partnership Project：3GPP)RAN#75次全会上，一个关于窄带物联网(NarrowBand Internet Of things，NB-IoT)进一步增强的新工作项目(参见RP-170852：New WID on Further NB-IoT enhancements)和一个关于机器类通信(Machine Type Communication：MTC)更进一步增强的新的工作项目(参见非专利文献：RP-170732：New WID on Even further enhanced MTC for LTE)获得批准。这两个研究项目的目标之一是针对小数据包业务的传输进行增强，考虑小数据包业务在一段时间内所要传输的数据量比较小，比如1000比特，即通过一个物理层的传输块即可传完，而现有机制中数据传输都必须在完成与空口的连接进行无线资源控制(Radio Resource Control，RRC)连接状态之后才能完成，这使得用于传输小数据包的信令开销比较大，考虑到MTC或NB-IoT的用户终端数据庞大，导致了更严重的信令开销；同时过大的信令开销也导致了不必要的用户终端能耗。为了使得能以较少的信令开销来完成小数据包的传输，并实现用户终端(User Equipment，UE)的节能，在版本15的小数据传输增强中，提出UE可以不进入RRC连接态来实现数据传输，比如在更早的时候在随机接入过程中将小数据和随机接入消息3一起发送。版本15的小数据传输增强方案对上行小数据传输机制进行了增强，使得UE在RRC连接建立之前通过随机接入消息3就可以将数据发送给基站，但由于时间关系，并没有对下行小数据传输进行讨论。
[0003] 2018年6月，在第三代合作伙伴计划(3rd Generation Partnership Project：3GPP)RAN#80次全会上，一个关于窄带物联网(NarrowBand Internet Of things，NB-IoT)进一步增强的新工作项目(参见RP-181451：New WID on R16enhancement for NB-IoT)获得批准。这个研究项目的目标之一就是在NB-IoT网络中实现移动终止(Mobile Terminating)的下行早期小数据传输。其中，移动终止指的是业务传输的终止端是用户，即网络侧发起的下行业务传输，区别于用户侧发起(Mobile Originating)的上行业务传输。。
[0004] 本公开主要就如何实现移动终止的下行早期小数据传输提出解决方法。发明内容
[0005] 为了解决上述问题，本公开提供一种用户设备执行的方法、用户设备、基站执行的方法以及基站。
[0006] 根据本发明的第一方面，提供了一种用户设备UE执行的方法，包括：所述UE从基站接收寻呼消息；和所述UE在基于所述寻呼消息发起RRC连接建立过程或RRC连接恢复过程时，基于下行早期数据传输EDT指示信息来判断是否执行下行EDT准备操作。
[0007] 在上述方法中，所述下行EDT指示信息包含在系统信息中或者所述寻呼消息中。
[0008] 在上述方法中，在所述下行EDT指示信息存在时，执行所述下行EDT准备操作，在所述下行EDT指示信息不存在时，不执行所述下行EDT准备操作；或者，在所述下行EDT指示信息的值为1或TURE时，执行所述下行EDT准备操作，在所述下行EDT指示信息的值为0或FALSE时，不执行所述下行EDT准备操作。
[0009] 在上述方法中，所述下行EDT指示信息包含增强覆盖等级信息，所述UE基于所述增强覆盖等级信息来判断是否执行所述下行EDT准备操作。
[0010] 在上述方法中，所述下行EDT指示信息为所述寻呼消息中包含的下行EDT UE标识列表，在所述UE的UE标识包含在所述下行EDT UE标识列表时，所述UE执行所述下行EDT准备操作。
[0011] 在上述方法中，所述下行EDT指示信息是用M比特表示的一个整数，且对应于所述寻呼消息中包含的UE标识列表中的对应的条目。
[0012] 在上述方法中，所述下行EDT准备操作包含以下操作的至少一种操作：恢复DRB和/或SRB对应的PDCP状态；重建DRB和/或SRB的PDCP实体；若最近之前的RRC连接释放消息中提供了drb-continueROHC指示，且所述UE在同一个小区内恢复或建立RRC连接，则指示下层使用所保存的UE接入层上下行且配置了drb-continueROHC，对配置了头压缩协议的DRB继续头压缩协议上下文，若最近之前的RRC连接释放消息中未提供drb-continueROHC指示，或者UE在不同小区内恢复或建立RRC连接，则指示下层使用所保存的UE接入层上下文，对配置了头压缩协议的DRB重置其头压缩协议上下文；恢复DRB和/或SRB；使用所保存的NCC的值，并基于当前密钥KeNB所关联的KASME密钥派生出KeNB密钥；派生出先前配置的完整性算法所关联的KRRCint密钥；派生出先前配置的加密算法所关联KRRCenc密钥和KUPenc密钥；配置下层使用先前配置的完整性算法和派生出来的KRRCint密钥对后续所述UE接收和发送的消息恢复完整性保护；配置下层使用先前配置的加密算法和派生出来的KRRCenc密钥对后续所述UE接收和发送的消息恢复加密/解密；配置下层使用先前配置的加密算法和派生出来的KUPenc密钥立即对所述UE所发送或接收的用户数据恢复加密/解密；恢复安全；和配置下层使用EDT。
[0013] 根据本发明的第二方面，提供了一种用户设备UE，包括：处理器；以及存储器，存储有指令；其中，所述指令在由所述处理器运行时执行根据上下文所述的方法。
[0014] 根据本发明的第三方面，提供了一种基站执行的方法，包括：所述基站向用户设备UE发送寻呼消息；和通过下行早期数据传输EDT指示信息，向所述UE指示在基于所述寻呼消息发起RRC连接建立过程或RRC连接恢复过程时是否执行下行EDT准备操作。
[0016] 通过下文结合附图的详细描述，本公开的上述和其它特征将会变得更加明显，其中：
[0018] 图2示出了基于本公开的实施例的基站执行的方法200的流程图。
[0019] 图3示出了基于本公开的实施例的用户设备30的框图。
[0020] 图4示出了基于本公开的实施例的基站40的框图。
具体实施方式
[0021] 根据结合附图对本公开示例性实施例的以下详细描述，本公开的其它方面、优势和突出特征对于本领域技术人员将变得显而易见。
[0022] 在本公开中，术语“包括”和“含有”及其派生词意为包括而非限制；术语“或”是包含性的，意为和/或。
[0023] 在本说明书中，下述用于描述本公开原理的各种实施例只是说明，不应该以任何方式解释为限制公开的范围。参照附图的下述描述用于帮助全面理解由权利要求及其等同物限定的本公开的示例性实施例。下述描述包括多种具体细节来帮助理解，但这些细节应认为仅仅是示例性的。因此，本领域普通技术人员应认识到，在不背离本公开的范围和精神的情况下，可以对本文中描述的实施例进行多种改变和修改。此外，为了清楚和简洁起见，省略了公知功能和结构的描述。此外，贯穿附图，相同参考数字用于相似功能和操作。
[0024] 下文以LTE移动通信系统及其后续的演进版本作为示例应用环境，具体描述了根据本公开的多个实施方式。然而，需要指出的是，本公开不限于以下实施方式，而是可适用于更多其它的无线通信系统，如NB-IoT系统中、MTC系统中，也可以用于5G下一代无线通信系统(New Radio，NR)中。
[0025] 本公开中的基站可以是任何类型基站，包含Node B、增强基站eNB，也可以是5G通信系统基站gNB、或者微基站、微微基站、宏基站、家庭基站等；所述小区也可以是上述任何类型基站下的小区。UE可以指NB-IoT UE、带宽降低低复杂度(Bandwidth reduced Low complexity，BL)UE、或在增强覆盖(enhanced coverage)中的UE、也可以是其他UE如5G NR UE。本公开下述实施例中，指示(indicate/indication)和通知(notify/notification)或知会/信息(inform/information)可以互换，增强覆盖与覆盖增强(coverage enhancement)可以互换。
[0026] 不同的实施例之间也可以结合工作。
[0027] 下面先对本公开涉及到的一些概念和进行说明。值得注意的是，在下文的描述中的一些命名仅是实例说明性的，而不是限制性的，也可以作其他命名。
[0028] 增强覆盖等级：增强覆盖技术中将需要增强覆盖的程度分为多个增强覆盖等级，比如在NB-IoT中，增强覆盖等级可以是等级0～2。在一些增强覆盖方法中，每一个增强覆盖等级可以对应一套不同的无线参数配置，如随机接入配置(如PRACH(Physical Random Access CHannel)资源)，比如对增强覆盖等级高的配置更多的重复次数等。
[0029] 寻呼(Paging)：寻呼消息用于在通知RRC空闲态或RRC不活动态的UE有下行数据将要到达或者通知UE系统信息的更新。当用于前者时，寻呼消息中包含一个UE标识列表，如下述代码中所示(下述仅示出了本公开相关寻呼消息的内容，略去了不相关的寻呼消息部分)，接收到寻呼消息的UE，若其标识包含在寻呼消息中，则UE认为其被寻呼到，该UE将有下行数据传输。随后UE会发起RRC连接建立或RRC连接恢复过程和网络侧建立联系，响应所收到的寻呼消息，完成下行传输。
[0030]
[0031] 随机接入响应(Random Access Response，RAR)：随机接入过程中的第二条消息。基站会在接收到UE的随机接入前导之后，通过发送随机接入响应消息来对该随机接入前导的接收进行响应。随机接入响应消息中包括时间提前域、上行许可(uplink grant)域、UE标识域等。
[0032] 消息3：随机接入过程中的第三条消息。在本公开中，消息3统指UE在RAR中包含的上行许可所指示的上行资源上所发送的上行传输。如在RRC连接建立过程中，消息3中对应的RRC消息为RRC连接建立请求消息，在RRC连接恢复过程中，消息3中对应的RRC消息为RRC连接恢复请求消息。在本公开中，为了描述方便，除了所述RRC消息，有时消息3也包括包含在消息3中一起传输的上层数据。
[0033] 消息4：随机接入过程中，用于响应消息3的下行消息，由基站发送给UE。在消息4中可以包含UE用于随机接入竞争解析的随机接入竞争解析标识以确定本次随机接入是否成功；还可以包括用于响应消息3中RRC消息的下行RRC消息。例如，当消息3中的RRC消息为RRC早期数据请求消息时，消息4中的RRC消息可以是RRC早期数据完成消息；当消息3中的RRC消息为RRC连接建立请求消息时，消息4中包含的RRC消息可以是RRC连接建立消息或RRC连接拒绝消息；当消息3中的RRC消息为RRC连接恢复请求消息时，消息4中包含的RRC消息可以是RRC连接恢复消息、RRC连接拒绝消息或RRC连接释放消息。在本公开中，为了描述方便，有时消息4电包含伴随消息4一起传输的用户面数据(承载在数据无线承载((user)Data Radio Bearer，DRB)上)或者包含消息4的媒介接入控制层(Medium Access Control，MAC)数据包。
[0034] 控制面优化方案和用户面优化方案：
[0035] 在R15之前的通信系统中，已经支持两种优化的数据传输方案，以用来降低数据传输的信令开销和UE能耗，称控制面蜂窝演进分组服务优化(cp-CIoT-EPS-Optimisation)和用户面蜂窝演进分组服务优化(up-CIoT-EPS-Optimisation)。在控制面蜂窝演进分组服务优化方案中，应用层的数据作为一个非接入层(Non Access Stratum，NAS)数据包包含在控制面的信令无线承载(Signalling Radio Bearer，SRB)上传输，可简称为控制面优化方案或控制面方案。在用户面蜂窝演进分组服务优化方案中，仍和传统系统中的数据传输一样应用层的数据在RRC连接状态下的数据无线承载((user)Data Radio Bearer，DRB)上传输，但在当数据传输完成后，UE和eNB挂起(suspend)RRC连接(通过包含挂起指示的RRC连接释放消息来指示)，保存UE上下文，进入RRC空闲状态。当UE要进行数据传输时，UE向eNB发起RRC连接恢复流程(在该流程中，UE向基站发送RRC连接恢复请求消息来发起连接恢复，基站向UE发送RRC连接恢复消息来指示其恢复RRC连接，继而UE向基站反馈RRC连接恢复完成消息以进行响应)，因为UE和eNB上保存了UE上下文，通过该流程可以恢复其RRC连接、SRB、DRB和安全，无需重新建立RRC连接、DRB和安全。这种方案也可简称用户面优化方案或用户面方案。其中UE保存了UE上下文的RRC空闲态，虽然也称RRC空闲态，但实际上可以看做一个RRC空闲态和连接态的一个中间状态。这个中间状态，在5G NR系统中，可以认为是其定义的RRC非活动状态(RRC_inactive)。
[0036] 在版本14的用户面方案中，发起了RRC连接恢复流程的UE在发送了RRC连接恢复请求消息(消息3)后，会等待接收RRC连接恢复消息(消息4)。如果RRC连接恢复消息的完整性校验失败，则UE执行离开RRC连接态的操作(UE执行离开RRC连接态的操作可参见3GPP技术规范36.331的5.3.12章节)，即认为可能受到了安全方面的攻击，会结束该RRC连接恢复过程而直接进入RRC空闲态。如果RRC连接恢复消息的完整性校验成功，则UE继续执行RRC连接恢复消息中的内容，并进入RRC连接状态。
[0037] R15中的早期数据传输(Early Data Transmission，EDT)：
[0038] R15中的小数据传输优化方案基于上述两种方案优化了早期小数据的传输。上行早期小数据传输指的是在随机接入过程中伴随消息3一起传输小数据，因为这种优化方式相较传统数据传输方式而言，能够在更早的时刻完成数据传输，所以称为早期数据传输，本公开中，小数据(small data或small packet)可等同于早期数据(early data)。对R15的上行早期数据传输，UE通过在随机接入过程中采用EDT特定的PRACH传输资源或随机接入前导来向基站指示其将要进行EDT传输。
[0039] 对基于控制面方案的上行EDT，用户面数据作为NAS PDU包含在消息3的RRC消息中通过SRB完成传输。对基于用户面方案的上行EDT，用户面数据和RRC消息(消息3)在MAC层完成复用组包成同一个MAC协议数据单元(Protocol Data Unit，PDU)进行传输，用户数据是通过DRB传输而RRC消息是通过SRB传输的，这就要求UE在触发EDT过程时就要恢复(或称(重新)激活)DRB和安全，以及对各协议层应用RRC挂起之前的无线配置，UE在该RRC过程中恢复安全是基于在前一次的RRC连接过程中获取的NCC来派生出新的安全秘钥(包括加密秘钥和完整性秘钥)的，更进一步地，NCC是从前一次的RRC连接过程中用于释放UE RRC连接使UE进入挂起RRC连接的空闲态或RRC inactive态的RRC连接释放消息中获取的。这不同于传统非EDT传输中只有在接收到消息4后基于RRC消息中配置的NCC才恢复DRB/SRB和安全。
[0040] 在上述上行EDT中，因为上行EDT是由UE主动发起的，所以UE可以在EDT发起时，提前进行EDT所需的准备工作，比如在用户面方案中，UE在发起EDT的RRC过程时就恢复安全、SRB和DRB。而在下行EDT中，若要正确进行下行EDT，UE也需要提前进行EDT所需的准备工作，但所谓移动终止的下行EDT是由基站发起的，在当前的协议中UE无法获知基站何时会发起下行EDT，即对一个移动终止的下行传输而言，UE无法判定基站是否会使用EDT方式，因此也无法判定何时进行下行EDT的准备工作。有一种可能的解决方法是在一个移动终止的下行传输中，有EDT功能的UE在收到寻呼消息后，总是提前进行下行EDL的准备工作，不管此时传输是否使用下行EDT的方式。但这种解决方法在当UE所驻留的小区是版本15的基站即不支持下行EDT的基站时，如前所述，EDT和非EDT传输的安全恢复机制不一样，在这种场景下，UE使用的是EDT的安全恢复机制，而版本15的基站则采用的是非EDT的安全恢复机制，会导致UE和基站上的安全恢复状态不同步，加密和完整性校验的密钥不一致，从而使得安全校验失败，UE进入空闲状态。所以本公开主要就在接收到寻呼消息时UE如何判定基站是否会使用EDT方式给出解决方法。
[0041] 下面，对本公开中的用户设备UE执行的方法进行说明，作为一例，图1中表示基于本公开的实施例的用户设备执行的方法100的流程图。
[0042] 在步骤S101中，用户设备UE从基站接收寻呼消息。该寻呼消息用于在移动终止的业务传输中告知处于RRC空闲态或不活动态(inactive)的UE有下行业务传输。
[0043] 在步骤S102中，用户设备UE在基于接收到的寻呼消息发起RRC连接建立过程或RRC连接恢复过程时，基于下行早期数据传输EDT指示信息来判断是否执行下行EDT准备操作。
[0044] 具体而言，收到寻呼消息的用户设备UE，若其UE标识包含在寻呼消息中，则发起RRC连接建立过程或RRC连接恢复过程。
[0045] 上述的下行EDT指示信息可以包含在系统信息中，也可以包含在所述寻呼消息中，由基站进行发送。
[0046] 此外，关于如何判断是否执行下行EDT准备操作，可以在在下行EDT指示信息存在时，执行下行EDT准备操作，在下行EDT指示信息不存在时，不执行下行EDT准备操作。此外，也可以在在下行EDT指示信息的值为1或TURE时，执行下行EDT准备操作，在下行EDT指示信息的值为0或FALSE时，不执行下行EDT准备操作。再有，关于该下行EDT准备操作的具体操作内容，作为一例，可以参照下述的实施例1中的准备工作。
[0047] 另外，上述的下行EDT指示信息可以包含增强覆盖等级信息，用户设备UE可以基于增强覆盖等级信息来判断是否执行下行EDT准备操作。具体而言，例如，若基站发送的下行EDT指示信息存在，用户设备UE的增强覆盖等级小于或小于等于下行EDT指示信息中所配置的值，则用户贞UE在发起RRC连接建立过程或RRC连接恢复过程时，执行下行EDT的准备操作。另一方面，若未接收到基站发送的下行EDT指示信息或用户设备UE的增强覆盖等级大于或大于等于下行EDT指示信息中所配置的值，则用户设备UE在发起RRC连接建立过程或RRC连接恢复过程时，不执行下行EDT的准备工作。
[0048] 此外，对本公开中的基站执行的方法进行说明，作为一例，图2中表示基于本公开的实施例的基站执行的方法200的流程图。
[0049] 在步骤201中，基站向用户设备UE发送寻呼消息。该寻呼消息用于在移动终止的业务传输中告知处于RRC空闲态或不活动态(inactive)的UE有下行业务传输。
[0050] 在步骤S202中，基站通过下行EDT指示信息，向用户设备UE指示在基于寻呼消息发起RRC连接建立过程或RRC连接恢复过程时是否执行下行EDT准备操作。
[0051] 此外，图3示出了根据本公开实施例的用户设备30的框图。如图3所示，该用户设备30包括处理器301和存储器302。处理器301例如可以包括微处理器、微控制器、嵌入式处理器等。存储器302例如可以包括易失性存储器(如随机存取存储器RAM)、硬盘驱动器(HDD)、非易失性存储器(如闪速存储器)、或其他存储器系统等。存储器302上存储有程序指令。该指令在由处理器301运行时，可以执行本公开详细描述的由用户设备执行的上述方法。
[0052] 另外，图4示出了根据本公开实施例的基站40的框图。如图4所示，该基站40包括处理器401和存储器402。如上述所述，本公开中的基站40基站可以是任何类型基站，包含但不限于：Node B、增强基站eNB、5G通信系统基站gNB、或者微基站、微微基站、宏基站、家庭基站等。处理器401例如可以包括微处理器、微控制器、嵌入式处理器等。存储器402例如可以包括易失性存储器(如随机存取存储器RAM)、硬盘驱动器(HDD)、非易失性存储器(如闪速存储器)、或其他存储器系统等。存储器402上存储有程序指令。该指令在由处理器401运行时，可以执行本公开详细描述的由基站执行的上述方法。
[0053] 以下，对本公开所涉及的具体实施例进行详细说明。另外，如上所述，本公开中的实施例是为了容易理解本发明而进行的示例性说明，并不是对本发明的限定。
[0054] 实施例1：
[0055] 下面，对本发明的实施例1进行说明。该实施例1给出了一种在UE上执行的UE判定是否使用EDT方式发起移动终止的业务传输的方法。
[0056] 步骤1：UE从基站接收下行EDT指示信息，优选地，该指示信息包含在系统信息中，如系统信息块1或系统信息块2。优选地，该步骤还包括UE存储所收到的下行EDT指示信息。步骤1是可选的。
[0057] 所述下行EDT指示信息，用于指示该小区(是否)支持或允许下行EDT。换句话说，用于指示UE是否被允许下行EDT。在一种实现方式中，若所述下行EDT指示信息存在，则UE认为该小区支持或允许下行EDT，若所述下行EDT指示信息不存在，则UE认为该小区不支持或不允许下行EDT。在另一种实现方式中，若所述下行EDT指示信息设置为1或TURE，则UE认为该小区支持或允许下行EDT，若所述下行EDT指示信息设置为0或FALSE，则UE认为该小区不支持或不允许下行EDT。
[0058] 步骤2：UE从基站接收寻呼消息。该寻呼消息用于在移动终止的业务传输中告知处于RRC空闲态或不活动态(inactive)的UE有下行业务传输。
[0059] 步骤3：收到寻呼消息的UE，若其UE标识(如国际移动用标识(International Mobile Subscriber Identity，IMSI)或系统架构演进临时移动端标识(System Architecture Evolution Temporary Mobile Station Identifier，S-TMSI)或非激活态无线网络临时标识(Inactive Radio Network Temporary Identifier，I-RNTI)包含在寻呼消息中，发起RRC连接建立过程或RRC连接恢复过程来建立和网络侧的联系，优选地，所述发起的RRC连接建立过程或RRC连接恢复过程的建立原因是mt-access。若在步骤1中基站发送的下行EDT指示信息存在或其值置为1或TURE，则UE在发起RRC连接建立过程或RRC连接恢复过程时，执行下行EDT的准备工作。可选地，否则若在步骤1中未接收到基站发送的下行EDT指示信息或接收到的下行EDT指示信息值设置为0或FALSE，则UE在发起RRC连接建立过程或RRC连接恢复过程时，不执行下行EDT的准备工作。若在用户面方案中(即若UE正在发起用户面EDT(UP-EDT))，所述执行下行EDT的准备工作包括下述操作的一种或多种：
[0060] √恢复(restore)DRB和/或SRB对应的PDCP状态；优选地，恢复所有DRB和所有SRB对应的PDCP状态。
[0061] √重建DRB和/或SRB的PDCP实体；优选地，重建所有DRB和所有SRB的PDCP实体。
[0062] √若最近之前的RRC连接释放消息中提供了drb-continueROHC指示，且UE在同一个小区内恢复或建立RRC连接，则指示下层使用所保存的UE接入层上下行且配置了drb-continueROHC，对配置了头压缩协议的DRB继续头压缩协议上下文；否则(若最近之前的RRC连接释放消息中未提供drb-continueROHC指示，或UE在不同小区内恢复或建立RRC连接，)，指示下层使用所保存的UE接入层上下文，对配置了头压缩协议的DRB重置其头压缩协议上下文。其中，drb-continueROHC用于指示对配置了头压缩协议的DRB继续头压缩协议上下文，若drb-continueROHC不配置则对配置了头压缩协议的DRB重置(reset)其头压缩协议上下文。
[0063] √恢复(resume)DRB和/或SRB。优选地，恢复所有SRB和DRB。
[0064] √使用所保存的NCC的值，并基于当前密钥KeNB所关联的KASME密钥派生出KeNB密钥。
[0065] √派生出先前配置的完整性算法所关联的KRRCint密钥。
[0066] √派生出先前配置的加密算法所关联KRRCenc密钥和KUPenc密钥。
[0067] √配置下层使用先前配置的完整性算法和上述派生出来的KRRCint密钥对后续所有UE接收和发送的消息恢复完整性保护。
[0068] √配置下层使用先前配置的加密算法和上述派生出来的KRRCenc密钥对后续所有UE接收和发送的消息恢复加密/解密。
[0069] √配置下层使用先前配置的加密算法和上述派生出来的KUPenc密钥立即对UE所发送或接收的用户数据恢复加密/解密。
[0070] √恢复安全。
[0071] √配置下层使用EDT。
[0072] 实施例2
[0073] 以下，对本发明的实施例2进行说明。实施例2与实施例1的不同之处在于，所述下行EDT指示信息还包括了增强覆盖等级信息。该实施例在UE上执行。
[0074] 步骤1：UE从基站接收下行EDT指示信息，优选地，该指示信息包含在系统信息中，如系统信息块1或系统信息块2。优选地，该步骤还包括UE存储所收到的下行EDT指示信息。步骤1是可选的。
[0075] 所述下行EDT指示信息，用于指示该小区(是否)支持或允许下行EDT。换句话说，用于指示UE是否被允许下行EDT。更进一步地，所述下行EDT指示信息包含增强覆盖等级信息，用于指示该小区支持或允许下行EDT的增强覆盖等级。在一种实现方式中，所述下行EDT指示信息包含一个整数N，若UE的增强覆盖等级大于或大于等于N，则不支持或不允许使用下行EDT，若UE的增强覆盖等级小于或小于等于N，则支持或允许使用下行EDT。
[0076] 步骤2：UE从基站接收寻呼消息。该寻呼消息用于在移动终止的业务传输中告知处于RRC空闲态或不活动态(inactive)的UE有下行业务传输。
[0077] 步骤3：收到寻呼消息的UE，若其UE标识(如国际移动用标识(International Mobile Subscriber Identity，IMSI)或S-TMSI或I-RNTI)包含在寻呼消息中，发起RRC连接建立过程或RRC连接恢复过程来建立和网络侧的联系，优选地，所述发起的RRC连接建立过程或RRC连接恢复过程的建立原因是mt-access。若在步骤1中基站发送的下行EDT指示信息存在，UE的增强覆盖等级小于或小于等于下行EDT指示信息中所配置的值，则UE在发起RRC连接建立过程或RRC连接恢复过程时，执行下行EDT的准备工作。可选地，否则若在步骤1中未接收到基站发送的下行EDT指示信息或UE的增强覆盖等级大于或大于等于下行EDT指示信息中所配置的值，则UE在发起RRC连接建立过程或RRC连接恢复过程时，不执行下行EDT的准备工作。若在用户面方案中(即若UE正在发起用户面EDT(UP-EDT))，所述执行下行EDT的准备工作与实施例1中一样，此处不赘述。
[0078] 实施例3
[0079] 以下，对本发明的实施例3进行说明。该实施例3与实施例1的不同在于，所述下行EDT指示信息包含在寻呼消息中。该实施例在UE上执行。
[0080] 步骤1：UE从基站接收包含下行EDT指示信息的寻呼消息。该寻呼消息用于在移动终止的业务传输中告知处于RRC空闲态或不活动态(inactive)的UE有下行业务传输。
[0081] 所述下行EDT指示信息，用于指示对本次下行业务(是否)使用下行EDT方式。换句话说，用于指示UE是否使用下行EDT来发起随后的RRC连接建立/恢复过程。所述本次下行业务(不)使用下行EDT方式也可以表述为本次寻呼(不)是对下行EDT方式的用户数据传输的。所述下行EDT指示信息的实现方法在后续实施例4～5中说明，但值得注意的是，实施例4～5仅为举例，本公开并不限定所述下行EDT指示信息的实现方法。
[0082] 步骤2：收到寻呼消息的UE，若其UE标识(如IMSI或S-TMSI或I-RNTI)包含在寻呼消息中，发起RRC连接建立过程或RRC连接恢复过程来建立和网络侧的联系。优选地，所述发起的RRC连接建立过程或RRC连接恢复过程的建立原因是mt-access。。在发起RRC过程的时候，UE根据所接收到的寻呼消息中的下行EDT标识信息判断本次下行传输是否使用下行EDT方式，即是否执行下行EDT的准备工作。若判断的结果为是，则UE在发起RRC连接建立过程或RRC连接恢复过程时，执行下行EDT的准备工作。可选地，若判断的结果为否，则UE在发起RRC连接建立过程或RRC连接恢复过程时，不执行下行EDT的准备工作。若在用户面方案中(即若UE正在发起用户面EDT(UP-EDT))，所述执行下行EDT的准备工作所包含的操作同实施例1中所述，此处不赘述。
[0083] 实施例4
[0084] 以下，对本发明的实施例4进行说明。该实施例4给出了一种UE判断本次传输是否使用下行EDT的方法。
[0085] 在该实施例中，若寻呼消息中该UE关联的所述下行EDT指示信息存在或置为TURE，则UE认为本次下行业务使用下行EDT方式，若所述下行EDT指示信息不存在，则UE认为本次下行业务不使用下行EDT方式。
[0086] 在这种实施方式中，所述下行EDT指示信息(如下面的EDTindication-r16信息元素)包含在寻呼消息中的pagingrecord信息元素中，该信息元素中包含一个UE标识，表示所述寻呼消息是关联到所述UE标识所对应的UE的。
[0087] PagingRecord-NB-r13：：＝SEQUENCE{
[0088] ue-Identity-r13 PagingUE-Identity，
[0089] EDTindication-r16 ENUMERATED{true}
[0090] ...
[0091] }
[0092] 在本实施例的另一中方式中，若所述下行EDT指示信息设置为1，则UE认为本次下行业务使用下行EDT方式，若所述下行EDT指示信息设置为0，则UE认为本次下行业务不使用下行EDT方式。
[0093] PagingRecord-NB-r13：：＝SEQUENCE{
[0094] ue-Identity-r13 PagingUE-Identity，
[0095] EDTindication-r16 BOOLEN
[0096] ...
[0097] }
[0098] 实施例5
[0099] 以下，对本发明的实施例5进行说明。该实施例5给出了一种UE判断本次传输是否使用下行EDT的方法。
[0100] 在该实施例中，在寻呼消息中除现有的UE标识列表之外，引入一个新的UE标识列表(如pagingrecordlist-r16信息元素)，新的UE标识列表中的UE标识所指示的UE的本次寻呼消息所触发的下行传输使用EDT方式。具体来说，若寻呼消息中该UE标识包含在新的UE标识列表中，则UE认为本次下行业务使用下行EDT方式，若寻呼消息中该UE标识不包含在新的UE标识列表中(即包含在传统pagingrecondlist中)，则UE认为本次下行业务不使用下行EDT方式。
[0101] 在这种实施方式中，所述下行EDT指示信息(如下面的pagingrecordlist-r16信息元素)为在寻呼消息中的新的寻呼UE标识列表。
[0102] Paging-NB：：＝SEQUENCE{
[0103] pagingRecordList-r13 PagingRecordList-NB-r13 OPTIONAL，
[0104] pagingRecordList-r16 PagingRecordList-NB-r16 OPTIONAL，
[0105] }
[0106] 实施例6
[0107] 以下，对本发明的实施例6进行说明。该实施例6给出了一种UE判断本次传输是否使用下行EDT的方法。
[0108] 在该实施例中，在寻呼消息中除现有的UE标识列表之外，引入一个下行EDT指示信息，所述下行EDT指示信息可以是用M比特表示的一个整数，该下行EDT指示信息的值对应于UE标识列表中的对应的条目(entry)。举例来说，若该下行EDT指示信息的值设置为N，则表示对UE标识列表(即pagingrecordlist)中前N个(或后N个)UE标识条目所对应的UE的下行传输采用EDT方式。
[0109] 收到寻呼消息的UE，若其UE标识包含在寻呼消息中的UE标识列表中，且若配置了下行EDT指示信息值N且UE标识处于UE标识列表中的前N个(或后N个)，则UE认为随后的下行传输是EDT方式。UE在发起对应的RRC连接建立或RRC连接恢复过程时使用EDT方式，即执行下行EDT的准备操作。可选地，否则若其UE标识包含在寻呼消息中的UE标识列表中，且若未配置下行EDT指示信息值N或UE标识不是处于UE标识列表中的前N个(或后N个)，则UE认为随后的下行传输是不是EDT方式。UE在发起对应的RRC连接建立或RRC连接恢复过程时不使用EDT方式，即不执行下行EDT的准备操作。
[0110] 在这种实施方式中，所述下行EDT指示信息(如下面的EDTindication-r16信息元素)包含在寻呼消息中，为一个整数。
[0111]
[0112] 以上，对基于用户设备UE的实施例进行了说明，也就是说对在用户设备UE上执行的实施例1～6进行了说明。下面，对基于基站的实施例进行说明，下述实施例在基站上实施，对应于上述在UE上执行的实施例1～6。
[0113] 实施例7
[0114] 实施例7中给出了一种使用EDT方式发起移动终止的业务传输的方法。
[0115] 步骤1：基站向UE发送下行EDT指示信息，优选地，该指示信息包含在系统信息中，如系统信息块1或系统信息块2。步骤1是可选的。
[0116] 所述下行EDT指示信息，用于指示该小区(是否)支持或允许下行EDT。换句话说，用于指示UE是否被允许下行EDT。在一种实现方式中，若该小区支持或允许下行EDT，则基站设置所述下行EDT指示信息存在，若该小区不支持或不允许下行EDT，则基站设置所述下行EDT指示信息不存在。在另一种实现方式中，若该小区支持或允许下行EDT，则基站设置所述下行EDT指示信息为1或TURE，若该小区不支持或不允许下行EDT，则基站设置所述下行EDT指示信息为0或FALSE。
[0117] 步骤2：基站发送寻呼消息。该寻呼消息用于在移动终止的业务传输中告知处于RRC空闲态或不活动态(inactive)的UE有下行业务传输。
[0118] 步骤3：若步骤1中基站指示了本小区支持或允许下行EDT，则基站认为UE在响应寻呼消息的RRC连接建立或RRC连接恢复过程中执行了EDT准备操作，基站使用UE接入层上下文中所保存的NCC来派生相关安全密钥并激活安全，用于消息4的发送；若步骤1中基站指示了本小区不支持或不允许下行EDT，则基站认为UE在响应寻呼消息的RRC连接建立或RRC连接恢复过程中未执行了EDT准备操作，基站为UE在消息4中分配新的NCC，并基于该NCC来派生相关安全密钥并激活安全，用于消息4的发送；
[0119] 实施例8
[0120] 以下对本发明的实施例8进行说明，该实施例8与实施例7的不同之处在于，所述下行EDT指示信息还包括了增强覆盖等级信息。
[0121] 步骤1：基站向UE发送下行EDT指示信息，优选地，该指示信息包含在系统信息中，如系统信息块1或系统信息块2。步骤1是可选的。
[0122] 所述下行EDT指示信息，用于指示该小区(是否)支持或允许下行EDT。换句话说，用于指示UE是否被允许下行EDT。在一种实现方式中，若该小区支持或允许下行EDT，则基站设置所述下行EDT指示信息存在，若该小区不支持或不允许下行EDT，则基站设置所述下行EDT指示信息不存在。在另一种实现方式中，若该小区支持或允许下行EDT，则基站设置所述下行EDT指示信息为1或TURE，若该小区不支持或不允许下行EDT，则基站设置所述下行EDT指示信息为0或FALSE。
[0123] 所述下行EDT指示信息，用于指示该小区(是否)支持或允许下行EDT。换句话说，用于指示UE是否被允许下行EDT。更进一步地，所述下行EDT指示信息包含增强覆盖等级信息，用于指示该小区支持或允许下行EDT的增强覆盖等级。在一种实现方式中，所述下行EDT指示信息包含一个整数N，若UE的增强覆盖等级大于或大于等于N，则不支持或不允许使用下行EDT，若UE的增强覆盖等级小于或小于等于N，则支持或允许使用下行EDT。
[0124] 步骤2：基站向UE发送寻呼消息。该寻呼消息用于在移动终止的业务传输中告知处于RRC空闲态或不活动态(inactive)的UE有下行业务传输。
[0125] 步骤3：若在步骤1中基站发送的下行EDT指示信息存在，基站所获知的UE的增强覆盖等级小于或小于等于下行EDT指示信息中所配置的值，则基站认为UE在响应寻呼消息的RRC连接建立或RRC连接恢复过程中执行了EDT准备操作，基站使用UE接入层上下文中所保存的NCC来派生相关安全密钥并激活安全，用于消息4的发送；若在步骤1中基站未发送的下行EDT指示信息或基站所获知的UE的增强覆盖等级大于或大于等于下行EDT指示信息中所配置的值，则基站认为UE在响应寻呼消息的RRC连接建立或RRC连接恢复过程中未执行了EDT准备操作，基站为UE在消息4中分配新的NCC，并基于该NCC来派生相关安全密钥并激活安全，用于消息4的发送。
[0126] 实施例9
[0127] 以下，对本发明的实施例9进行说明，该实施例9与实施例7的不同在于，所述下行EDT指示信息包含在寻呼消息中。该实施例在UE上执行。
[0128] 步骤1：基站向UE发送包含下行EDT指示信息的寻呼消息。该寻呼消息用于在移动终止的业务传输中告知处于RRC空闲态或不活动态(inactive)的UE有下行业务传输。
[0129] 所述下行EDT指示信息，用于指示对本次下行业务(是否)使用下行EDT方式。换句话说，用于指示UE是否使用下行EDT来发起随后的RRC连接建立/恢复过程。所述本次下行业务(不)使用下行EDT方式也可以表述为本次寻呼(不)是对下行EDT方式的用户数据传输的。所述下行EDT指示信息的实现方法在后续实施例10～12中说明，但值得注意的是，实施例10～12仅为举例，本公开并不限定所述下行EDT指示信息的实现方法。
[0130] 步骤2：若在步骤1中，基站发送的寻呼消息中对一个UE所关联的下行EDT指示信息指示对该UE本次下行传输使用下行EDT方式，则基站认为UE在响应寻呼消息的RRC连接建立或RRC连接恢复过程中执行了EDT准备操作，基站使用UE接入层上下文中所保存的NCC来派生相关安全密钥并激活安全，用于消息4的发送；若在步骤1中，基站发送的寻呼消息中对一个UE所关联的下行EDT只是信息知识对该UE本次下行传输不使用下行EDT方式，则基站认为UE在响应寻呼消息的RRC连接建立或RRC连接恢复过程中未执行了EDT准备操作，基站为UE在消息4中分配新的NCC，并基于该NCC来派生相关安全密钥并激活安全，用于消息4的发送；
[0131] 实施例10
[0132] 以下，对本发明的实施例10进行说明，该实施例10给出了一种下行EDT指示信息的设置方式。
[0133] 在该实施例中，若基站确认该UE本次下行业务使用下行EDT方式，则寻呼消息中该UE关联的所述下行EDT指示信息存在或置为TURE或1；若基站确认该UE本次下行业务不使用下行EDT方式，则寻呼消息中该UE关联的所述下行EDT指示信息不存在或置为FALSE或0。
[0134] 在这种实施方式中，所述下行EDT指示信息(如下面的EDTindication-r16信息元素)包含在寻呼消息中的pagingrecord信息元素中，该信息元素中包含一个UE标识，表示所述寻呼消息是关联到所述UE标识所对应的UE的。
[0135] PagingRecord-NB-r13：：＝SEQUENCE{
[0136] ue-Identity-r13 PagingUE-Identity，
[0137] EDTindication-r16 ENUMERATED{true}
[0138] ...
[0139] }
[0140] 在本实施例的另一中方式以代码的形式示例如下：
[0141] PagingRecord-NB-r13：：＝SEQUENCE{
[0142] ue-Identity-r13 PagingUE-Identity，
[0143] EDTindication-r16 BOOLEN
[0144] ...
[0145] }
[0146] 实施例11
[0147] 以下，对本发明的实施例11进行说明，该实施例11给出了一种下行EDT指示信息的设置方式。
[0148] 在该实施例中，在寻呼消息中除现有的UE标识列表之外，引入一个新的UE标识列表(如pagingrecordlist-r16信息元素)，新的UE标识列表中的UE标识所指示的UE的本次寻呼消息所触发的下行传输使用EDT方式。具体来说，若基站确定一个UE本次下行业务使用下行EDT方式，则基站将寻呼消息中该UE标识包含在新的UE标识列表中；若基站确定一个UE本次下行业务不使用下行EDT方式，则基站将寻呼消息中该UE标识不包含在新的UE标识列表中(即包含在传统pagingrecondlist中)。
[0149] 在这种实施方式中，所述下行EDT指示信息(如下面的pagingrecordlist-r16信息元素)为在寻呼消息中的新的寻呼UE标识列表。
[0150] Paging-NB：：＝SEQUENCE{
[0151] pagingRecordList-r13 PagingRecordList-NB-r13 OPTIONAL，
[0152] pagingRecordList-r16 PagingRecordList-NB-r16 OPTIONAL，
[0153] }
[0154] 实施例12
[0155] 以下，对本发明的实施例12进行说明，该实施例12给出了一种下行EDT指示信息的设置方式。
[0156] 在该实施例中，在寻呼消息中除现有的UE标识列表之外，引入一个下行EDT指示信息，所述下行EDT指示信息可以是用M比特表示的一个整数，该下行EDT指示信息的值对应于UE标识列表中的对应的条目(entry)。举例来说，若该下行EDT指示信息的值设置为N，则表示对UE标识列表(即pagingrecordlist)中前N个(或后N个)UE标识条目所对应的UE的下行传输采用EDT方式。
[0157] 若基站确定一个UE的本次下行传输采用EDT方式，则基站在寻呼消息中包含所述下行EDT指示信息，其值设置为N，并将该UE对应的UE标识包含在寻呼消息中的UE标识列表中的前N个(或后N个)条目中。若基站确定一个UE的本次下行传输不采用EDT方式，则基站在寻呼消息中不包含所述下行EDT指示信息，或者包含取值设置为N得所述下行EDT指示信息，并将该UE对应的UE标识包含在寻呼消息中的UE标识列表中的后N个(或前N个)条目中。
[0158] 在这种实施方式中，所述下行EDT指示信息(如下面的EDTindication-r16信息元素)包含在寻呼消息中，为一个整数。
[0159]
[0160] 实施例13
[0161] 以下，对本发明的实施例13进行说明。
[0162] 在上述实施例9中，基站在发送寻呼消息时需要确定对一个UE的本次下行传输是否使用下行EDT方式，如前所述是否使用EDT方式主要基于业务数据大小的判断，可选地，还可以结合UE的增强覆盖等级信息进行判断。该实施例13提供了一种在基站上执行的获取业务数据量大小信息的方法，用于帮助基站确认是否使用下行EDT方式进行下行传输。
[0163] 步骤1：基站从网络侧实体(如移动性管理实体(Mobility Management Entity，MME))接收针对一个UE的寻呼消息。该寻呼消息中携带本次寻呼所关联的下行传输的下行业务量大小信息。可选地，该寻呼消息中还携带有UE的增强覆盖等级信息。
[0164] 所述下行业务量大小信息可以是具体的包大小数值，比如X比特或X字节；也可以是一个整数，用于表示大概的数据量大小，比如1标识数据量为1～200比特；2表示数据量为200～400个比特，以此类推。
[0166] 步骤2：基站基于获取的下行业务量大小信息，可选地，还可以基于获取的UE增强覆盖等级信息，确定UE的本次寻呼对应的下行传输是否使用EDT方式。优选地，如果确定结果为是，基站在空口的寻呼消息中包含下行EDT指示信息，如果否，基站不在空口的寻呼消息中包含下行EDT指示信息。
[0167] 实施例14
[0168] 本实施例提出一种下行EDT指示方式，在UE上执行。与前述实施例不同的是，所述下行EDT指示信息包含在下行控制信息(Downlink Control Information，DCI)中在物理下行控制信道(Physical Downlink Control Channel，PDCCH)上传输。该实施例用于UE在接收消息4之前尚未获取任何基站是否在本次移动终止的下行传输中是否使用下行EDT方式的信息，所以通过用于调度消息4的PDCCH来获取所述下行EDT指示信息。
[0169] 步骤1：UE接收用于调度消息4下行传输的PDCCH信令。可选地，所述PDCCH信令中包含下行EDT指示信息。所述下行EDT指示信息如前所述，用于指示步骤2中的消息4中包含下行EDT数据。
[0170] 步骤1之前还包括UE发起随机接入过程，并执行随机接入过程的前三条消息的传输，包括发送随机接入前导、接收RAR和发送消息3。
[0171] 步骤2：UE接收包含消息4的物理下行共享信道(Physical Downlink Shared CHannel)传输。
[0172] 步骤3：若UE基于消息4中的竞争解决标识MAC控制元素判断本次随机接入竞争解决成功，且若步骤1中收到的PDCCH信息中包含下行EDT指示信息，则UE将所述下行EDT指示信息告知上层，所述上层至少是RRC层，备选地，还可以是MAC层。
[0173] 步骤4：RRC层收到来自下层的下行EDT指示信息，则RRC层执行下行EDT的准备工作，并在所述准备工作结束后对步骤2中所述消息4执行L2处理。所述下行EDT的准备工作参见实施例1，此处不赘述。
[0174] 实施例15
[0175] 本实施例提出了一种放弃EDT操作的方法，在UE上执行。
[0176] 在本实施例中，当UE收到底层发来的(上行)EDT取消的指示，若底层指示的此次回退(即EDT取消)是响应于用于(上行)EDT的RRC连接恢复请求的且所述回退不是由于RAR中所提供的上行许可不是用于EDT的，且若UE不准备(not expect)接收下行EDT，则UE执行用户面EDT的放弃操作，所述EDT的放弃操作请参见3GPP协议规范文档36.331的5.3.3.9a章节。
[0177] 所述UE不准备接收下行EDT，在一种实现方式中，可表述为UE所接收到的寻呼消息中不包含下行EDT指示，或UE未接收到下行EDT指示。
[0178] 运行在根据本公开的设备上的程序可以是通过控制中央处理单元(CPU)来使计算机实现本公开的实施例功能的程序。该程序或由该程序处理的信息可以临时存储在易失性存储器(如随机存取存储器RAM)、硬盘驱动器(HDD)、非易失性存储器(如闪速存储器)、或其他存储器系统中。
[0179] 用于实现本公开各实施例功能的程序可以记录在计算机可读记录介质上。可以通过使计算机系统读取记录在所述记录介质上的程序并执行这些程序来实现相应的功能。此处的所谓“计算机系统”可以是嵌入在该设备中的计算机系统，可以包括操作系统或硬件(如外围设备)。“计算机可读记录介质”可以是半导体记录介质、光学记录介质、磁性记录介质、短时动态存储程序的记录介质、或计算机可读的任何其他记录介质。
[0180] 用在上述实施例中的设备的各种特征或功能模块可以通过电路(例如，单片或多片集成电路)来实现或执行。设计用于执行本说明书所描述的功能的电路可以包括通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、或其他可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或上述器件的任意组合。通用处理器可以是微处理器，也可以是任何现有的处理器、控制器、微控制器、或状态机。上述电路可以是数字电路，也可以是模拟电路。因半导体技术的进步而出现了替代现有集成电路的新的集成电路技术的情况下，本公开的一个或多个实施例也可以使用这些新的集成电路技术来实现。
[0181] 此外，本公开并不局限于上述实施例。尽管已经描述了所述实施例的各种示例，但本公开并不局限于此。安装在室内或室外的固定或非移动电子设备可以用作终端设备或通信设备，如AV设备、厨房设备、清洁设备、空调、办公设备、自动贩售机、以及其他家用电器等。
[0182] 如上，已经参考附图对本公开的实施例进行了详细描述。但是，具体的结构并不局限于上述实施例，本公开也包括不偏离本公开主旨的任何设计改动。另外，可以在权利要求的范围内对本公开进行多种改动，通过适当地组合不同实施例所公开的技术手段所得到的实施例也包含在本公开的技术范围内。此外，上述实施例中所描述的具有相同效果的组件可以相互替代。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 一种基于Web的移动瘦终端访问控制方法、系统及瘦终端 | 2020-05-08 | 736 |
| 数据网安全防护方法、装置、计算机设备和存储介质 | 2020-05-11 | 955 |
| 基于负载均衡的智能电力终端的多级管理系统及认证方法 | 2020-05-12 | 638 |
| 用于执行轨道车辆的紧急制动的制动设备和方法 | 2020-05-15 | 65 |
| 一种智能网联交通系统的固定路径服务系统 | 2020-05-11 | 614 |
| 一种高安全可信移动终端安全体系架构及安全服务方法 | 2020-05-11 | 113 |
| 用于防喷器控制的安全性完整性等级(SIL)评级系统 | 2020-05-14 | 621 |
| 泛在电力物联网环境下的用电信息安全传输步骤与方法 | 2020-05-13 | 438 |
| 一种智能照明系统及其安全设计方法 | 2020-05-13 | 974 |
| 一种应用于电力公司的调控智能网络化交互系统 | 2020-05-11 | 179 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
QQ群二维码
意见反馈
意见反馈