CN112020149A - 一种避免pusch和pucch冲突的方法和设备 - Google Patents

Abstract

本申请公开了一种应用于eMTC深度覆盖场景的避免PUSCH和PUCCH冲突的方法，适用于eMTC终端，包括：当eMTC终端进入重复发送模式时，在eMTC终端准备向基站发送调度请求(SR)时，eMTC终端判断对应于所述SR的PUCCH是否会与eMTC终端的PUSCH传输存在冲突；如果对应于所述SR的PUCCH会与eMTC终端的PUSCH传输存在冲突，则eMTC终端推迟发送所述SR；否则，eMTC终端发送所述SR。本申请还公开了一种应用于基站侧的避免PUSCH和PUCCH冲突的方法，及对应的eMTC终端和基站。应用本申请公开的技术方案，能够降低PUSCH和PUCCH冲突概率，提高PUSCH的解调性能。

Description

一种避免PUSCH和PUCCH冲突的方法和设备

技术领域

本申请涉及物联网技术领域，特别涉及一种避免PUSCH和PUCCH冲突的方法和设备。

背景技术

物联网(IoT，Internet of Things)技术是未来信息技术发展的重要组成部分，其主要技术特点是将物品通过通信技术与网络连接，从而实现人机互连、物物互连的智能化网络。

协议3GPP R13针对此类物联网业务的特点，基于LTE进行演进，设计了专门用于物联网的eMTC(Enhanced Machine Type Communications：增强型机器通信)技术。eMTC的特点是：广覆盖(相对于LTE 15dB的覆盖进行了增强)、低成本、低功耗、支持海量连接。

其中，eMTC的广覆盖是通过连续多个子帧重复发送、跳频等技术实现的，适用于需要深度覆盖的行业场景，如地下室、井盖、偏远区域等。

本申请的发明人在实现本申请的过程中发现：

现有的eMTC解决方案中，当同一用户在某一子帧同时存在物理上行控制信道(PUCCH)和物理上行共享信道(PUSCH)数据需要上传时，终端会丢弃PUSCH。在重复发送场景下，PUCCH和PUSCH均会进行重复发送，这样，PUSCH会大概率被丢弃，且PUSCH会被连续丢弃。若某一重复发送的PUSCH数据连续被丢弃过多，则会影响PUSCH的解调性能，最终导致上行链路异常。

发明内容

本申请提供了一种基于eMTC深度覆盖的避免PUSCH和PUCCH冲突的方法和设备，旨在降低PUSCH和PUCCH冲突概率，提高PUSCH的解调性能。

本申请提供了一种避免物理上行共享信道PUSCH和物理上行控制信道PUCCH冲突的方法，应用于增强型机器通信eMTC深度覆盖场景，适用于eMTC终端，包括：

当所述eMTC终端进入重复发送模式时，在所述eMTC终端准备向基站发送调度请求SR时，所述eMTC终端判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突；

如果对应于所述SR的PUCCH会与所述eMTC终端的PUSCH传输存在冲突，则所述eMTC终端推迟发送所述SR；

如果对应于所述SR的PUCCH不会与所述eMTC终端的PUSCH传输存在冲突，则所述eMTC终端发送所述SR。

较佳的，所述eMTC终端判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突，具体包括：

所述eMTC终端判断是否满足条件1和/或条件2：

条件1为：上行子帧{k，k+Pucch_Repeat_Num}范围内，所述eMTC终端有PUSCH需要上传，且该PUSCH为初传；

条件2为：上行子帧{k，k+Pucch_Repeat_Num}范围内，所述eMTC终端有PUSCH需要上传，且该PUSCH为重传；

其中，k为SR起始子帧；

Pucch_Repeat_Num为PUCCH重复次数；

如果满足条件1和/或条件2，则对应于所述SR的PUCCH会与所述eMTC终端的PUSCH传输存在冲突，否则，对应于所述SR的PUCCH不会与所述eMTC终端的PUSCH传输存在冲突。

较佳的，所述eMTC终端推迟发送所述SR，具体包括：

所述eMTC终端启动第一定时器，在所述第一定时器超时之前，所述eMTC终端继续判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突，直至对应于所述SR的PUCCH不会与所述eMTC终端的PUSCH传输存在冲突时，发送所述SR；

其中，所述第一定时器的长度为N*SR发送周期，参数N可配置，配置范围为{1，1024}。

较佳的，该方法还包括：

