CN117751561A - 混合自动重传请求harq进程处理方法及装置 - Google Patents

混合自动重传请求harq进程处理方法及装置 Download PDF

Info

Publication number
CN117751561A
CN117751561A CN202280002297.8A CN202280002297A CN117751561A CN 117751561 A CN117751561 A CN 117751561A CN 202280002297 A CN202280002297 A CN 202280002297A CN 117751561 A CN117751561 A CN 117751561A
Authority
CN
China
Prior art keywords
transmission
harq
terminal
retransmission
transport block
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.)
Pending
Application number
CN202280002297.8A
Other languages
English (en)
Inventor
刘晓菲
吴昱民
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.)
Beijing Xiaomi Mobile Software Co Ltd
Original Assignee
Beijing Xiaomi Mobile Software Co Ltd
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 Beijing Xiaomi Mobile Software Co Ltd filed Critical Beijing Xiaomi Mobile Software Co Ltd
Publication of CN117751561A publication Critical patent/CN117751561A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L27/00—Modulated-carrier systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

本公开提出了一种混合自动重传请求HARQ进程处理方法及装置，涉及移动通信技术领域，根据本公开实施例提供了的混合自动重传请求HARQ进程处理方法，其中对于非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程可执行以下至少一项操作：不清空HARQ buffer；根据网络指示确定下次传输块TB传输是初传还是重传。本公开可将保证支持非激活态组播业务接收的终端，能够在MAC重置时不清空HARQ buffer，和/或不直接将下行HARQ进程中下次收到的传输块传输视为初传，以此能够保证数据传输的完整性以及提高译码的准确率，防止丢失有用信息。

Description