当所述第一定时器超时时，所述SR还没有成功发送，则在下一个PUCCH可用时域位置发送SR，同时丢弃PUSCH数据。

本申请还提供了一种eMTC终端，应用于eMTC深度覆盖场景，包括：第一判断模块和第一控制模块，其中：

所述第一判断模块，用于在所述eMTC终端处于重复发送模式，且所述eMTC终端准备向基站发送SR时，判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突，并将判断结果通知所述第一控制模块；

所述第一控制模块，用于在对应于所述SR的PUCCH会与所述eMTC终端的PUSCH传输存在冲突时，推迟发送所述SR；并用于在对应于所述SR的PUCCH不会与所述eMTC终端的PUSCH传输存在冲突时，发送所述SR。

本申请还提供了一种避免PUSCH和PUCCH冲突的方法，应用于eMTC深度覆盖场景，适用于基站，包括：

当eMTC终端进入重复发送模式时，在所述基站准备进行上行PUSCH调度时，判断所述PUSCH调度所对应的PUSCH传输是否会与所述eMTC终端的PUCCH传输存在冲突；

如果所述PUSCH调度所对应的PUSCH传输会与所述eMTC终端的PUCCH传输存在冲突，则当前子帧不进行所述上行PUSCH调度；

如果所述PUSCH调度所对应的PUSCH传输不会与所述eMTC终端的PUCCH传输存在冲突，则进行所述上行PUSCH调度。

较佳的，所述判断所述PUSCH调度所对应的PUSCH传输是否会与所述eMTC终端的PUCCH传输存在冲突，具体包括：

判断上行子帧{k，k+Pusch_Repeat_Num}范围内所述eMTC终端是否有PUCCH ACK/NACK需要反馈；

其中，k为PUSCH起始子帧；

Pusch_Repeat_Num为PUSCH重复次数；

如果上行子帧{k，k+Pusch_Repeat_Num}范围内所述eMTC终端有PUCCHACK/NACK需要反馈，则所述PUSCH调度所对应的PUSCH传输会与所述eMTC终端的PUCCH传输存在冲突；

否则，所述PUSCH调度所对应的PUSCH传输不会与所述eMTC终端的PUCCH传输存在冲突。

本申请还提供了一种基站，应用于eMTC深度覆盖场景，包括：第二判断模块和第二控制模块，其中：

所述第二判断模块，用于在eMTC终端处于重复发送模式，且所述基站准备进行上行PUSCH调度时，判断所述PUSCH调度所对应的PUSCH传输是否会与所述eMTC终端的PUCCH传输存在冲突，并将判断结果通知所述第二控制模块；

所述第二控制模块，用于在所述PUSCH调度所对应的PUSCH传输会与所述eMTC终端的PUCCH传输存在冲突时，当前子帧不进行所述上行PUSCH调度；并用于在所述PUSCH调度所对应的PUSCH传输不会与所述eMTC终端的PUCCH传输存在冲突时，进行所述上行PUSCH调度。

由上述技术方案可见，本申请提供的应用于eMTC终端侧的避免PUSCH和PUCCH冲突的方法和eMTC终端，通过在eMTC终端准备向基站发送调度请求SR时，先判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突，并在对应于所述SR的PUCCH会与所述eMTC终端的PUSCH传输存在冲突时，推迟发送所述SR，从而避免了PUSCH和PUCCH冲突，提高了PUSCH的解调性能。

此外，本申请提供的应用于基站侧的避免PUSCH和PUCCH冲突的方法和基站设备，通过在基站准备进行上行PUSCH调度时，先断所述PUSCH调度所对应的PUSCH传输是否会与所述eMTC终端的PUCCH传输存在冲突，并在所述PUSCH调度所对应的PUSCH传输会与所述eMTC终端的PUCCH传输存在冲突时，在当前子帧不进行所述上行PUSCH调度，从而避免了PUSCH和PUCCH冲突，提高了PUSCH的解调性能。

附图说明

图1为本申请应用于eMTC终端侧的避免PUSCH和PUCCH冲突的方法流程示意图；

图2为本申请应用于基站侧的避免PUSCH和PUCCH冲突的方法流程示意图；

图3为本申请一较佳eMTC终端的组成结构示意图；

图4为本申请一较佳基站的组成结构示意图；

图5为本申请实施例一中应用于eMTC终端侧的避免PUSCH和PUCCH冲突的方法流程示意图；

图6为本申请实施例二中应用于基站侧的避免PUSCH和PUCCH冲突的方法流程示意图。

具体实施方式

为使本申请的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本申请作进一步详细说明。

为解决现有技术所存在的问题，本申请提出一种基于eMTC深度覆盖的避免PUSCH和PUCCH冲突的方法，应用于eMTC终端侧，该方法的流程示意图如图1所示，包括以下步骤：

步骤101：当所述eMTC终端进入重复发送模式时，进入步骤102。

步骤102：在所述eMTC终端准备向基站发送调度请求SR时，进入步骤103。

步骤103：所述eMTC终端判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突。

步骤104：如果对应于所述SR的PUCCH会与所述eMTC终端的PUSCH传输存在冲突，则所述eMTC终端推迟发送所述SR。

步骤105：如果对应于所述SR的PUCCH不会与所述eMTC终端的PUSCH传输存在冲突，则所述eMTC终端发送所述SR。

至此，结束图1所示方法流程。

为解决现有技术所存在的问题，本申请还提出一种基于eMTC深度覆盖的避免PUSCH和PUCCH冲突的方法，应用于基站侧，该方法的流程示意图如图2所示，包括以下步骤：

步骤201：当eMTC终端进入重复发送模式时，进入步骤202。

步骤202：在所述基站准备进行上行PUSCH调度时，进入步骤203。

步骤203：所述基站判断所述PUSCH调度所对应的PUSCH传输是否会与所述eMTC终端的PUCCH传输存在冲突。

步骤204：如果所述PUSCH调度所对应的PUSCH传输会与所述eMTC终端的PUCCH传输存在冲突，则当前子帧不进行所述上行PUSCH调度。

步骤205：如果所述PUSCH调度所对应的PUSCH传输不会与所述eMTC终端的PUCCH传输存在冲突，则进行所述上行PUSCH调度。

至此，结束图2所示方法流程。

对应于图1所示方法，本申请还提供了一种对应的eMTC终端，应用于eMTC深度覆盖场景，其组成结构如图3所示，包括：第一判断模块和第一控制模块，其中：

所述第一判断模块，用于在所述eMTC终端处于重复发送模式，且所述eMTC终端准备向基站发送SR时，判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突，并将判断结果通知所述第一控制模块；

所述第一控制模块，用于在对应于所述SR的PUCCH会与所述eMTC终端的PUSCH传输存在冲突时，推迟发送所述SR；并用于在对应于所述SR的PUCCH不会与所述eMTC终端的PUSCH传输存在冲突时，发送所述SR。

对应于图2所示方法，本申请还提供了一种基站设备，应用于eMTC深度覆盖场景，其组成结构如图4所示，包括：第二判断模块和第二控制模块，其中：

所述第二判断模块，用于在eMTC终端处于重复发送模式，且所述基站准备进行上行PUSCH调度时，判断所述PUSCH调度所对应的PUSCH传输是否会与所述eMTC终端的PUCCH传输存在冲突，并将判断结果通知所述第二控制模块；

所述第二控制模块，用于在所述PUSCH调度所对应的PUSCH传输会与所述eMTC终端的PUCCH传输存在冲突时，当前子帧不进行所述上行PUSCH调度；并用于在所述PUSCH调度所对应的PUSCH传输不会与所述eMTC终端的PUCCH传输存在冲突时，进行所述上行PUSCH调度。

下面通过两个较佳实施例，对本申请技术方案进行进一步详细说明。

实施例一：

本实施例对本申请应用于eMTC终端侧的避免PUSCH和PUCCH冲突的方法进行说明。图5为本申请实施例一中应用于eMTC终端侧的避免PUSCH和PUCCH冲突的方法流程示意图，参见图5，该方法包括以下步骤：

步骤501、当eMTC终端进入modeB模式时，执行步骤502，否则，保持现状。

eMTC终端有两种模式：modeA和modeB，其中：

modeA模式是指非重复发送模式，在modeA下，eMTC终端不对PUCCH和PUSCH进行重复发送；

modeB模式是指重复发送模式，在modeB下，eMTC终端对PUCCH和PUSCH进行重复发送。

步骤502、当终端准备向基站发送SR(Scheduling Request：调度请求)时，执行步骤503。

步骤503：判断是否满足条件1和/或条件2：

条件1为：上行子帧{k，k+Pucch_Repeat_Num}范围内，该终端有PUSCH需要上传，且该PUSCH为初传；