混合自动重传请求HARQ进程处理方法及装置 技术领域
本公开涉及移动通信技术领域，特别涉及一种混合自动重传请求HARQ进程处理方法及装置。
背景技术
混合自动重传请求(Hybrid Automatic Repeat Request，HARQ)协议是新空口(New Radio，NR)中最主要的重传方式。当数据包译码错误时，会发送重传请求。尽管无法解析数据包，但接收到的数据包中仍包含有用信息，因此，如果丢弃错误的数据包，会导致有用信息丢失。在相关技术中，将接收到的错误数据包存储在HARQ buffer中，随后与重传的数据包进行合并，得到一个合并的数据包，并对合并的数据包进行纠错解码。由于初传和重传一般采用相同的方式进行调度，终端需要知道这次传输是新传还是重传，因为新传需要清空缓存，而重传需要进行合并，因此下行发送的调度信息中包含了一个显式的新数据指示(New data indicator,NDI)，用于标记该调度的传输块(Transport Block,TB)。NDI本质上是一个1bit的序列号，在新传输块时会翻转，当接收到一个下行调度分配时，终端会检查NDI，判断当前传输是应该与HARQ buffer中的数据包进行合并还是清空HARQ buffer。
在第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)R18标准中研究支持非激活态组播业务接收，当终端在非激活态时，也能够继续执行组播业务数据接收。在相关技术中，当网络侧通过包含挂起配置的RRCRelease将终端释放到非激活态时，需要执行媒体接入控制(Medium Access Control，MAC)重置流程。在MAC重置流程中，会清空HARQ buffer,同时对于每个下行HARQ进程，将下次收到的传输块(Transport Block,TB)传输视为初传。而对于支持非激活态组播业务接收的终端，执行该操作可能会因非激活态组播业务(Multicast Broadcast Service，MBS)相关HARQ进程的初始化，造成数据丢失或译码失败。
发明内容
本公开提供了一种混合自动重传请求HARQ进程处理方法及装置，可避免支持非激活态组播业务接收的终端在MAC重置时因HARQ进程重置而导致数据丢失或译码失败的问题。
本公开的第一方面实施例提供了一种混合自动重传请求HARQ进程处理方法，该方法应用于终端，所述方法包括：
对于非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程执行以下至少一项操作：
不清空HARQ buffer；
根据网络指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，所述不清空HARQ buffer，包括：
不清空所有HARQ buffer。
在本公开的一些实施例中，所述不清空HARQ buffer，包括：
不清空所有传输块TB没有被成功译码的HARQ buffer。
在本公开的一些实施例中，所述不清空HARQ buffer，包括：
不清空所有所述MBS相关的HARQ buffer。
在本公开的一些实施例中，所述不清空HARQ buffer，包括：
不清空所有所述MBS相关的且传输块TB没有被成功译码的HARQ buffer。
在本公开的一些实施例中，所述方法还包括：
接收网络侧发送的网络指示。
在本公开的一些实施例中，所述根据网络指示确定下次传输块TB传输是初传还是重传，包括：
所述网络指示携带于下行控制信息DCI指示，根据所述DCI指示确定下次传输块TB传输是初传还 是重传。
在本公开的一些实施例中，所述根据所述DCI指示确定下次传输块TB传输是初传还是重传，包括：
根据所述DCI指示中的新数据指示NDI确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，所述根据网络指示确定下次传输块TB传输是初传还是重传，包括：
对于所有HARQ进程，根据所述网络指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，所述根据网络指示确定下次传输块TB传输是初传还是重传，包括：
对于所有传输块TB没有被成功译码的HARQ进程，根据所述网络指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，所述根据网络指示确定下次传输块TB传输是初传还是重传，包括：
对于所有所述MBS相关的HARQ进程，根据所述网络指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，所述根据网络指示确定下次传输块TB传输是初传还是重传，包括：
对于所有所述MBS相关的且传输块TB没有被成功译码的HARQ进程，根据所述网络指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，所述方法还包括：
根据组无线网络临时标识G-RNTI解码的物理下行控制信道PDCCH确定所述MBS相关的HARQ进程。
本公开的第二方面实施例提供了一种混合自动重传请求HARQ进程处理方法，所述方法应用于网络侧，所述方法包括：
向终端发送网络指示，所述网络指示用于所述终端确定传输块TB传输是初传还是重传。
在本公开的一些实施例中，所述网络指示携带于下行控制信息DCI指示中。
本公开的第三方面实施例提供了一种混合自动重传请求HARQ进程处理装置，所述装置应用于终端，所述装置包括：
执行模块，用于对于非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程执行以下操作：
不清空HARQ buffer；
根据网络指示确定下次传输块TB传输是初传还是重传。
本公开的第四方面实施例提供了一种混合自动重传请求HARQ进程处理装置，所述装置应用于网络侧，所述装置包括：
发送模块，用于向终端发网络指示，所述网络指示用于所述终端确定传输块TB传输是初传还是重传。
本公开的第五方面实施例提供了一种通信设备，该通信设备包括：收发器；存储器；处理器，分别与收发器及存储器连接，配置为通过执行存储器上的计算机可执行指令，控制收发器的无线信号收发，并能够实现如本公开第一方面实施例或第二方面实施例的方法。
本公开的第六方面实施例提供了一种计算机存储介质，其中，计算机存储介质存储有计算机可执行指令；计算机可执行指令被处理器执行后，能够实现如本公开第一方面实施例或第二方面实施例的方法。
本公开实施例提供了一种混合自动重传请求HARQ进程处理方法及装置，终端可在处于非激活态并继续执行组播业务数据接收时，在媒体接入控制MAC重置过程中，根据协议约定对混合自动重传请求HARQ进程执行以下至少一项操作：不清空HARQ buffer；根据网络指示确定下次传输块TB传输是初传还是重传。通过上述操作，可避免MAC重置过程中对HARQ进程进行完全的初始化，保证支持非激活态组播业务接收的终端，在处于非激活态并继续执行组播业务数据接收时，HARQ buffer中存储的错误数据包不会被清空，也不会直接将下次收到的传输块传输视为初传，能够正常执行译码错误数据包的重传操作，从而能够保证非激活态终端在MAC重置时，组播业务数据传输的完整性以及提高译码的准确率，防止丢失有用信息。
本公开附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本公开的实践了解到。
附图说明
本公开上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图；
图2为根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图；
图3为根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图；
图4为根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图；
图5为根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图；
图6为根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图；
图7为根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图；
图8为根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的时序图；
图9为根据本公开实施例提供的一种混合自动重传请求HARQ进程处理装置的结构示意图；
图10为根据本公开实施例提供的一种混合自动重传请求HARQ进程处理装置的结构示意图；
图11为根据本公开实施例的一种通信装置的结构示意图；
图12为本公开实施例提供的一种芯片的结构示意图。
具体实施方式
下面详细描述本公开的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本公开，而不能理解为对本公开的限制。
混合自动重传请求(Hybrid Automatic Repeat Request，HARQ)协议是新空口(New Radio，NR)中最主要的重传方式。当数据包译码错误时，会发送重传请求。尽管无法解析数据包，但接收到的数据包中仍包含有用信息，因此，如果丢弃错误的数据包，会导致有用信息丢失。相关技术将接收到的错误数据包存储在HARQ buffer中，随后与重传的数据包进行合并，得到一个合并的数据包，并对合并的数据包进行纠错解码。
然而对于释放到非激活态的终端，需要执行媒体接入控制(Medium Access Control，MAC)重置流程，在MAC重置流程中，会清空HARQ buffer,同时对于每个下行HARQ进程，将下次收到的传输块(Transport Block,TB)传输视为初传。故对于支持非激活态组播业务接收的终端，执行该操作可能会因非激活态组播业务(Multicast Broadcast Service，MBS)相关HARQ进程的初始化，数据包译码错误时，不能在清空的HARQ buffer中查取译码错误的数据包，并与重传的数据包进行合并，进而容易导致有用信息丢失或直接导致译码失败。
为此，本公开提出了一种混合自动重传请求HARQ进程处理方法及装置，可避免支持非激活态组播业务接收的终端在MAC重置时因HARQ进程重置而导致数据丢失或译码失败的问题。
下面结合附图对本申请所提供的切换方法及装置进行详细地介绍。
图1示出了根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图。如图1所示，该方法应用于终端，且可以包括以下步骤。
步骤101、对于非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程执行不清空HARQ buffer的操作。
其中，非激活态组播业务(Multicast Broadcast Service，MBS)为非激活态终端仍能执行业务数据接收的组播业务。
当网络侧通过包含挂起配置的RRCRelease将终端释放到非激活态时，需要执行媒体接入控制(Medium Access Control，MAC)重置流程，在MAC重置流程中，会清空HARQ buffer。而终端从非激活态继续执行非激活态组播业务时，需要接收业务数据，对于数据包译码错误的情况，需要将接收到的错误数据包存储在混合自动重传请求(Hybrid Automatic Repeat Request，HARQ)buffer中，随后与重传的数据包进行合并，得到一个合并的数据包，并对合并的数据包进行纠错解码。故为了保证终端针对非激活态组播业务MBS的正常执行，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程执行保持HARQ进程中的HARQ buffer(也就是不清空HARQ buffer)的操作，可保证支持非激活态组播业务接收的终端，能够正常执行译码错误的数据包的重传操作，在不清空的HARQ buffer中查取错误数据包，与重传的数据包进行合并，并对合并的数据包进行纠错解码，从而避免支持非激活态组播业务接收的终端在MAC重置时因清空HARQ buffer而导致数据丢失或译码失败的问题。
其中，HARQ buffer可以是以下至少一项：
所有HARQ buffer；
所有传输块(Transport Block,TB)没有被成功译码的HARQ buffer；
所有MBS相关的HARQ buffer；
所有MBS相关的且TB没有被成功译码的HARQ buffer。
在本公开实施例中，作为一种可能的实现方式：对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有HARQ buffer；
作为一种可能实现方式：对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有TB没有被成功译码的HARQ buffer；
作为一种可能实现方式：对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的HARQ buffer；
作为一种可能实现方式：对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的且TB没有被成功译码的HARQ buffer。
需要说明的是，以上实施例中，MBS相关的HARQ buffer关联MBS相关的HARQ进程，可以根据G-RNTI解码的物理下行控制信道(Physical Downlink Control Channel，PDCCH)确定。
综上，根据本公开实施例提供的混合自动重传请求HARQ进程处理方法，可避免MAC重置过程中，对HARQ进程进行完全的初始化，保证支持非激活态组播业务接收的终端，在处于非激活态并继续执行组播业务数据接收时，相关HARQ buffer中存储的错误数据包不会被清空，能够正常执行译码错误数据包的重传操作，从而能够保证非激活态终端在MAC重置时，组播业务数据传输的完整性以及提高译码的准确率，防止丢失有用信息。
图2示出了根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图。如图2所示，该方法应用于终端，且可以包括以下步骤。
步骤201、对于非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程，执行根据网络指示确定下次传输块TB传输的类型。
在一种实现方式中，下次传输块TB的类型可以是初传传输。在一种实现方式中，下次传输块TB的类型可以重传传输。也就是说，可以是默认下次传输块TB的类型为初传传输，除非网络设备明确指示下次传输块TB的类型为重传传输；当然，可以相反，即默认下次传输块TB的类型为重传传输，除非网络设备明确指示下次传输块TB的类型为初传传输。还可以是，必须由网络侧设备来指示下次传输块TB的类型是初传传输还是重传传输。
当网络侧通过包含挂起配置的RRCRelease将终端释放到非激活态时，需要执行媒体接入控制(Medium Access Control，MAC)重置流程，在MAC重置流程中，对于每个下行HARQ进程，会将下次收到的传输块(Transport Block,TB)传输视为初传。而终端从非激活态继续执行非激活态组播业务时，需要接收业务数据，对于数据包译码错误的情况，会发送重传请求，将重传的数据包与译码错误数据包进行合并，得到一个合并的数据包，并对合并的数据包进行纠错解码。故为了保证终端针对非激活态组播业务(Multicast Broadcast Service，MBS)的正常执行，在媒体接入控制MAC重置过程中，终端可根据协议约定对混合自动重传请求HARQ进程，执行根据网络指示确定下次传输块TB传输是初传还是重传的操作，避免将所有TB传输直接视为初传，而忽略重传这一过程。以使终端能够获取重传的数据包，进而与译码错误的数据包进行合并以及进行纠错解码。
在本公开实施例中，在执行本实施例步骤之前，可接收到网络侧发送的网络指示。其中，网络侧可包括基站、核心网中的至少一种；作为一种可能的实现方式，网络指示可携带于下行控制信息(Downlink Control Information，DCI)中，例如，所述网络指示可为DCI指示中1bit的新数据指示(new data indicator，NDI)。对于本公开实施例，当接收到一个下行调度分配，终端根据网络指示确定下次传输块TB传输是初传还是重传的操作时，可根据DCI指示中的新数据指示NDI确定下次传输块TB传输是初传还是重传。NDI取值为0或1，用于在HARQ传输新数据时，通过将本次传输的NDI设置为与前次不同的值(0变为1，或1变为0)来指示本次传输是初传的数据；相反地，如果NDI保持不变，则表示本次传输的数据与前次相同，即为重传数据。网络侧通过发送用于指示下次传输块TB传输是初传还是重传的NDI，终端通过检查NDI，判断下次传输块中的传输数据包是否应该与HARQ buffer中的数据包进行合并。具体的，当NDI指示下次传输块中的传输数据包为重传时，终端将下次传输块中的传输数据包与对应HARQ buffer中的数据包进行合并；当NDI指示下次传输块中的传输数据包为初传时，终端若判断传输数据包译码错误，则需要将译码错误的传输数据包存储在HARQ buffer中，以便后续与重传的数据包进行合并，并对合并的数据包进行纠错解码，以防止有用信息丢失。
在本公开实施例中，作为一种可能的实现方式：终端可根据协议约定，在MAC重置过程中，对于所有HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
作为一种可能的实现方式：终端可根据协议约定，在MAC重置过程中，对于所有传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
作为一种可能的实现方式：终端可根据协议约定，在MAC重置过程中，对于所有MBS相关的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
作为一种可能的实现方式：终端可根据协议约定，在MAC重置过程中，对于所有MBS相关的且传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
需要说明的是，以上实施例中，MBS相关的HARQ buffer关联MBS相关的HARQ进程，可以根据G-RNTI解码的物理下行控制信道(Physical Downlink Control Channel，PDCCH)确定。
综上，根据本公开实施例提供的混合自动重传请求HARQ进程处理方法，可使支持非激活态组播业务接收的终端，能够根据网络侧发送的网络指示确定下次传输块TB传输是初传还是重传，从而能够保证非激活态终端在MAC重置时，组播业务数据传输的完整性以及提高译码的准确率，防止丢失有用信息。
图3示出了根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图。如图3所示，该方法应用于终端，基于图1、图2所示实施例，如图3所示，且可以包括以下步骤。
301、对于非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程执行不清空HARQ buffer，并且根据网络指示确定下次传输块TB的类型。
在一种实现方式中，下次传输块TB的类型可以是初传传输。在一种实现方式中，下次传输块TB的类型可以重传传输。也就是说，可以是默认下次传输块TB的类型为初传传输，除非网络设备明确指示下次传输块TB的类型为重传传输；当然，可以相反，即默认下次传输块TB的类型为重传传输，除非网络设备明确指示下次传输块TB的类型为初传传输。还可以是，必须由网络侧设备来指示下次传输块TB的类型是初传传输还是重传传输。
当网络侧通过包含挂起配置的RRCRelease将终端释放到非激活态时，需要执行媒体接入控制(Medium Access Control，MAC)重置流程，在MAC重置流程中，会清空HARQ buffer，同时对于每个下行HARQ进程，将下次收到的TB传输视为初传。而终端从非激活态继续执行非激活态组播业务时，需要接收业务数据，对于数据包译码错误的情况，需要将接收到的错误数据包存储在混合自动重传请求(Hybrid Automatic Repeat Request，HARQ)buffer中，随后与重传的数据包进行合并，得到一个合并的数据包，并对合并的数据包进行纠错解码。故为了保证终端针对非激活态组播业务(Multicast Broadcast Service，MBS)的正常执行，在媒体接入控制MAC重置过程中，终端可根据协议约定对混合自动重传请求HARQ进程执行保持HARQ进程中的HARQ buffer(也就是不清空HARQ buffer)，以及根据网络指示确定下次传输块TB传输是初传还是重传的操作。使支持非激活态组播业务接收的终端，能够避免将所有TB传输直接视为初传，而忽略重传这一过程，从而能够支持在重传过程中从不清空的HARQ buffer中查取错误数据包，正常执行译码错误的数据包的重传操作。通过本公开实施例，能够从一定程度上保证数据传输的完整性以及提高译码的准确率，避免有用信息丢失或译码失败的问题。
在本公开实施例中，作为一种可能的实现方式：对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有HARQ buffer，并且对于所有HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
在本公开实施例中，作为一种可能的实现方式：对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有TB没有被成功译码的HARQ buffer，并且对于所有传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
在本公开实施例中，作为一种可能的实现方式：对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的HARQ buffer，并且对于所有MBS相关的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
在本公开实施例中，作为一种可能的实现方式：对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的且TB没有被成功译码的HARQ buffe，并且对于所有MBS相关的且传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
需要说明的是，以上实施例中，MBS相关的HARQ buffer关联MBS相关的HARQ进程，可以根据G-RNTI解码的物理下行控制信道(Physical Downlink Control Channel，PDCCH)确定。
综上，根据本公开实施例提供的混合自动重传请求HARQ进程处理方法，可保证支持非激活态组播业务接收的终端，能够不清空HARQ buffer，并且根据网络侧发送的网络指示确定下次传输块TB传输是初传还是重传，从而能够保证非激活态终端在MAC重置时，组播业务数据传输的完整性以及提高译码 的准确率，防止丢失有用信息。
图4示出了根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图。如图1所示，该方法应用于终端，基于图1所示实施例，如图4所示，且可以包括以下步骤。
401、接收网络侧发送的非激活态组播业务MBS。
其中，网络侧可包括基站、核心网中的至少一种；终端可为非激活态终端；非激活态组播业务(Multicast Broadcast Service，MBS)为非激活态终端仍能执行业务数据接收的组播业务。网络侧可通过向非激活态终端发送非激活态组播业务MBS，以便非激活态终端在接收到MBS后，在响应执行MBS过程中，执行对混合自动重传请求(Hybrid Automatic Repeat Request，HARQ)进程的处理，防止MAC重置过程对HARQ进程进行完全的初始化，使在执行MBS过程中，防止发生数据丢失，确保数据传输的完整性，且能够提高译码准确率。
402、响应于执行非激活态组播业务MBS，在媒体接入控制MAC重置过程中，保持混合自动重传请求HARQ进程中的HARQ buffer。
在相关技术中，当网络侧通过包含挂起配置的RRCRelease将终端释放到非激活态时，需要执行媒体接入控制(Medium Access Control，MAC)重置流程。在MAC重置流程中，会清空HARQ buffer。而非激活态终端执行业务数据接收的组播业务时，译码错误的数据包会被存储在HARQ buffer中，以防止丢失有用信息。当HARQ buffer被清空，HARQ buffer中存储的数据包也会随之删除，进而无法实现与重传数据包的合并，可能会造成译码失败或有用数据丢失。
基于此，在本公开实施例中，在MAC重置过程中，处于非激活态的终端通过不完全执行非激活态组播业务相关HARQ进程的初始化，根据协议约定对混合自动重传请求HARQ进程执行不清空HARQ buffer的操作，可保证支持非激活态组播业务接收的终端，能够正常进行组播业务数据的接收，从而避免出现在MAC重置时因清空HARQ buffer而导致数据丢失或译码失败的问题。
在本公开实施例中，在不清空HARQ buffer时，可根据实际应用需要执行以下至少一项操作，从而保证非激活态组播业务MBS不受到MAC重置的影响，确保错误译码数据的信息完整性以及提高译码的成功率和准确率：
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有HARQ buffer；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有TB没有被成功译码的HARQ buffer；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的HARQ buffer；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的且TB没有被成功译码的HARQ buffer。
对于非激活态组播业务，终端通过不清空HARQ进程中的HARQ buffer，使非激活态组播业务MBS不受到MAC重置的影响，还可以包括上述公开操作外的其他可实现操作，或是前述操作与其他操作的组合，本公开实施例并不对此做出限定。
综上，根据本公开实施例提供的混合自动重传请求HARQ进程处理方法，可避免MAC重置过程中，对HARQ进程进行完全的初始化，保证支持非激活态组播业务接收的终端，在处于非激活态并继续执行 组播业务数据接收时，相关HARQ buffer中存储的错误数据包不会被清空，能够正常执行译码错误数据包的重传操作，从而避免支持非激活态组播业务接收的终端在MAC重置时因清空HARQ buffer而导致数据丢失或译码失败的问题，进一步提高译码的准确率。
图5示出了根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图。如图1所示，该方法应用于终端，基于图2所示实施例，如图5所示，且可以包括以下步骤。
501、响应于执行非激活态组播业务MBS，在媒体接入控制MAC重置过程中，接收网络侧发送的网络指示。
其中，作为一种可能的实现方式，网络指示可携带于下行控制信息(Downlink Control Information，DCI)中，，例如，所述网络指示可为DCI指示中1bit的新数据指示(new data indicator，NDI)。对于本公开实施例，响应于执行非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端可接收网络侧发送的网络指示，以基于网络指示确定下次传输块TB传输是初传还是重传，并执行后续的操作。网络指示对应的新数据指示NDI取值为0或1，用于在HARQ传输新数据时，将本次传输的NDI设置为与前次不同的值(0变为1，或1变为0)来指示本次传输是初传的数据；相反地，如果NDI保持不变，则表示本次传输的数据与前次相同，即为重传数据。
502、根据网络指示确定下次传输块TB的传输类型。
在一种实现方式中，下次传输块TB的类型可以是初传传输。在一种实现方式中，下次传输块TB的类型可以重传传输。也就是说，可以是默认下次传输块TB的类型为初传传输，除非网络设备明确指示下次传输块TB的类型为重传传输；当然，可以相反，即默认下次传输块TB的类型为重传传输，除非网络设备明确指示下次传输块TB的类型为初传传输。还可以是，必须由网络侧设备来指示下次传输块TB的类型是初传传输还是重传传输。
在相关技术中，当网络侧通过包含挂起配置的RRCRelease将终端释放到非激活态时，需要执行媒体接入控制(Medium Access Control，MAC)重置流程。在MAC重置流程中，对于每个下行HARQ进程，会直接将下次收到的传输块传输视为初传。而非激活态终端执行业务数据接收的组播业务时，可能会发生数据重传操作，即下次收到的传输块可为重传数据块，重传数据块的作用在于将重传的数据包与译码错误数据包进行合并，以使终端对合并的数据包进行纠错解码，获取完整的数据信息。然而，若直接将下次收到的传输块传输视为初传，则有可能将重传数据块错误认定为初传数据块，无法实现后续的数据块合并过程，可能会造成有用数据的丢失，甚至造成译码失败。
基于此，在本公开实施例中，在MAC重置过程中，处于非激活态的终端通过不完全执行非激活态组播业务相关HARQ进程的初始化，对于每个下行HARQ进程，不直接将下次收到的传输块传输视为初传，而是根据协议约定对混合自动重传请求HARQ进程执行根据网络侧的网络指示确定下次传输块TB传输是初传还是重传的操作，可保证支持非激活态组播业务接收的终端，能够正常进行组播业务数据的接收，从而能够从一定程度上保证数据传输的完整性以及提高译码的准确率，避免有用信息的丢失。
相应的，终端可通过检查网络侧发送的NDI，以确定下次传输块TB传输是初传还是重传。若传输的NDI值发生变化(0变为1，或1变为0)，则确定下次传输块TB传输是初传；若传输的NDI值未发生变化，则确定下次传输块TB传输是重传。进一步的，当NDI指示下次传输块中的传输数据包为重传时，终端会将下次传输块中的传输数据包与对应HARQ buffer中的数据包进行合并；当NDI指示下次传输块中的传输数据包为初传时，终端若判断传输数据包译码错误，则需要将译码错误的传输数据包存储在HARQ buffer中，以便后续与重传的数据包进行合并，并对合并的数据包进行纠错解码，以防止有用信息丢失。
在本公开实施例中，在根据网络指示确定下次传输块TB传输是初传还是重传时，可根据实际应用需要执行以下至少一项操作，从而保证非激活态组播业务MBS不受到MAC重置的影响，确保错误译码数据的信息完整性以及提高译码的成功率和准确率：
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，对于所有HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，对于所有传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，对于所有MBS相关的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，对于所有MBS相关的且传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
需要说明的是，本领域内技术人员可以理解，对于非激活态组播业务，终端通过根据网络指示确定下次传输块TB传输是初传还是重传，使非激活态组播业务MBS不受到MAC重置的影响，还可以包括上述公开操作外的其他可实现操作，或是前述操作与其他操作的组合，本公开实施例并不对此做出限定。
综上，根据本公开实施例提供的混合自动重传请求HARQ进程处理方法，可保证支持非激活态组播业务接收的终端，能够根据网络侧发送的网络指示确定下次传输块TB传输是初传还是重传，从而能够保证非激活态终端在MAC重置时，组播业务数据传输的完整性以及提高译码的准确率，防止丢失有用信息。
图6示出了根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图。如图1所示，该方法应用于终端，基于图1、图2所示实施例，如图6所示，且可以包括以下步骤。
601、响应于执行非激活态组播业务，在媒体接入控制MAC重置过程中，保持混合自动重传请求HARQ进程中的HARQ buffer，并且根据网络指示确定下次传输块TB的传输类型。
在一种实现方式中，下次传输块TB的类型可以是初传传输。在一种实现方式中，下次传输块TB的类型可以重传传输。也就是说，可以是默认下次传输块TB的类型为初传传输，除非网络设备明确指示下次传输块TB的类型为重传传输；当然，可以相反，即默认下次传输块TB的类型为重传传输，除非网络设备明确指示下次传输块TB的类型为初传传输。还可以是，必须由网络侧设备来指示下次传输块TB的类型是初传传输还是重传传输。
在相关技术中，当网络侧通过包含挂起配置的RRCRelease将终端释放到非激活态时，需要执行媒体接入控制(Medium Access Control，MAC)重置流程。在MAC重置流程中，会清空HARQ buffer，并且对于每个下行HARQ进程，会直接将下次收到的传输块传输视为初传。而非激活态终端执行业务数据接收的组播业务时，译码错误的数据包会被存储在HARQ buffer中，以防止丢失有用信息。当HARQ buffer被清空，HARQ buffer中存储的数据包也会随之删除，进而无法实现与重传数据包的合并，可能会造成译码失败或有用数据丢失。相应的，在下行HARQ进程中，直接将下次收到的传输块传输视为初传，有可能将重传数据块错误认定为初传数据块，无法实现后续的重传数据块合并过程，不能进行对合并数据包的纠错解码，同样会造成有用数据的丢失，甚至造成译码失败。
基于此，在本公开实施例中，作为一种优选方式，在MAC重置过程中，处于非激活态的终端通过不完全执行非激活态组播业务相关HARQ进程的初始化，而是根据协议约定对混合自动重传请求HARQ进程 执行保持HARQ进程中的HARQ buffer(也就是不清空混合自动重传请求HARQ进程中的HARQ buffer)，并且根据网络指示确定下次传输块TB传输是初传还是重传的操作，可保证支持非激活态组播业务接收的终端，能够正常进行组播业务数据的接收，从而避免出现在MAC重置时因清空HARQ buffer而导致数据丢失或译码失败的问题。
在本公开实施例中，在不清空HARQ进程中的HARQ buffer，并且根据网络指示确定下次传输块TB传输是初传还是重传时，可根据实际应用需要执行以下至少一项操作，从而保证非激活态组播业务MBS不受到MAC重置的影响，确保错误译码数据的信息完整性以及提高译码的成功率和准确率：
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有HARQ buffer，并且对于所有HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有TB没有被成功译码的HARQ buffer，并且对于所有传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的HARQ buffer，并且对于所有MBS相关的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的且TB没有被成功译码的HARQ buffe，并且对于所有MBS相关的且传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
其中，以上实施例中，MBS相关的HARQ buffer关联MBS相关的HARQ进程，可以根据G-RNTI解码的物理下行控制信道(Physical Downlink Control Channel，PDCCH)确定。
需要说明的是，本领域内技术人员可以理解，对于非激活态组播业务，终端通过不清空HARQ进程中的HARQ buffer，并且根据网络指示确定下次传输块TB传输是初传还是重传，使非激活态组播业务MBS不受到MAC重置的影响，还可以包括上述公开操作外的其他可实现操作，或是前述操作与其他操作的组合，本公开实施例并不对此做出限定。
综上，根据本公开实施例提供的混合自动重传请求HARQ进程处理方法，可保证支持非激活态组播业务接收的终端，能够不清空HARQ buffer，并且根据网络侧发送的网络指示确定下次传输块TB传输是初传还是重传，从而能够保证非激活态终端在MAC重置时，组播业务数据传输的完整性以及提高译码的准确率，防止丢失有用信息。
图7示出了根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的流程示意图。如图7所示，该方法应用于网络侧，且可以包括以下步骤。
701、向终端发送网络指示，网络指示用于终端确定传输块TB的类型。
在一种实现方式中，下次传输块TB的类型可以是初传传输。在一种实现方式中，下次传输块TB的类型可以重传传输。也就是说，可以是默认下次传输块TB的类型为初传传输，除非网络设备明确指示下次传输块TB的类型为重传传输；当然，可以相反，即默认下次传输块TB的类型为重传传输，除非网络设备明确指示下次传输块TB的类型为初传传输。还可以是，必须由网络侧设备来指示下次传输块TB的类型是初传传输还是重传传输。
其中，网络侧可包括基站、核心网中的至少一种；网络指示携带于下行控制信息DCI指示中，具体可为DCI指示中1bit的新数据指示(new data indicator，NDI)。对于本公开实施例，网络侧可先向 终端发送非激活态组播业务MBS，在终端响应于执行非激活态组播业务MBS时，向终端发送用于确定传输块TB传输是初传还是重传的网络指示，以使终端基于网络指示确定传输块TB是初传传输块还是重传传输块，并执行后续的处理。
综上，根据本公开实施例提供的混合自动重传请求HARQ进程处理方法，可向终端发送网络指示，以使终端根据网络指示确定传输块TB传输是初传还是重传，进一步使支持非激活态组播业务接收的终端，能够根据网络侧发送的网络指示确定下次传输块TB传输是初传还是重传，以此避免出现支持非激活态组播业务接收的终端在MAC重置时因HARQ进程重置而导致数据丢失或译码失败的问题。
图8为根据本公开实施例的一种混合自动重传请求HARQ进程处理方法的时序图。该方法应用于一种混合自动重传请求HARQ进程处理系统，该系统包括：终端UE、网络侧，网络侧向终端UE发送网络指示；对于非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程执行以下至少一项操作：不清空HARQ buffer；根据网络指示确定下次传输块TB传输是初传还是重传。
参见图8，该方法包括如下步骤。
801、网络侧向终端发送终端发送非激活态组播业务。
802、网络侧向终端发送网络指示。
其中，网络侧可包括基站、核心网中的至少一种；网络指示携带于下行控制信息DCI指示中，具体可为DCI指示中1bit的新数据指示(new data indicator，NDI)。
终端响应于执行非激活态组播业务，在媒体接入控制MAC重置过程中，执行803至805中的任意一项：
其中，终端为支持非激活态组播业务接收的终端，非激活态组播业务为非激活态终端仍能执行业务数据接收的组播业务。
803、保持混合自动重传请求HARQ进程中的HARQ buffer。
其中，保持HARQ进程中的HARQ buffer(也就是不清空混合自动重传请求HARQ进程中的HARQ buffer)，可包括以下至少一项操作：
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有HARQ buffer；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有TB没有被成功译码的HARQ buffer；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的HARQ buffer；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的且TB没有被成功译码的HARQ buffer。
804、根据网络指示确定下次传输块TB的传输类型。
在一种实现方式中，下次传输块TB的类型可以是初传传输。在一种实现方式中，下次传输块TB的类型可以重传传输。也就是说，可以是默认下次传输块TB的类型为初传传输，除非网络设备明确指示下次传输块TB的类型为重传传输；当然，可以相反，即默认下次传输块TB的类型为重传传输，除非 网络设备明确指示下次传输块TB的类型为初传传输。还可以是，必须由网络侧设备来指示下次传输块TB的类型是初传传输还是重传传输。
其中，根据网络指示确定下次传输块TB传输是初传还是重传，可包括以下至少一项操作：
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，对于所有HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，对于所有传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，对于所有MBS相关的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，对于所有MBS相关的且传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
805、保持混合自动重传请求HARQ进程中的HARQ buffer，并且根据网络指示确定下次传输块TB的传输类型。
其中，不清空混合自动重传请求HARQ进程中的HARQ buffer，并且根据网络指示确定下次传输块TB传输是初传还是重传，可包括以下至少一项操作：
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有HARQ buffer，并且对于所有HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有TB没有被成功译码的HARQ buffer，并且对于所有传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不清空所有MBS相关的HARQ buffer，并且对于所有MBS相关的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传；
对于非激活态组播业务，终端可根据协议约定，在MAC重置过程中，不不清空所有MBS相关的且TB没有被成功译码的HARQ buffe，并且对于所有MBS相关的且传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
通过应用本实施例提供的混合自动重传请求HARQ进程处理方法，终端可在处于非激活态并继续执行组播业务数据接收时，在媒体接入控制MAC重置过程中，根据协议约定对混合自动重传请求HARQ进程执行以下至少一项操作：不清空HARQ buffer；根据网络指示确定下次传输块TB传输是初传还是重传。通过上述操作，可避免MAC重置过程中，对HARQ进程进行完全的初始化，保证支持非激活态组播业务接收的终端，在处于非激活态并继续执行组播业务数据接收时，HARQ buffer中存储的错误数据包不会被清空，并且根据网络侧发送的网络指示确定下次传输块TB传输是初传还是重传。进而能够正常执行译码错误数据包的重传操作，从而能够保证非激活态终端在MAC重置时，组播业务数据传输的完整性以及提高译码的准确率，防止丢失有用信息。
上述本申请提供的实施例中，分别从终端、网络侧的角度对本申请实施例提供的方法进行了介绍。为了实现上述本申请实施例提供的方法中的各功能，终端、网络侧可以包括硬件结构、软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能可以以硬件结构、软件模块、或者硬件结构加软件模块的方式来执行。
图9为根据本公开实施例提供的一种混合自动重传请求HARQ进程处理装置900的结构示意图，该混合自动重传请求HARQ进程处理装置900可用于终端。
如图9所示，该装置900可包括：
执行模块910，可以用于对于非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程执行以下操作：
不清空HARQ buffer；
根据网络指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，不清空HARQ buffer，包括：不清空所有HARQ buffer。
在本公开的一些实施例中，不清空HARQ buffer，包括：不清空所有传输块TB没有被成功译码的HARQ buffer。
在本公开的一些实施例中，不清空HARQ buffer，包括：不清空所有MBS相关的HARQ buffer。
在本公开的一些实施例中，不清空HARQ buffer，包括：不清空所有MBS相关的且传输块TB没有被成功译码的HARQ buffer。
在本公开的一些实施例中，如图9所示，该装置900还包括：接收模块920；
接收模块920，可以用于接收网络侧发送的网络指示。
在本公开的一些实施例中，根据网络指示确定下次传输块TB传输是初传还是重传，包括：
网络指示携带于下行控制信息DCI指示，根据DCI指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，根据DCI指示确定下次传输块TB传输是初传还是重传，包括：
根据DCI指示中的新数据指示NDI确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，根据网络指示确定下次传输块TB传输是初传还是重传，包括：
对于所有HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，根据网络指示确定下次传输块TB传输是初传还是重传，包括：
对于所有传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，根据网络指示确定下次传输块TB传输是初传还是重传，包括：
对于所有MBS相关的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，根据网络指示确定下次传输块TB传输是初传还是重传，包括：
对于所有MBS相关的且传输块TB没有被成功译码的HARQ进程，根据网络指示确定下次传输块TB传输是初传还是重传。
在本公开的一些实施例中，如图9所示，该装置900还包括：确定模块930；
确定模块930，可以用于根据组无线网络临时标识G-RNTI解码的物理下行控制信道PDCCH确定MBS相关的HARQ进程。
图10为本公开实施例提供的一种混合自动重传请求HARQ进程处理装置1000的结构示意图。该混合自动重传请求HARQ进程处理装置1000可用于网络侧。
如图10所示，该装置1000可包括：
发送模块1010，可以用于向终端发送网络指示，网络指示用于终端确定传输块TB传输是初传还是重传。
在本公开的一些实施例中，网络指示携带于下行控制信息DCI指示中。
请参见图11，图11是本申请实施例提供的一种通信装置1100的结构示意图。通信装置1100可以是网络设备，也可以是用户设备，也可以是支持网络设备实现上述方法的芯片、芯片系统、或处理器等，还可以是支持用户设备实现上述方法的芯片、芯片系统、或处理器等。该装置可用于实现上述方法实施例中描述的方法，具体可以参见上述方法实施例中的说明。
通信装置1100可以包括一个或多个处理器1101。处理器1101可以是通用处理器或者专用处理器等。例如可以是基带处理器或中央处理器。基带处理器可以用于对通信协议以及通信数据进行处理，中央处理器可以用于对通信装置(如，基站、基带芯片，终端设备、终端设备芯片，DU或CU等)进行控制，执行计算机程序，处理计算机程序的数据。
可选的，通信装置1100中还可以包括一个或多个存储器1102，其上可以存有计算机程序1104，处理器1101执行计算机程序1104，以使得通信装置1100执行上述方法实施例中描述的方法。可选的，存储器1102中还可以存储有数据。通信装置1100和存储器1102可以单独设置，也可以集成在一起。
可选的，通信装置1100还可以包括收发器1105、天线1106。收发器1105可以称为收发单元、收发机、或收发电路等，用于实现收发功能。收发器1105可以包括接收器和发送器，接收器可以称为接收机或接收电路等，用于实现接收功能；发送器可以称为发送机或发送电路等，用于实现发送功能。
可选的，通信装置1100中还可以包括一个或多个接口电路1107。接口电路1107用于接收代码指令并传输至处理器1101。处理器1101运行代码指令以使通信装置1100执行上述方法实施例中描述的方法。
在一种实现方式中，处理器1101中可以包括用于实现接收和发送功能的收发器。例如该收发器可以是收发电路，或者是接口，或者是接口电路。用于实现接收和发送功能的收发电路、接口或接口电路可以是分开的，也可以集成在一起。上述收发电路、接口或接口电路可以用于代码/数据的读写，或者，上述收发电路、接口或接口电路可以用于信号的传输或传递。
在一种实现方式中，处理器1101可以存有计算机程序1103，计算机程序1103在处理器1101上运行，可使得通信装置1100执行上述方法实施例中描述的方法。计算机程序1103可能固化在处理器1101中，该种情况下，处理器1101可能由硬件实现。
在一种实现方式中，通信装置1100可以包括电路，该电路可以实现前述方法实施例中发送或接收或者通信的功能。本申请中描述的处理器和收发器可实现在集成电路(integrated circuit，IC)、模拟IC、射频集成电路RFIC、混合信号IC、专用集成电路(application specific integrated circuit，ASIC)、印刷电路板(printed circuit board，PCB)、电子设备等上。该处理器和收发器也可以用各种IC工艺技术来制造，例如互补金属氧化物半导体(complementary metal oxide semiconductor，CMOS)、N型金属氧化物半导体(nMetal-oxide-semiconductor，NMOS)、P型金属氧化物半导体(positive channel metal oxide semiconductor，PMOS)、双极结型晶体管(bipolar junction transistor，BJT)、双极CMOS(BiCMOS)、硅锗(SiGe)、砷化镓(GaAs)等。
以上实施例描述中的通信装置可以是网络设备或者用户设备，但本申请中描述的通信装置的范围并不限于此，而且通信装置的结构可以不受图11的限制。通信装置可以是独立的设备或者可以是较大设备的一部分。例如该通信装置可以是：
(1)独立的集成电路IC，或芯片，或，芯片系统或子系统；
(2)具有一个或多个IC的集合，可选的，该IC集合也可以包括用于存储数据，计算机程序的存储部件；
(3)ASIC，例如调制解调器(Modem)；
(4)可嵌入在其他设备内的模块；
(5)接收机、终端设备、智能终端设备、蜂窝电话、无线设备、手持机、移动单元、车载设备、网络设备、云设备、人工智能设备等等；
(6)其他等等。
对于通信装置可以是芯片或芯片系统的情况，可参见图12所示的芯片的结构示意图。图12所示的芯片包括处理器1201和接口1202。其中，处理器1201的数量可以是一个或多个，接口1202的数量可以是多个。
可选的，芯片还包括存储器1203，存储器1203用于存储必要的计算机程序和数据。
本领域技术人员还可以了解到本申请实施例列出的各种说明性逻辑块(illustrative logical block)和步骤(step)可以通过电子硬件、电脑软件，或两者的结合进行实现。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现的功能，但这种实现不应被理解为超出本申请实施例保护的范围。
本申请还提供一种可读存储介质，其上存储有指令，该指令被计算机执行时实现上述任一方法实施例的功能。
本申请还提供一种计算机程序产品，该计算机程序产品被计算机执行时实现上述任一方法实施例的功能。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机程序。在计算机上加载和执行计算机程序时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机程序可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机程序可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
本领域普通技术人员可以理解：本申请中涉及的第一、第二等各种数字编号仅为描述方便进行的区分，并不用来限制本申请实施例的范围，也表示先后顺序。
本申请中的至少一个还可以描述为一个或多个，多个可以是两个、三个、四个或者更多个，本申请不做限制。在本申请实施例中，对于一种技术特征，通过“第一”、“第二”、“第三”、“A”、“B”、“C”和“D”等区分该种技术特征中的技术特征，该“第一”、“第二”、“第三”、“A”、“B”、“C”和“D”描述的技术特征间无先后顺序或者大小顺序。
如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。
应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
此外，应该理解，本申请的各种实施例可以单独实施，也可以在方案允许的情况下与其他实施例组合实施。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (19)

  1. 一种混合自动重传请求HARQ进程处理方法，其特征在于，所述方法应用于终端，所述方法包括：
    对于非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程执行以下至少一项操作：
    不清空HARQ buffer；
    根据网络指示确定下次传输块TB传输是初传还是重传。
  2. 根据权利要求1所述的方法，其特征在于，所述不清空HARQ buffer，包括：
    不清空所有HARQ buffer。
  3. 根据权利要求1所述的方法，其特征在于，所述不清空HARQ buffer，包括：
    不清空所有传输块TB没有被成功译码的HARQ buffer。
  4. 根据权利要求1所述的方法，其特征在于，所述不清空HARQ buffer，包括：
    不清空所有所述MBS相关的HARQ buffer。
  5. 根据权利要求1所述的方法，其特征在于，所述不清空HARQ buffer，包括：
    不清空所有所述MBS相关的且传输块TB没有被成功译码的HARQ buffer。
  6. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    接收网络侧发送的网络指示。
  7. 根据权利要求1所述的方法，其特征在于，所述根据网络指示确定下次传输块TB传输是初传还是重传，包括：
    所述网络指示携带于下行控制信息DCI指示，根据所述DCI指示确定下次传输块TB传输是初传还是重传。
  8. 根据权利要求7所述的方法，其特征在于，所述根据所述DCI指示确定下次传输块TB传输是初传还是重传，包括：
    根据所述DCI指示中的新数据指示NDI确定下次传输块TB传输是初传还是重传。
  9. 根据权利要求1所述的方法，其特征在于，所述根据网络指示确定下次传输块TB传输是初传还是重传，包括：
    对于所有HARQ进程，根据所述网络指示确定下次传输块TB传输是初传还是重传。
  10. 根据权利要求1所述的方法，其特征在于，所述根据网络指示确定下次传输块TB传输是初传还是重传，包括：
    对于所有传输块TB没有被成功译码的HARQ进程，根据所述网络指示确定下次传输块TB传输是初传还是重传。
  11. 根据权利要求1所述的方法，其特征在于，所述根据网络指示确定下次传输块TB传输是初传还是重传，包括：
    对于所有所述MBS相关的HARQ进程，根据所述网络指示确定下次传输块TB传输是初传还是重传。
  12. 根据权利要求1所述的方法，其特征在于，所述根据网络指示确定下次传输块TB传输是初传还是重传，包括：
    对于所有所述MBS相关的且传输块TB没有被成功译码的HARQ进程，根据所述网络指示确定下次传输块TB传输是初传还是重传。
  13. 根据权利要求1-12中任一项所述的方法，其特征在于，所述方法还包括：
    根据组无线网络临时标识G-RNTI解码的物理下行控制信道PDCCH确定所述MBS相关的HARQ进程。
  14. 一种混合自动重传请求HARQ进程处理方法，其特征在于，所述方法应用于网络侧，所述方法包括：
    向终端发送网络指示，所述网络指示用于所述终端确定传输块TB传输是初传还是重传。
  15. 根据权利要求14所述的方法，其特征在于，所述网络指示携带于下行控制信息DCI指示中。
  16. 一种混合自动重传请求HARQ进程处理装置，其特征在于，所述装置应用于终端，所述装置包括：
    执行模块，用于对于非激活态组播业务MBS，在媒体接入控制MAC重置过程中，终端根据协议约定对混合自动重传请求HARQ进程执行以下操作：
    不清空HARQ buffer；
    根据网络指示确定下次传输块TB传输是初传还是重传。
  17. 一种混合自动重传请求HARQ进程处理装置，其特征在于，所述装置应用于网络侧，所述装置包括：
    发送模块，用于向终端发送网络指示，所述网络指示用于所述终端确定传输块TB传输是初传还是重传。
  18. 一种通信设备，其中，包括：收发器；存储器；处理器，分别与所述收发器及所述存储器连接，配置为通过执行所述存储器上的计算机可执行指令，控制所述收发器的无线信号收发，并能够实现权利要求1-15中任一项所述的方法。
  19. 一种计算机存储介质，其中，所述计算机存储介质存储有计算机可执行指令；所述计算机可执行指令被处理器执行后，能够实现权利要求1-15中任一项所述的方法。