条件2为：上行子帧{k，k+Pucch_Repeat_Num}范围内，该终端有PUSCH需要上传，且该PUSCH为重传；

其中，k为SR起始子帧；

Pucch_Repeat_Num为PUCCH重复次数。

本申请在终端向基站发送SR之前进行相关的判断，以防止PUSCH与PUCCH冲突。

步骤504：若满足上述条件，则终端不发送SR，并启动定时器1，若不满足上述条件，则执行步骤506，触发SR在PUCCH资源进行发送。

本步骤中，启动定时器1后，实际上是将SR推迟到了下一个PUCCH可用时域子帧进行发送。

步骤505：在定时器1超时之前，继续转到步骤503进行判断，直至不满足步骤503所述条件时，执行步骤506，触发SR在PUCCH资源进行发送。

步骤507、若定时器1超时后SR还没有成功发送，则不判断PUCCH是否与PUSCH冲突，直接在下一个PUCCH可用时域位置发送SR，同时丢弃PUSCH数据。

其中，定时器1的长度为N*SR发送周期，N可配，配置范围为{1，1024}，默认值64。

至此，结束本实施例方法流程。

实施例二：

本实施例对本申请应用于基站侧的避免PUSCH和PUCCH冲突的方法进行说明。图6为本申请实施例二中应用于基站侧的避免PUSCH和PUCCH冲突的方法流程示意图，参见图6，该方法包括以下步骤：

步骤601：当eMTC终端进入modeB模式后，执行步骤602，否则，保持现状。

步骤602：当基站进行上行调度(即调度PUSCH)时，执行步骤603。

步骤603：判断上行子帧{k，k+Pusch_Repeat_Num}范围内终端是否有PUCCH ACK/NACK需要反馈，其中，k为PUSCH起始子帧，Pusch_Repeat_Num为PUSCH重复次数，若终端有PUCCH ACK/NACK需要反馈，则执行步骤604，否则，执行步骤605。

根据相关时序关系，终端会在基站分配的PUCCH资源上向基站发送ACK/NACK，因此，按照时序关系，基站可以确定终端将在哪个子帧反馈ACK/NACK。

本步骤中，基站通过在进行上行PUSCH调度时，先判断上行子帧{k，k+Pusch_Repeat_Num}范围内终端是否有PUCCH ACK/NACK需要反馈，并在终端有PUCCH ACK/NACK需要反馈时，在当前子帧不进行PUSCH调度，从而避免了PUSCH与PUCCH冲突。

步骤604：当前子帧不进行PUSCH调度，到下一个调度子帧再继续判断。

从而，避免了PUSCH与PUCCH冲突。

步骤605：当前子帧进行PUSCH调度。

至此，结束本实施例方法流程。

由上述技术方案可见，本申请提供的应用于eMTC终端侧的避免PUSCH和PUCCH冲突的方法和eMTC终端，通过在eMTC终端准备向基站发送调度请求SR时，先判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突，并在对应于所述SR的PUCCH会与所述eMTC终端的PUSCH传输存在冲突时，推迟发送所述SR，从而避免了PUSCH和PUCCH冲突，提高了PUSCH的解调性能。

此外，本申请提供的应用于基站侧的避免PUSCH和PUCCH冲突的方法和基站设备，通过在基站准备进行上行PUSCH调度时，先断所述PUSCH调度所对应的PUSCH传输是否会与所述eMTC终端的PUCCH传输存在冲突，并在所述PUSCH调度所对应的PUSCH传输会与所述eMTC终端的PUCCH传输存在冲突时，在当前子帧不进行所述上行PUSCH调度，从而避免了PUSCH和PUCCH冲突，提高了PUSCH的解调性能。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (8)

1.一种避免物理上行共享信道PUSCH和物理上行控制信道PUCCH冲突的方法，应用于增强型机器通信eMTC深度覆盖场景，适用于eMTC终端，其特征在于，包括：

当所述eMTC终端进入重复发送模式时，在所述eMTC终端准备向基站发送调度请求SR时，所述eMTC终端判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突；

如果对应于所述SR的PUCCH会与所述eMTC终端的PUSCH传输存在冲突，则所述eMTC终端推迟发送所述SR；

如果对应于所述SR的PUCCH不会与所述eMTC终端的PUSCH传输存在冲突，则所述eMTC终端发送所述SR。

2.根据权利要求1所述的方法，其特征在于，所述eMTC终端判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突，具体包括：

所述eMTC终端判断是否满足条件1和/或条件2：

条件1为：上行子帧{k，k+Pucch_Repeat_Num}范围内，所述eMTC终端有PUSCH需要上传，且该PUSCH为初传；

条件2为：上行子帧{k，k+Pucch_Repeat_Num}范围内，所述eMTC终端有PUSCH需要上传，且该PUSCH为重传；

其中，k为SR起始子帧；

Pucch_Repeat_Num为PUCCH重复次数；

如果满足条件1和/或条件2，则对应于所述SR的PUCCH会与所述eMTC终端的PUSCH传输存在冲突，否则，对应于所述SR的PUCCH不会与所述eMTC终端的PUSCH传输存在冲突。

3.根据权利要求1或2所述的方法，其特征在于，所述eMTC终端推迟发送所述SR，具体包括：

所述eMTC终端启动第一定时器，在所述第一定时器超时之前，所述eMTC终端继续判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突，直至对应于所述SR的PUCCH不会与所述eMTC终端的PUSCH传输存在冲突时，发送所述SR；

其中，所述第一定时器的长度为N*SR发送周期，参数N可配置，配置范围为{1，1024}。

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

当所述第一定时器超时时，所述SR还没有成功发送，则在下一个PUCCH可用时域位置发送SR，同时丢弃PUSCH数据。

5.一种eMTC终端，应用于eMTC深度覆盖场景，其特征在于，包括：第一判断模块和第一控制模块，其中：

所述第一判断模块，用于在所述eMTC终端处于重复发送模式，且所述eMTC终端准备向基站发送SR时，判断对应于所述SR的PUCCH是否会与所述eMTC终端的PUSCH传输存在冲突，并将判断结果通知所述第一控制模块；

所述第一控制模块，用于在对应于所述SR的PUCCH会与所述eMTC终端的PUSCH传输存在冲突时，推迟发送所述SR；并用于在对应于所述SR的PUCCH不会与所述eMTC终端的PUSCH传输存在冲突时，发送所述SR。

6.一种避免PUSCH和PUCCH冲突的方法，应用于eMTC深度覆盖场景，适用于基站，其特征在于，包括：

当eMTC终端进入重复发送模式时，在所述基站准备进行上行PUSCH调度时，判断所述PUSCH调度所对应的PUSCH传输是否会与所述eMTC终端的PUCCH传输存在冲突；

如果所述PUSCH调度所对应的PUSCH传输会与所述eMTC终端的PUCCH传输存在冲突，则当前子帧不进行所述上行PUSCH调度；

如果所述PUSCH调度所对应的PUSCH传输不会与所述eMTC终端的PUCCH传输存在冲突，则进行所述上行PUSCH调度。

7.根据权利要求6所述的方法，其特征在于，所述判断所述PUSCH调度所对应的PUSCH传输是否会与所述eMTC终端的PUCCH传输存在冲突，具体包括：

判断上行子帧{k，k+Pusch_Repeat_Num}范围内所述eMTC终端是否有PUCCH ACK/NACK需要反馈；

其中，k为PUSCH起始子帧；

Pusch_Repeat_Num为PUSCH重复次数；

如果上行子帧{k，k+Pusch_Repeat_Num}范围内所述eMTC终端有PUCCH ACK/NACK需要反馈，则所述PUSCH调度所对应的PUSCH传输会与所述eMTC终端的PUCCH传输存在冲突；

否则，所述PUSCH调度所对应的PUSCH传输不会与所述eMTC终端的PUCCH传输存在冲突。

8.一种基站，应用于eMTC深度覆盖场景，其特征在于，包括：第二判断模块和第二控制模块，其中：

所述第二判断模块，用于在eMTC终端处于重复发送模式，且所述基站准备进行上行PUSCH调度时，判断所述PUSCH调度所对应的PUSCH传输是否会与所述eMTC终端的PUCCH传输存在冲突，并将判断结果通知所述第二控制模块；

所述第二控制模块，用于在所述PUSCH调度所对应的PUSCH传输会与所述eMTC终端的PUCCH传输存在冲突时，当前子帧不进行所述上行PUSCH调度；并用于在所述PUSCH调度所对应的PUSCH传输不会与所述eMTC终端的PUCCH传输存在冲突时，进行所述上行PUSCH调度。

Images