CN202280002297.8A 2022-07-20 2022-07-20 混合自动重传请求harq进程处理方法及装置 Pending CN117751561A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/106896 WO2024016242A1 (zh) 2022-07-20 2022-07-20 混合自动重传请求harq进程处理方法及装置

Publications (1)

Publication Number Publication Date
CN117751561A true CN117751561A (zh) 2024-03-22

Family

ID=89616654

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202280002297.8A Pending CN117751561A (zh) 2022-07-20 2022-07-20 混合自动重传请求harq进程处理方法及装置

Country Status (2)

Country Link
CN (1) CN117751561A (zh)
WO (1) WO2024016242A1 (zh)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102055573B (zh) * 2009-11-03 2013-05-15 电信科学技术研究院 一种harq进程的处理方法、设备和系统
CN110830177B (zh) * 2018-08-10 2021-03-30 华为技术有限公司 一种混合自动重传请求传输方法和装置
CN111132186B (zh) * 2018-10-31 2021-11-30 华为技术有限公司 一种重置mac层、数据传输方法及装置
CN113517956A (zh) * 2020-04-10 2021-10-19 华为技术有限公司 一种清空缓存的方法及装置
CN118214523A (zh) * 2020-04-30 2024-06-18 华为技术有限公司 通信方法和装置
CN113765628B (zh) * 2020-06-05 2023-05-09 中国移动通信有限公司研究院 数据处理方法、装置、相关设备及存储介质
KR20220032484A (ko) * 2020-09-07 2022-03-15 아서스테크 컴퓨터 인코포레이션 무선 통신 시스템에서 ｍａｃ 리셋에 관한 이동성 절차를 위한 방법 및 장치

Also Published As

Publication number Publication date
WO2024016242A1 (zh) 2024-01-25

Similar Documents

Publication Publication Date Title
US11283554B2 (en) Method for partial retransmission
RU2477004C2 (ru) Проверка правильности обнаружения подтверждения приема по схеме н-аrq посредством комбинирования данных и повторного декодирования
CN110291732B (zh) 无线网络中的损坏数据的自动重传
JP3450729B2 (ja) パケット通信装置
KR101532789B1 (ko) 재전송 데이터를 처리하는 ｈａｒｑ 동작 방법
US20120307753A1 (en) Method for transmitting packet switched data in a cellular radio communicaton system during cell change
CN114402655B (zh) 一种位置信息的确定方法及其装置
WO2018121462A1 (zh) 一种多载波中传输数据的方法、终端设备和网络设备
CN112398599A (zh) 通信系统、操作通信系统的方法以及操作通信设备的方法
CN111181689B (zh) 一种简化DigRF接收侧的NEST机制处理方法及系统
CN117751561A (zh) 混合自动重传请求harq进程处理方法及装置
US20240188086A1 (en) Resource mapping method and communication device for uplink control information (uci)
WO2018126410A1 (zh) 数据传输方法及终端与网络设备
CN115486003A (zh) 一种数据接收的处理方法及其装置
CN117751684A (zh) 媒体接入控制mac重置定时器的处理方法及装置
RU2327221C2 (ru) Уменьшенное время ожидания для восстановления после ошибок коммуникаций
WO2017075832A1 (zh) 一种下行数据包、上行数据包传输方法及设备
CN110431899B (zh) 一种基于载波聚合的解调方法及装置
WO2024016244A1 (zh) 支持非激活态组播业务接收的配置方法及装置
WO2023245450A1 (zh) 定时提前量报告上报方法和装置
WO2024152160A1 (zh) 信息反馈方法和装置
WO2024092532A1 (zh) 一种侧行链路harq rtt定时器的启动或重启方法及装置
CN118285080A (zh) 侧行链路无线链路失败的处理方法及装置
CN118266198A (zh) 一种侧行链路连续先听后说失败的上报方法及装置
JP2006148784A (ja) 通信方法、及び通信装置

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