CN107733578B - 一种对下行数据进行反馈的方法及装置 - Google Patents

一种对下行数据进行反馈的方法及装置 Download PDF

Info

Publication number
CN107733578B
CN107733578B CN201610665878.6A CN201610665878A CN107733578B CN 107733578 B CN107733578 B CN 107733578B CN 201610665878 A CN201610665878 A CN 201610665878A CN 107733578 B CN107733578 B CN 107733578B
Authority
CN
China
Prior art keywords
subframe
uplink
configuration
information
downlink
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201610665878.6A
Other languages
English (en)
Other versions
CN107733578A (zh
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.)
China Academy of Telecommunications Technology CATT
Datang Mobile Communications Equipment Co Ltd
Original Assignee
China Academy of Telecommunications Technology CATT
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 China Academy of Telecommunications Technology CATT filed Critical China Academy of Telecommunications Technology CATT
Priority to CN201610665878.6A priority Critical patent/CN107733578B/zh
Priority to KR1020197007225A priority patent/KR102197444B1/ko
Priority to JP2019507261A priority patent/JP6756901B2/ja
Priority to US16/325,178 priority patent/US10911205B2/en
Priority to EP17838410.3A priority patent/EP3499764A4/en
Priority to PCT/CN2017/086271 priority patent/WO2018028278A1/zh
Publication of CN107733578A publication Critical patent/CN107733578A/zh
Application granted granted Critical
Publication of CN107733578B publication Critical patent/CN107733578B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1822Automatic repetition systems, e.g. Van Duuren systems involving configuration of automatic repeat request [ARQ] with parallel processes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/1607Details of the supervisory signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/003Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055Physical resource allocation for ACK/NACK
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1854Scheduling and prioritising arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1861Physical mapping arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1864ARQ related signaling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/04Wireless resource allocation
    • H04W72/044Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446Resources in time domain, e.g. slots or frames

Landscapes

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

Abstract

本申请公开了一种对下行数据进行反馈的方法及装置,当UE的处理时长缩短时,对下行数据进行反馈的反馈时序信息可以适应性发生改变。上述方法包括:确定UE的处理能力,上述处理能力是指上述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;根据确定的处理能力,确定上述UE对上述下行数据进行反馈的反馈时序信息。

Description

一种对下行数据进行反馈的方法及装置
技术领域
本申请涉及通信技术领域,尤其涉及一种对下行数据进行反馈的方法及装置。
背景技术
随着移动通信业务需求的发展变化,国际电信联盟(InternationalTelecommunication Union,ITU)等多个组织对未来移动通信系统都定义了更高的用户面时延性能要求。在不改变传输时间间隔(Transmission Time Interval,TTI)的情况下(此时TTI为1毫秒),可以通过提高用户设备(User Equipment,UE)的处理性能,缩短处理时长,从而提高用户面时延性能。
表1所示为长期演进(Long Term Evolution,LTE)系统中,时分双工(TimeDivision Duplexing,TDD)模式下子帧的上下行配置方式。其中,TDD模式下的一个无线帧为10毫秒,每个无线帧包括0~9共10个子帧,一个子帧为1毫秒;对于每个无线帧,现有技术共定义了7种子帧的上下行配置方式,配置编号分别为0~6;如表1所示,D为下行子帧,U为上行子帧,S为特殊子帧。
Figure BDA0001077670900000011
表1
在TDD模式的LTE系统中,设UE在下行或特殊子帧m中接收下行数据,并经过k个子帧(k毫秒)对该下行数据进行处理和传输后,可以在后续的上行子帧中做出该下行数据是否需要重传的反馈,包括确定(Acknowledgement,ACK)反馈和否定(NegativeAcknowledgement,NACK)反馈。由于现有技术对数据的处理时长为3个子帧(3毫秒),传输时长为1个子帧(1毫秒),此时,对于在下行或特殊子帧m中接收的下行数据,最快可以在向后经过的第4个子帧(k=4)中进行反馈,如果该第4个子帧不是上行子帧,则可以在该第4个子帧之后的第1个上行子帧中进行反馈。
那么,在一个上行子帧n中,可以对在多个下行或特殊子帧m接收到的下行数据进行反馈,其中,m=n-k+10β(当n-k<-10时,β为2,当-10≤n-k<0时,β为1,当n-k≥0时,β为0)。表2所示为当处理时长为3个子帧时,针对每一种上下行配置方式下,每个上行子帧n可以对应的k的取值;以表2为依据,就可以得到现有技术中对下行数据进行反馈的反馈时序信息,并通过高层指令为终端指示发送反馈信息的物理上行链路控制信道(Physical UplinkControl Channel,PUCCH)隐式资源。
Figure BDA0001077670900000021
表2
但是,当需要采用缩短处理时长的方式来提高用户面时延性能时,上述现有技术中对下行数据进行反馈的反馈时序信息,以及依据该反馈时序信息所指示的PUCCH隐式资源,都将无法适用。
可见,现有技术中存在当UE的处理时长缩短时,对下行数据进行反馈的反馈时序信息无法适用的问题。
发明内容
本申请实施例提供一种对下行数据进行反馈的方法及装置,用以解决现有技术中存在的当UE的处理时长缩短时,对下行数据进行反馈的反馈时序信息无法适用的问题。
本申请实施例提供一种对下行数据进行反馈的方法,包括:
确定用户设备UE的处理能力,上述处理能力是指上述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;
根据确定的处理能力,确定上述UE对上述下行数据进行反馈的反馈时序信息。
本申请实施例还提供一种对下行数据进行反馈的装置,包括:
处理模块,用于确定用户设备UE的处理能力,上述处理能力是指上述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;
反馈模块,用于根据确定的处理能力,确定上述UE对上述下行数据进行反馈的反馈时序信息。
本申请实施例提供一种用户设备UE结构示意图,包括:
处理器,用于读取存储器中的程序,执行下列过程:
确定UE的处理能力,上述处理能力是指上述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;
根据确定的处理能力,确定上述UE对上述下行数据进行反馈的反馈时序信息。
本申请实施例还提供一种网络侧设备结构示意图,包括:
处理器,用于读取存储器中的程序,执行下列过程:
确定UE的处理能力,上述处理能力是指上述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;
根据确定的处理能力,确定上述UE对上述下行数据进行反馈的反馈时序信息。
本申请有益效果包括:
本申请实施例提供的方案中,根据UE处理能力的不同,也即,根据UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长的不同,来分别确定UE对下行数据进行反馈的反馈时序信息,此时,若UE的处理时长缩短,对下行数据进行反馈的反馈时序信息则会适应性地发生改变,完成对下行数据的反馈,进而提高用户面时延性能。
本申请的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本申请的进一步理解,并且构成说明书的一部分,与本申请实施例一起用于解释本申请,并不构成对本申请的限制。在附图中:
图1为本申请实施例1提供的一种对下行数据进行反馈的方法的流程示意图;
图2为本申请实施例2提供的方案中,UE在3个进程下对下行数据进行反馈的示意图;
图3为本申请实施例3提供的方案中,UE在5个进程下对下行数据进行反馈的示意图;
图4为本申请实施例4提供的方案中,UE在8个进程下对下行数据进行反馈的示意图;
图5a为本申请实施例5提供的方案中,UE在7个进程下对下行数据进行反馈的示意图;
图5b为分别在处理时长为3个子帧的UE中,以及在本申请实施例5提供的方案中,针对上行子帧2上的反馈时序示意图;
图5c为在本申请实施例5中,针对上行子帧2上,用于发送反馈信息的PUCCH隐式资源分配示意图;
图6为本申请实施例6提供的方案中,UE在10个进程下对下行数据进行反馈的示意图;
图7为本申请实施例7提供的方案中,UE在13个进程下对下行数据进行反馈的示意图;
图8为本申请实施例8提供的方案中,UE在5个进程下对下行数据进行反馈的示意图;
图9为本申请实施例9提供的方案中,UE在2个进程下对下行数据进行反馈的示意图;
图10为本申请实施例10提供的方案中,UE在3个进程下对下行数据进行反馈的示意图;
图11为本申请实施例11提供的方案中,UE在6个进程下对下行数据进行反馈的示意图;
图12为本申请实施例12提供的方案中,UE在7个进程下对下行数据进行反馈的示意图;
图13为本申请实施例13提供的方案中,UE在8个进程下对下行数据进行反馈的示意图;
图14为本申请实施例14提供的方案中,UE在12个进程下对下行数据进行反馈的示意图;
图15为本申请实施例15提供的方案中,UE在5个进程下对下行数据进行反馈的示意图;
图16a为本申请实施例16提供的一种对下行数据进行反馈的装置的结构示意图之一;
图16b为本申请实施例16提供的一种对下行数据进行反馈的装置的结构示意图之二;
图16c为本申请实施例16提供的一种对下行数据进行反馈的装置的结构示意图之三;
图16d为本申请实施例16提供的一种对下行数据进行反馈的装置的详细结构示意图;
图17为本申请实施例17提供的一种用户设备UE结构示意图;
图18为本申请实施例18提供的一种网络侧设备结构示意图。
具体实施方式
为了给出当UE的处理时长缩短时,对下行数据进行反馈的反馈时序信息适应性发生改变的实现方案,本申请实施例提供了一种对下行数据进行反馈的方法,以下结合说明书附图对本申请的优选实施例进行说明,应当理解,此处所描述的优选实施例仅用于说明和解释本申请,并不用于限定本申请。并且在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
实施例1
本申请实施例1提供一种对下行数据进行反馈的方法,其流程示意图如图1所示,具体可以包括以下步骤:
S101、确定UE的处理能力,上述处理能力是指上述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;
S102、根据确定的处理能力,确定上述UE对上述下行数据进行反馈的反馈时序信息。
实际实施时,用户设备UE和网络侧设备(例如基站)均可以作为本申请实施例1提供的方案的执行主体。
当UE作为执行主体时,UE根据自身的处理能力,以及与不同的处理能力对应的反馈时序信息,确定出自身适用的反馈时序信息。
当网络侧设备作为执行主体时,可以接收UE上报的处理能力,根据UE上报的处理能力确定出该UE所适用的反馈时序信息。具体地,网络侧设备可以直接将与该UE的处理能力相适应的各种上下行配置方式下的反馈时序信息统一发送给UE,也可以将需要UE使用的上下行配置方式和与该上下行配置方式对应的反馈时序信息通知给UE。
在上述两种具体情形下,都可以根据UE处理能力的不同,也即,根据UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长的不同,来分别确定UE对下行数据进行反馈的反馈时序信息,此时,若UE的处理时长缩短,对下行数据进行反馈的反馈时序信息则会适应性地发生改变,完成对下行数据的反馈,进而提高用户面时延性能。
具体地,上述步骤S102,可以包括:若上述处理能力对应的处理时长为3个子帧,确定上述UE对上述下行数据进行反馈的第一反馈时序信息,该第一反馈时序信息为第三代合作伙伴计划长期演进发行第13版(3rd Generation Partnership Project Long TermEvolution Release 13,3GPP LTE Rel-13)及之前版本的协议中所定义的反馈时序信息;若上述处理能力对应的处理时长小于3个子帧,确定上述UE对上述下行数据进行反馈的第二反馈时序信息,其中,上述UE在第二反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长,小于在第一反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长。
实际实施时,如果确定出处理能力对应的处理时长仍为3个子帧,那么,可以仍采用3GPP LTE Rel-13及之前版本的协议中所定义的反馈时序信息,也即采用根据表2可以得到的反馈时序信息;如果确定出处理能力对应的处理时长小于3个子帧,即UE的处理时长缩短,此时,可以根据UE的处理时长,使用新的反馈时序信息对下行数据进行反馈。
那么,针对处理能力对应的处理时长小于3个子帧的情形,如果上述处理能力对应的处理时长为2个子帧(2毫秒),传输时长为1个子帧(1毫秒),此时,对于在子帧(下行子帧或特殊子帧)m中接收的下行数据,最快可以在自接收到下行数据起的第3个子帧(k=3)中进行反馈,如果该第3个子帧不是上行子帧,则可以在该第3个子帧之后的第1个上行子帧中进行反馈。那么,在一个上行子帧n中,可以对在多个子帧(下行子帧或特殊子帧)m接收到的下行数据进行反馈,其中,m=n-k+10β(当n<k时,β为1,当n≥k时,β为0)。表3所示为当处理时长为2个子帧时,针对每一种上下行配置方式下,每个上行子帧n可以对应的k的取值。
Figure BDA0001077670900000081
表3
同理,如果上述处理能力对应的处理时长为1个子帧(1毫秒),在子帧(下行子帧或特殊子帧)m中接收的下行数据,最快可以在向后经过的第3个子帧(k=3)中进行反馈。表4所示为当处理时长为1个子帧时,在每一种上下行配置方式下,每个上行子帧n对应的k的取值。
Figure BDA0001077670900000082
表4
显然,根据表3和表4,就可以确定出当处理时长为2个子帧或1个子帧时,在每一种上下行配置方式下,UE对下行数据进行反馈的反馈时序信息,完成对下行数据的反馈。
进一步地,本申请实施例1提供的方法,还可以包括:根据确定的处理能力以及上述UE的上下行配置信息,确定上述UE对上述下行数据进行反馈时的最大混合自动重传请求(Hybrid Automatic Repeat Request,HARQ)进程数。
具体地,根据确定出的反馈时序信息,可以得到在同一处理能力和上下行配置信息下,UE对下行数据进行反馈的最大HARQ进程数。表5所示为当处理时长为2个子帧时,针对每一种上下行配置方式,所列举的最大HARQ进程数;表6所示为当处理时长为1个子帧时,针对每一种上下行配置方式,所列举的最大HARQ进程数。
上下行配置 最大HARQ进程数
0 3
1 5
2 8
3 7
4 10
5 13
6 5
表5
上下行配置 最大HARQ进程数
0 2
1 3
2 6
3 7
4 8
5 12
6 5
表6
至此,根据表3和表5,就可以得到当处理时长为2个子帧时,针对每一种上下行配置方式,UE在多个进程下对下行数据进行反馈的具体流程。同理,根据表4和表6,也可以得到当处理时长为1个子帧时,针对每一种上下行配置方式,UE在多个进程下对下行数据进行反馈的具体流程。
进一步地,上述步骤S102之后,还可以包括:若在配置编号为L的上下行配置方式下,在上行子帧n中对在子帧n-k+10β接收的下行数据进行反馈,则在子帧n-k+10β中,确定与第三反馈时序信息所指示的子帧相同的子帧;其中,上述第三反馈时序信息所指示的子帧是指在针对处理时长为3个子帧的UE所设计的反馈时序中,在配置编号为L(L为非负整数)的上下行配置方式下,在上行子帧n中发送的反馈信息所对应的发送下行数据的子帧(该子帧也即上行子帧n所反馈的发送下行数据的子帧,或者说为发送上行子帧n所反馈的下行数据的子帧);针对确定的上述相同的子帧,与上述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;针对子帧n-k+10β中除确定的上述相同的子帧以外的任一子帧,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源或者根据预定义的规则,确定用于发送反馈信息的PUCCH隐式资源。
也即,在配置编号为L的上下行配置方式下,针对处理时长小于3个子帧的UE,如果是对在子帧m中接收的下行数据通过上行子帧n进行反馈,而针对处理时长为3个子帧的UE,同样也是在该子帧m中接收的下行数据通过该上行子帧n进行反馈,那么,针对这种情况,对于该子帧m,可以与处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源。而对于其他不存在上述情况的任一子帧,则可以通过高层信令指示来确定PUCCH隐式资源,或者通过预定义的规则来确定PUCCH隐式资源。
具体地,针对子帧n-k+10β中除确定的上述相同的子帧以外的任一子帧,根据预定义的规则,确定用于发送反馈信息的PUCCH隐式资源,可以包括:针对子帧n-k+10β中除确定的上述相同的子帧以外的任一子帧,确定高层信令指示的上述PUCCH隐式资源的起始点,并根据上述起始点和在该任一子帧中进行物理下行链路控制信道(Physical DownlinkControl Channel,PDCCH)传输所使用的第一个控制信道单元(Control Channel Element,CCE)的索引号,确定用于发送反馈信息的PUCCH隐式资源;其中,上述起始点,与上述处理时长为3个子帧的UE发送反馈信息的PUCCH隐式资源的起始点不同。
如上所述,针对其他不存在上述情况的任一子帧,可以通过预定义的规则来确定新的PUCCH隐式资源,该预定义的规则具体可以为:通过高层信令确定新的PUCCH的起始点,根据该起始点以及该任一子帧进行PDCCH传输所使用的第一个CCE的索引号,来确定新的PUCCH隐式资源。
可见,本申请实施例1提供的对下行数据进行反馈的方法,可以实现当UE的处理时长缩短时,对下行数据进行反馈的反馈时序信息适应性发生改变。
下面结合附图,用实施例2~实施例14对本申请实施例1提供的方法进行详细描述。
实施例2
当UE对接受的下行数据进行处理的处理能力对应的处理时长为2个子帧,上下行配置信息对应的配置编号为0时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为3、4、8或9时,k为3;其中,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为3;
针对子帧0、子帧1、子帧5和子帧6,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图2所示为本申请实施例2提供的方案中,UE在3个进程下对下行数据进行反馈的示意图。图中的PDSCH传输帧为物理下行共享信道(Physical Downlink Shared Channel,PDSCH)传输帧。
实施例3
当UE对接收的下行数据进行处理的处理能力对应的处理时长为2个子帧,上下行配置信息对应的配置编号为1时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2或7时,k为3和6,当n为3或8时,k为3;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为5;
针对子帧1和子帧6,与所述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;
针对子帧0、子帧4、子帧5和子帧9,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图3所示为本申请实施例3提供的方案中,UE在5个进程下对下行数据进行反馈的示意图。
实施例4
当UE对接收的下行数据进行处理的处理能力对应的处理时长为2个子帧,上下行配置信息对应的配置编号为2时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2或7时,k为7、4、3和6;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为8;
针对子帧0、子帧1、子帧3、子帧5、子帧6和子帧8,与所述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;
针对子帧4和子帧9,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图4所示为本申请实施例4提供的方案中,UE在8个进程下对下行数据进行反馈的示意图。
实施例5
当UE对接收的下行数据进行处理的处理能力对应的处理时长为2个子帧,上下行配置信息对应的配置编号为3时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2时,k为7、5和6;当n为3时,k为5和4;当n为4时,k为4和3;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为7;
针对子帧0、子帧5、子帧6和子帧8,与所述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;
针对子帧1、子帧7和子帧9,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图5a所示为本申请实施例5提供的方案中,UE在7个进程下对下行数据进行反馈的示意图。
图5b所示为分别在处理时长为3个子帧的UE中,以及在本申请实施例5提供的方案中,针对上行子帧2上的反馈时序示意图;图5c所示为在本申请实施例5中,针对上行子帧2上,用于发送反馈信息的PUCCH隐式资源分配示意图。图中的PUSCH为物理上行共享信道(Physical Uplink Shared Channel,PUSCH)。
实施例6
当UE对接收的下行数据进行处理的处理能力对应的处理时长为2个子帧,上下行配置信息对应的配置编号为4时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2时,k为8、7、6和11;当n为3时,k为6、5、4和3;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为10;
针对子帧1、子帧4、子帧5、子帧7、子帧8和子帧9,与所述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;
针对子帧0和子帧6,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图6所示为本申请实施例6提供的方案中,UE在10个进程下对下行数据进行反馈的示意图。
实施例7
当UE对接收的下行数据进行处理的处理能力对应的处理时长为2个子帧,上下行配置信息对应的配置编号为5时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2时,k为12、9、8、7、5、4、3、11和6;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为13;
针对子帧0、子帧1、子帧3、子帧4、子帧5、子帧6、子帧7和子帧8,与所述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源。
针对子帧9,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图7所示为本申请实施例7提供的方案中,UE在13个进程下对下行数据进行反馈的示意图。
实施例8
当UE对接收的下行数据进行处理的处理能力对应的处理时长为2个子帧,上下行配置信息对应的配置编号为6时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2或7时,k为6;当n为3或4时,k为4;当n为8时,k为3;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为5;
针对子帧0、子帧1、子帧5、子帧6和子帧9,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图8所示为本申请实施例8提供的方案中,UE在5个进程下对下行数据进行反馈的示意图。
实施例9
当UE对接收的下行数据进行处理的处理能力对应的处理时长为1个子帧,上下行配置信息对应的配置编号为0时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2、3、7或8时,k为2;其中,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为2;
针对子帧0、子帧1、子帧5和子帧6,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图9所示为本申请实施例9提供的方案中,UE在2个进程下对下行数据进行反馈的示意图。
实施例10
当UE对接收的下行数据进行处理的处理能力对应的处理时长为1个子帧,上下行配置信息对应的配置编号为1时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2或7时,k为3和2;当n为3或8时,k为2;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为3;
针对子帧0、子帧1、子帧4、子帧5、子帧6和子帧9,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图10所示为本申请实施例10提供的方案中,UE在3个进程下对下行数据进行反馈的示意图。
实施例11
当UE对接收的下行数据进行处理的处理能力对应的处理时长为1个子帧,上下行配置信息对应的配置编号为2时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2或7时,k为4、3、2和6;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为6;
针对子帧1、子帧3、子帧6和子帧8,与所述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;
针对子帧0、子帧4、子帧5和子帧9,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图11所示为本申请实施例11提供的方案中,UE在6个进程下对下行数据进行反馈的示意图。
实施例12
当UE对接收的下行数据进行处理的处理能力对应的处理时长为1个子帧,上下行配置信息对应的配置编号为3时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2时,k为7、5和6;当n为3时,k为5和4;当n为4时,k为4和3;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为7;
针对子帧0、子帧5、子帧6和子帧8,与所述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;
针对子帧1、子帧7和子帧9,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图12所示为本申请实施例12提供的方案中,UE在7个进程下对下行数据进行反馈的示意图。
实施例13
当UE对接收的下行数据进行处理的处理能力对应的处理时长为1个子帧,上下行配置信息对应的配置编号为4时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2时,k为8、7、5和6;当n为3时,k为5、4、3和2;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为8;
针对子帧4、子帧5、子帧8和子帧9,与所述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;
针对子帧0、子帧1、子帧6和子帧7,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图13所示为本申请实施例13提供的方案中,UE在8个进程下对下行数据进行反馈的示意图。
实施例14
当UE对接收的下行数据进行处理的处理能力对应的处理时长为1个子帧,上下行配置信息对应的配置编号为5时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2时,k为9、8、7、5、4、3、2、11和6;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为12;
针对子帧1、子帧3、子帧4、子帧5、子帧6、子帧7和子帧8,与所述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源。
针对子帧0和子帧9,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图14所示为本申请实施例14提供的方案中,UE在12个进程下对下行数据进行反馈的示意图。
实施例15
当UE对接收的下行数据进行处理的处理能力对应的处理时长为1个子帧,上下行配置信息对应的配置编号为6时,在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n为2、3或4时,k为3;当n为7或8时,k为2;其中,当n<k时,β为1,当n≥k时,β为0;
根据上述处理能力和上下行配置信息,确定上述UE对上述下行数据进行反馈时的HARQ进程数为5;
针对子帧0、子帧1、子帧5、子帧6和子帧9,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
图15所示为本申请实施例15提供的方案中,UE在5个进程下对下行数据进行反馈的示意图。
综上可见,本申请实施例2~实施例15提供的对下行数据进行反馈的方法,可以实现当UE的处理时长缩短时,对下行数据进行反馈的反馈时序信息适应性发生改变。
实施例16
基于同一构思,根据本申请上述实施例提供的一种对下行数据进行反馈的方法,相应地,本申请实施例16还提供了一种对下行数据进行反馈的装置,具体实现方式可以参见前述方法的实施例,重复之处不再赘述。
本申请实施例16提供了一种对下行数据进行反馈的装置,其结构示意图如图16a所示,具体可以包括:
处理模块1601,用于确定UE的处理能力,上述处理能力是指上述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;
反馈模块1602,用于根据确定的处理能力,确定上述UE对上述下行数据进行反馈的反馈时序信息。
具体地,反馈模块1602,可以用于:若上述处理能力对应的处理时长为3个子帧,确定上述UE对上述下行数据进行反馈的第一反馈时序信息,该第一反馈时序信息为3GPP LTERel-13及之前版本的协议中所定义的反馈时序信息;若上述处理能力对应的处理时长小于3个子帧,确定上述UE对上述下行数据进行反馈的第二反馈时序信息,其中,上述UE在第二反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长,小于在第一反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长。
具体地,反馈模块1602,可以用于:若上述处理能力对应的处理时长为2个子帧,确定在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0;其中:若上下行配置信息对应的配置编号为0,则n为3、4、8或9时,k为3;若上述上下行配置信息对应的配置编号为1,则n为2或7时,k为3和6;n为3或8时,k为3;若上述上下行配置信息对应的配置编号为2,则n为2或7时,k为7、4、3和6;若上述上下行配置信息对应的配置编号为3,则n为2时,k为7、5和6;n为3时,k为5和4;n为4时,k为4和3;若上述上下行配置信息对应的配置编号为4,则n为2时,k为8、7、6和11;n为3时,k为6、5、4和3;若上述上下行配置信息对应的配置编号为5,则n为2时,k为12、9、8、7、5、4、3、11和6;若上述上下行配置信息对应的配置编号为6,则n为2或7时,k为6;n为3或4时,k为4;n为8时,k为3。
具体地,反馈模块1602,可以用于:若上述处理能力对应的处理时长为1个子帧,确定在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0;其中:若上下行配置信息对应的配置编号为0,则n为2、3、7或8时,k为2;若上述上下行配置信息对应的配置编号为1,则n为2或7时,k为3和2;n为3或8时,k为2;若上述上下行配置信息对应的配置编号为2,则n为2或7时,k为4、3、2和6;若上述上下行配置信息对应的配置编号为3,则n为2时,k为7、5和6;n为3时,k为5和4;n为4时,k为4和3;若上述上下行配置信息对应的配置编号为4,则n为2时,k为8、7、5和6;n为3时,k为5、4、3和2;若上述上下行配置信息对应的配置编号为5,则n为2时,k为9、8、7、5、4、3、2、11和6;若上述上下行配置信息对应的配置编号为6,则n为2、3或4时,k为3;n为7或8时,k为2。
进一步地,本申请实施例16提供的装置,如图16b所示,还可以包括:
进程数确定模块1603,用于根据确定的处理能力以及所述UE的上下行配置信息,确定所述UE对所述下行数据进行反馈时的最大HARQ进程数。
具体地,进程数确定模块1603,可以用于:当上述处理能力对应的处理时长为2个子帧时,若上述上下行配置信息对应的配置编号为0,则上述最大HARQ进程数为3;若上述配置编号为1,则上述最大HARQ进程数为5;若上述配置编号为2,则上述最大HARQ进程数为8;若上述配置编号为3,则上述最大HARQ进程数为7;若上述配置编号为4,则上述最大HARQ进程数为10;若上述配置编号为5,则上述最大HARQ进程数为13;若上述配置编号为6,则上述最大HARQ进程数为5。
具体地,进程数确定模块1603,可以用于:当上述处理能力对应的处理时长为1个子帧时,若上述上下行配置信息对应的配置编号为0,则上述最大HARQ进程数为2;若上述配置编号为1,则上述最大HARQ进程数为3;若上述配置编号为2,则上述最大HARQ进程数为6;若上述配置编号为3,则上述最大HARQ进程数为7;若上述配置编号为4,则上述最大HARQ进程数为8;若上述配置编号为5,则上述最大HARQ进程数为12;若上述配置编号为6,则上述最大HARQ进程数为5。
进一步地,本申请实施例16提供的装置中,如图16c所示,还可以包括:
资源确定模块1604,用于若在配置编号为L的上下行配置方式下,在上行子帧n中对在子帧n-k+10β接收的下行数据进行反馈,则在子帧n-k+10β中,确定与第三反馈时序信息所指示的子帧相同的子帧;其中,上述第三反馈时序信息所指示的子帧是指在针对处理时长为3个子帧的UE所设计的反馈时序中,在配置编号为L的上下行配置方式下,在上行子帧n中发送的反馈信息所对应的发送下行数据的子帧;针对确定的上述相同的子帧,与上述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;针对子帧n-k+10β中除确定的上述相同的子帧以外的任一子帧,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
具体地,资源确定模块1604,可以用于:针对子帧n-k+10β中除确定的上述相同的子帧以外的任一子帧,确定高层信令指示的上述PUCCH隐式资源的起始点,并根据上述起始点和在该任一子帧中进行PDCCH传输所使用的第一个CCE的索引号,确定用于发送反馈信息的PUCCH隐式资源;其中,上述起始点,与上述处理时长为3个子帧的UE发送反馈信息的PUCCH隐式资源的起始点不同。
图16d所示为本申请实施例16提供的一种对下行数据进行反馈的装置的详细结构示意图。
可见,本申请实施例16提供的对下行数据进行反馈的装置,可以实现当UE的处理时长缩短时,对下行数据进行反馈的反馈时序信息适应性发生改变。
实施例17
本申请实施例17提供一种用户设备UE结构示意图,如图17所示,包括:
处理器1701,用于读取存储器1702中的程序,执行下列过程:
确定UE的处理能力,上述处理能力是指上述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;
根据确定的处理能力,确定上述UE对上述下行数据进行反馈的反馈时序信息。
具体地,处理器1701,可以用于:若上述处理能力对应的处理时长为3个子帧,确定上述UE对上述下行数据进行反馈的第一反馈时序信息,该第一反馈时序信息为3GPP LTERel-13及之前版本的协议中所定义的反馈时序信息;若上述处理能力对应的处理时长小于3个子帧,确定上述UE对上述下行数据进行反馈的第二反馈时序信息,其中,上述UE在第二反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长,小于在第一反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长。
具体地,处理器1701,可以用于:若上述处理能力对应的处理时长为2个子帧,确定在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0;其中:若上下行配置信息对应的配置编号为0,则n为3、4、8或9时,k为3;若上述上下行配置信息对应的配置编号为1,则n为2或7时,k为3和6;n为3或8时,k为3;若上述上下行配置信息对应的配置编号为2,则n为2或7时,k为7、4、3和6;若上述上下行配置信息对应的配置编号为3,则n为2时,k为7、5和6;n为3时,k为5和4;n为4时,k为4和3;若上述上下行配置信息对应的配置编号为4,则n为2时,k为8、7、6和11;n为3时,k为6、5、4和3;若上述上下行配置信息对应的配置编号为5,则n为2时,k为12、9、8、7、5、4、3、11和6;若上述上下行配置信息对应的配置编号为6,则n为2或7时,k为6;n为3或4时,k为4;n为8时,k为3。
具体地,处理器1701,可以用于:若上述处理能力对应的处理时长为1个子帧,确定在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0;其中:若上下行配置信息对应的配置编号为0,则n为2、3、7或8时,k为2;若上述上下行配置信息对应的配置编号为1,则n为2或7时,k为3和2;n为3或8时,k为2;若上述上下行配置信息对应的配置编号为2,则n为2或7时,k为4、3、2和6;若上述上下行配置信息对应的配置编号为3,则n为2时,k为7、5和6;n为3时,k为5和4;n为4时,k为4和3;若上述上下行配置信息对应的配置编号为4,则n为2时,k为8、7、5和6;n为3时,k为5、4、3和2;若上述上下行配置信息对应的配置编号为5,则n为2时,k为9、8、7、5、4、3、2、11和6;若上述上下行配置信息对应的配置编号为6,则n为2、3或4时,k为3;n为7或8时,k为2。
进一步地,处理器1701,还可以用于:根据确定的处理能力以及所述UE的上下行配置信息,确定所述UE对所述下行数据进行反馈时的最大HARQ进程数。
具体地,处理器1701,可以用于:当上述处理能力对应的处理时长为2个子帧时,若上述上下行配置信息对应的配置编号为0,则上述最大HARQ进程数为3;若上述配置编号为1,则上述最大HARQ进程数为5;若上述配置编号为2,则上述最大HARQ进程数为8;若上述配置编号为3,则上述最大HARQ进程数为7;若上述配置编号为4,则上述最大HARQ进程数为10;若上述配置编号为5,则上述最大HARQ进程数为13;若上述配置编号为6,则上述最大HARQ进程数为5。
具体地,处理器1701,可以用于:当上述处理能力对应的处理时长为1个子帧时,若上述上下行配置信息对应的配置编号为0,则上述最大HARQ进程数为2;若上述配置编号为1,则上述最大HARQ进程数为3;若上述配置编号为2,则上述最大HARQ进程数为6;若上述配置编号为3,则上述最大HARQ进程数为7;若上述配置编号为4,则上述最大HARQ进程数为8;若上述配置编号为5,则上述最大HARQ进程数为12;若上述配置编号为6,则上述最大HARQ进程数为5。
进一步地,处理器1701,还可以用于:若在配置编号为L的上下行配置方式下,在上行子帧n中对在子帧n-k+10β接收的下行数据进行反馈,则在子帧n-k+10β中,确定与第三反馈时序信息所指示的子帧相同的子帧;其中,上述第三反馈时序信息所指示的子帧是指在针对处理时长为3个子帧的UE所设计的反馈时序中,在配置编号为L的上下行配置方式下,在上行子帧n中发送的反馈信息所对应的发送下行数据的子帧;针对确定的上述相同的子帧,与上述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;针对子帧n-k+10β中除确定的上述相同的子帧以外的任一子帧,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
具体地,处理器1701,可以用于:针对子帧n-k+10β中除确定的上述相同的子帧以外的任一子帧,确定高层信令指示的上述PUCCH隐式资源的起始点,并根据所述起始点和在该任一子帧中进行PDCCH传输所使用的第一个CCE的索引号,确定用于发送反馈信息的PUCCH隐式资源;其中,所述起始点,与所述处理时长为3个子帧的UE发送反馈信息的PUCCH隐式资源的起始点不同。
其中,在图17中,总线架构可以包括任意数量的互联的总线和桥,具体由处理器1701代表的一个或多个处理器和存储器1702代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。针对不同的UE,用户接口1703还可以是能够外接内接需要设备的接口,连接的设备包括但不限于小键盘、显示器、扬声器、麦克风、操纵杆等。
处理器1701负责管理总线架构和通常的处理,存储器1702可以存储处理器1701在执行操作时所使用的数据。
实施例18
本申请实施例18还提供一种网络侧设备结构示意图,如图18所示,包括:
处理器1801,用于读取存储器1802中的程序,执行下列过程:
确定UE的处理能力,上述处理能力是指上述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;
根据确定的处理能力,确定上述UE对上述下行数据进行反馈的反馈时序信息。
具体地,处理器1801,可以用于:若上述处理能力对应的处理时长为3个子帧,确定上述UE对上述下行数据进行反馈的第一反馈时序信息,该第一反馈时序信息为3GPP LTERel-13及之前版本的协议中所定义的反馈时序信息;若上述处理能力对应的处理时长小于3个子帧,确定上述UE对上述下行数据进行反馈的第二反馈时序信息,其中,上述UE在第二反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长,小于在第一反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长。
具体地,处理器1801,可以用于:若上述处理能力对应的处理时长为2个子帧,确定在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0;其中:若上下行配置信息对应的配置编号为0,则n为3、4、8或9时,k为3;若上述上下行配置信息对应的配置编号为1,则n为2或7时,k为3和6;n为3或8时,k为3;若上述上下行配置信息对应的配置编号为2,则n为2或7时,k为7、4、3和6;若上述上下行配置信息对应的配置编号为3,则n为2时,k为7、5和6;n为3时,k为5和4;n为4时,k为4和3;若上述上下行配置信息对应的配置编号为4,则n为2时,k为8、7、6和11;n为3时,k为6、5、4和3;若上述上下行配置信息对应的配置编号为5,则n为2时,k为12、9、8、7、5、4、3、11和6;若上述上下行配置信息对应的配置编号为6,则n为2或7时,k为6;n为3或4时,k为4;n为8时,k为3。
具体地,处理器1801,可以用于:若上述处理能力对应的处理时长为1个子帧,确定在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0;其中:若上下行配置信息对应的配置编号为0,则n为2、3、7或8时,k为2;若上述上下行配置信息对应的配置编号为1,则n为2或7时,k为3和2;n为3或8时,k为2;若上述上下行配置信息对应的配置编号为2,则n为2或7时,k为4、3、2和6;若上述上下行配置信息对应的配置编号为3,则n为2时,k为7、5和6;n为3时,k为5和4;n为4时,k为4和3;若上述上下行配置信息对应的配置编号为4,则n为2时,k为8、7、5和6;n为3时,k为5、4、3和2;若上述上下行配置信息对应的配置编号为5,则n为2时,k为9、8、7、5、4、3、2、11和6;若上述上下行配置信息对应的配置编号为6,则n为2、3或4时,k为3;n为7或8时,k为2。
进一步地,处理器1801,还可以用于:根据确定的处理能力以及所述UE的上下行配置信息,确定所述UE对所述下行数据进行反馈时的最大HARQ进程数。
具体地,处理器1801,可以用于:当上述处理能力对应的处理时长为2个子帧时,若上述上下行配置信息对应的配置编号为0,则上述最大HARQ进程数为3;若上述配置编号为1,则上述最大HARQ进程数为5;若上述配置编号为2,则上述最大HARQ进程数为8;若上述配置编号为3,则上述最大HARQ进程数为7;若上述配置编号为4,则上述最大HARQ进程数为10;若上述配置编号为5,则上述最大HARQ进程数为13;若上述配置编号为6,则上述最大HARQ进程数为5。
具体地,处理器1801,可以用于:当上述处理能力对应的处理时长为1个子帧时,若上述上下行配置信息对应的配置编号为0,则上述最大HARQ进程数为2;若上述配置编号为1,则上述最大HARQ进程数为3;若上述配置编号为2,则上述最大HARQ进程数为6;若上述配置编号为3,则上述最大HARQ进程数为7;若上述配置编号为4,则上述最大HARQ进程数为8;若上述配置编号为5,则上述最大HARQ进程数为12;若上述配置编号为6,则上述最大HARQ进程数为5。
进一步地,处理器1801,还可以用于:若在配置编号为L的上下行配置方式下,在上行子帧n中对在子帧n-k+10β接收的下行数据进行反馈,则在子帧n-k+10β中,确定与第三反馈时序信息所指示的子帧相同的子帧;其中,上述第三反馈时序信息所指示的子帧是指在针对处理时长为3个子帧的UE所设计的反馈时序中,在配置编号为L的上下行配置方式下,在上行子帧n中发送的反馈信息所对应的发送下行数据的子帧;针对确定的上述相同的子帧,与上述处理时长为3个子帧的UE共享发送反馈信息的PUCCH隐式资源;针对子帧n-k+10β中除确定的上述相同的子帧以外的任一子帧,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
具体地,处理器1801,可以用于:针对子帧n-k+10β中除确定的上述相同的子帧以外的任一子帧,确定高层信令指示的上述PUCCH隐式资源的起始点,并根据所述起始点和在该任一子帧中进行PDCCH传输所使用的第一个CCE的索引号,确定用于发送反馈信息的PUCCH隐式资源;其中,所述起始点,与所述处理时长为3个子帧的UE发送反馈信息的PUCCH隐式资源的起始点不同。
其中,在图18中,总线架构可以包括任意数量的互联的总线和桥,具体由处理器1801代表的一个或多个处理器和存储器1802代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。处理器1801负责管理总线架构和通常的处理,存储器1802可以存储处理器1801在执行操作时所使用的数据。
综上所述,本申请实施例提供的方案中,根据UE处理能力的不同,也即,根据UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长的不同,来分别确定UE对下行数据进行反馈的反馈时序信息,此时,当UE的处理时间缩短,对下行数据进行反馈的反馈时序信息将会适应性地发生改变,完成对下行数据的反馈,进而提高用户面时延性能。
显然,尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本的创造性概念,则可对这些实施例做出另外的改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

Claims (16)

1.一种对下行数据进行反馈的方法,其特征在于,包括:
确定用户设备UE的处理能力,所述处理能力是指所述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;
若所述处理能力对应的处理时长小于3个子帧,确定所述UE对所述下行数据进行反馈的第二反馈时序信息,其中,所述UE在第二反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长,小于在第一反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长;具体包括:
若所述处理能力对应的处理时长为2个子帧,确定在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0;其中:
若上下行配置信息对应的配置编号为0,则n为3、4、8或9时,k为3;
若所述上下行配置信息对应的配置编号为1,则n为2或7时,k为3和6;n为3或8时,k为3;
若所述上下行配置信息对应的配置编号为2,则n为2或7时,k为7、4、3和6;
若所述上下行配置信息对应的配置编号为3,则n为2时,k为7、5和6;n为3时,k为5和4;n为4时,k为4和3;
若所述上下行配置信息对应的配置编号为4,则n为2时,k为8、7、6和11;n为3时,k为6、5、4和3;
若所述上下行配置信息对应的配置编号为5,则n为2时,k为12、9、8、7、5、4、3、11和6;
若所述上下行配置信息对应的配置编号为6,则n为2或7时,k为6;n为3或4时,k为4;n为8时,k为3。
2.如权利要求1所述的方法,其特征在于,确定用户设备UE的处理能力后,包括:
若所述处理能力对应的处理时长为3个子帧,确定所述UE对所述下行数据进行反馈的第一反馈时序信息,该第一反馈时序信息为第三代合作伙伴计划长期演进发行第13版3GPPLTE Rel-13及之前版本的协议中所定义的反馈时序信息。
3.如权利要求1所述的方法,其特征在于,若所述处理能力对应的处理时长小于3个子帧,确定所述UE对所述下行数据进行反馈的反馈时序信息为第二反馈时序信息,包括:
若所述处理能力对应的处理时长为1个子帧,确定在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0;其中:
若上下行配置信息对应的配置编号为0,则n为2、3、7或8时,k为2;
若所述上下行配置信息对应的配置编号为1,则n为2或7时,k为3和2;n为3或8时,k为2;
若所述上下行配置信息对应的配置编号为2,则n为2或7时,k为4、3、2和6;
若所述上下行配置信息对应的配置编号为3,则n为2时,k为7、5和6;n为3时,k为5和4;n为4时,k为4和3;
若所述上下行配置信息对应的配置编号为4,则n为2时,k为8、7、5和6;n为3时,k为5、4、3和2;
若所述上下行配置信息对应的配置编号为5,则n为2时,k为9、8、7、5、4、3、2、11和6;
若所述上下行配置信息对应的配置编号为6,则n为2、3或4时,k为3;n为7或8时,k为2。
4.如权利要求1所述的方法,其特征在于,还包括:
根据确定的处理能力以及所述UE的上下行配置信息,确定所述UE对所述下行数据进行反馈时的最大混合自动重传请求HARQ进程数。
5.如权利要求4所述的方法,其特征在于,根据确定的处理能力以及所述UE的上下行配置信息,确定所述UE对所述下行数据进行反馈时的最大HARQ进程数,包括:
当所述处理能力对应的处理时长为2个子帧时,若所述上下行配置信息对应的配置编号为0,则所述最大HARQ进程数为3;若所述配置编号为1,则所述最大HARQ进程数为5;若所述配置编号为2,则所述最大HARQ进程数为8;若所述配置编号为3,则所述最大HARQ进程数为7;若所述配置编号为4,则所述最大HARQ进程数为10;若所述配置编号为5,则所述最大HARQ进程数为13;若所述配置编号为6,则所述最大HARQ进程数为5。
6.如权利要求4所述的方法,其特征在于,根据确定的处理能力以及所述UE的上下行配置信息,确定所述UE对所述下行数据进行反馈时的最大HARQ进程数,包括:
当所述处理能力对应的处理时长为1个子帧时,若所述上下行配置信息对应的配置编号为0,则所述最大HARQ进程数为2;若所述配置编号为1,则所述最大HARQ进程数为3;若所述配置编号为2,则所述最大HARQ进程数为6;若所述配置编号为3,则所述最大HARQ进程数为7;若所述配置编号为4,则所述最大HARQ进程数为8;若所述配置编号为5,则所述最大HARQ进程数为12;若所述配置编号为6,则所述最大HARQ进程数为5。
7.如权利要求1所述的方法,其特征在于,确定所述UE对所述下行数据进行反馈的反馈时序信息之后,还包括:
若在配置编号为L的上下行配置方式下,在上行子帧n中对在子帧n-k+10β接收的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0,L为非负整数,则
在子帧n-k+10β中,确定与第三反馈时序信息所指示的子帧相同的第一子帧;其中,所述第三反馈时序信息所指示的子帧是指在针对处理时长为3个子帧的UE所设计的反馈时序中,在配置编号为L的上下行配置方式下,在上行子帧n中发送的反馈信息所对应的发送下行数据的子帧;
针对确定的所述第一子帧,与所述处理时长为3个子帧的UE共享发送反馈信息的物理上行链路控制信道PUCCH隐式资源;
针对子帧n-k+10β中除确定的所述第一子帧以外的任一子帧,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
8.如权利要求7所述的方法,其特征在于,针对子帧n-k+10β中除确定的所述第一子帧以外的任一子帧,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源,包括:
针对子帧n-k+10β中除确定的所述第一子帧以外的任一子帧,确定高层信令指示的所述PUCCH隐式资源的起始点,并根据所述起始点和在该任一子帧中进行物理下行链路控制信道PDCCH传输所使用的第一个控制信道单元CCE的索引号,确定用于发送反馈信息的PUCCH隐式资源;其中,所述起始点,与所述处理时长为3个子帧的UE发送反馈信息的PUCCH隐式资源的起始点不同,当n<k时,β为1,当n≥k时,β为0,L为非负整数。
9.一种对下行数据进行反馈的装置,其特征在于,包括:
处理模块,用于确定用户设备UE的处理能力,所述处理能力是指所述UE对接收的下行数据进行处理以确定是否需要重传所耗费的处理时长;
反馈模块,用于若所述处理能力对应的处理时长小于3个子帧,确定所述UE对所述下行数据进行反馈的第二反馈时序信息,其中,所述UE在第二反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长,小于在第一反馈时序信息所指示的反馈时序下对接收的下行数据进行反馈的最短时长;具体包括:
若所述处理能力对应的处理时长为2个子帧,确定在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0;其中:
若上下行配置信息对应的配置编号为0,则n为3、4、8或9时,k为3;
若所述上下行配置信息对应的配置编号为1,则n为2或7时,k为3和6;n为3或8时,k为3;
若所述上下行配置信息对应的配置编号为2,则n为2或7时,k为7、4、3和6;
若所述上下行配置信息对应的配置编号为3,则n为2时,k为7、5和6;n为3时,k为5和4;n为4时,k为4和3;
若所述上下行配置信息对应的配置编号为4,则n为2时,k为8、7、6和11;n为3时,k为6、5、4和3;
若所述上下行配置信息对应的配置编号为5,则n为2时,k为12、9、8、7、5、4、3、11和6;
若所述上下行配置信息对应的配置编号为6,则n为2或7时,k为6;n为3或4时,k为4;n为8时,k为3。
10.如权利要求9所述的装置,其特征在于,所述反馈模块,具体用于:
若所述处理能力对应的处理时长为3个子帧,确定所述UE对所述下行数据进行反馈的第一反馈时序信息,该第一反馈时序信息为第三代合作伙伴计划长期演进发行第13版3GPPLTE Rel-13及之前版本的协议中所定义的反馈时序信息。
11.如权利要求9所述的装置,其特征在于,所述反馈模块,具体用于:
若所述处理能力对应的处理时长为1个子帧,确定在上行子帧n中对在子帧n-k+10β接收到的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0;其中:
若上下行配置信息对应的配置编号为0,则n为2、3、7或8时,k为2;
若所述上下行配置信息对应的配置编号为1,则n为2或7时,k为3和2;n为3或8时,k为2;
若所述上下行配置信息对应的配置编号为2,则n为2或7时,k为4、3、2和6;
若所述上下行配置信息对应的配置编号为3,则n为2时,k为7、5和6;n为3时,k为5和4;n为4时,k为4和3;
若所述上下行配置信息对应的配置编号为4,则n为2时,k为8、7、5和6;n为3时,k为5、4、3和2;
若所述上下行配置信息对应的配置编号为5,则n为2时,k为9、8、7、5、4、3、2、11和6;
若所述上下行配置信息对应的配置编号为6,则n为2、3或4时,k为3;n为7或8时,k为2。
12.如权利要求9所述的装置,其特征在于,还包括:
进程数确定模块,用于根据确定的处理能力以及所述UE的上下行配置信息,确定所述UE对所述下行数据进行反馈时的最大混合自动重传请求HARQ进程数。
13.如权利要求12所述的装置,其特征在于,所述进程数确定模块,具体用于:
当所述处理能力对应的处理时长为2个子帧时,若所述上下行配置信息对应的配置编号为0,则所述最大HARQ进程数为3;若所述配置编号为1,则所述最大HARQ进程数为5;若所述配置编号为2,则所述最大HARQ进程数为8;若所述配置编号为3,则所述最大HARQ进程数为7;若所述配置编号为4,则所述最大HARQ进程数为10;若所述配置编号为5,则所述最大HARQ进程数为13;若所述配置编号为6,则所述最大HARQ进程数为5。
14.如权利要求12所述的装置,其特征在于,所述进程数确定模块,具体用于:
当所述处理能力对应的处理时长为1个子帧时,若所述上下行配置信息对应的配置编号为0,则所述最大HARQ进程数为2;若所述配置编号为1,则所述最大HARQ进程数为3;若所述配置编号为2,则所述最大HARQ进程数为6;若所述配置编号为3,则所述最大HARQ进程数为7;若所述配置编号为4,则所述最大HARQ进程数为8;若所述配置编号为5,则所述最大HARQ进程数为12;若所述配置编号为6,则所述最大HARQ进程数为5。
15.如权利要求9所述的装置,其特征在于,还包括:
资源确定模块,用于若在配置编号为L的上下行配置方式下,在上行子帧n中对在子帧n-k+10β接收的下行数据进行反馈,当n<k时,β为1,当n≥k时,β为0,L为非负整数,则
在子帧n-k+10β中,确定与第三反馈时序信息所指示的子帧相同的第一子帧;其中,所述第三反馈时序信息所指示的子帧是指在针对处理时长为3个子帧的UE所设计的反馈时序中,在配置编号为L的上下行配置方式下,在上行子帧n中发送的反馈信息所对应的发送下行数据的子帧;
针对确定的所述第一子帧,与所述处理时长为3个子帧的UE共享发送反馈信息的物理上行链路控制信道PUCCH隐式资源;
针对子帧n-k+10β中除确定的所述第一子帧以外的任一子帧,确定高层信令指示的用于发送反馈信息的PUCCH隐式资源,或者,根据预定义的规则确定用于发送反馈信息的PUCCH隐式资源。
16.如权利要求15所述的装置,其特征在于,所述资源确定模块,具体用于:
针对子帧n-k+10β中除确定的所述第一子帧以外的任一子帧,确定高层信令指示的所述PUCCH隐式资源的起始点,并根据所述起始点和在该任一子帧中进行物理下行链路控制信道PDCCH传输所使用的第一个控制信道单元CCE的索引号,确定用于发送反馈信息的PUCCH隐式资源;其中,所述起始点,与所述处理时长为3个子帧的UE发送反馈信息的PUCCH隐式资源的起始点不同,当n<k时,β为1,当n≥k时,β为0,L为非负整数。
CN201610665878.6A 2016-08-12 2016-08-12 一种对下行数据进行反馈的方法及装置 Active CN107733578B (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
CN201610665878.6A CN107733578B (zh) 2016-08-12 2016-08-12 一种对下行数据进行反馈的方法及装置
KR1020197007225A KR102197444B1 (ko) 2016-08-12 2017-05-27 다운 링크 데이터에 대한 피드백을 위한 방법 및 장치
JP2019507261A JP6756901B2 (ja) 2016-08-12 2017-05-27 ダウンリンクデータをフィードバックする方法及び装置
US16/325,178 US10911205B2 (en) 2016-08-12 2017-05-27 Method and device for feeding back downlink data
EP17838410.3A EP3499764A4 (en) 2016-08-12 2017-05-27 METHOD AND DEVICE FOR RECOVERING DOWNLINK DATA
PCT/CN2017/086271 WO2018028278A1 (zh) 2016-08-12 2017-05-27 一种对下行数据进行反馈的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610665878.6A CN107733578B (zh) 2016-08-12 2016-08-12 一种对下行数据进行反馈的方法及装置

Publications (2)

Publication Number Publication Date
CN107733578A CN107733578A (zh) 2018-02-23
CN107733578B true CN107733578B (zh) 2020-03-24

Family

ID=61162685

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610665878.6A Active CN107733578B (zh) 2016-08-12 2016-08-12 一种对下行数据进行反馈的方法及装置

Country Status (6)

Country Link
US (1) US10911205B2 (zh)
EP (1) EP3499764A4 (zh)
JP (1) JP6756901B2 (zh)
KR (1) KR102197444B1 (zh)
CN (1) CN107733578B (zh)
WO (1) WO2018028278A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3480988B1 (en) 2016-08-21 2022-05-25 LG Electronics Inc. Method for uplink transmission in wireless communication system, and device therefor
AU2016424838B2 (en) * 2016-09-28 2020-09-10 Huawei Technologies Co., Ltd. Method for feeding back ack/nack information for downlink data and related device
CN110392392B (zh) 2018-04-16 2021-07-09 华为技术有限公司 通信方法、通信装置及可读存储介质
EP3868163A4 (en) * 2018-10-16 2022-05-18 Lenovo (Beijing) Limited METHOD AND APPARATUS FOR TRANSMITTING FEEDBACK CORRESPONDING TO TRANSPORT BLOCKS
WO2023193219A1 (en) * 2022-04-08 2023-10-12 Qualcomm Incorporated Wireless communications feedback

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102326353A (zh) * 2009-02-19 2012-01-18 三星电子株式会社 用于在无线移动通信系统中执行混合自动重传请求操作的方法
CN102752089A (zh) * 2011-04-22 2012-10-24 北京三星通信技术研究有限公司 反馈ack/nack的方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101400081B (zh) 2007-09-28 2010-06-02 大唐移动通信设备有限公司 Tdd系统中的上行资源调度方法、系统及设备
KR101737749B1 (ko) * 2008-04-21 2017-05-18 애플 인크. Harq 프로토콜을 위한 방법 및 시스템
US20130121216A1 (en) * 2011-11-11 2013-05-16 Qualcomm Incorporated Method and apparatus for soft buffer management for harq operation
US8848591B2 (en) 2012-02-27 2014-09-30 Futurewei Technologies, Inc. System and method for message acknowledgment feedback for device-to-device communication overlaid on a cellular network
US20150085720A1 (en) 2013-09-26 2015-03-26 Qualcomm Incorporated Reduced delay harq process timeline for fdd-tdd carrier aggregation
CN105393485B (zh) 2013-09-27 2019-12-06 华为技术有限公司 无线通信系统中的方法和节点
CN105580307A (zh) * 2014-05-15 2016-05-11 华为技术有限公司 数据传输装置和方法
US20160205540A1 (en) 2015-01-09 2016-07-14 Htc Corporation Methods of handling wireless communications for communication system
CN105323857A (zh) 2015-11-12 2016-02-10 深圳市金立通信设备有限公司 一种harq信息配置的方法及相关设备

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102326353A (zh) * 2009-02-19 2012-01-18 三星电子株式会社 用于在无线移动通信系统中执行混合自动重传请求操作的方法
CN102752089A (zh) * 2011-04-22 2012-10-24 北京三星通信技术研究有限公司 反馈ack/nack的方法

Also Published As

Publication number Publication date
JP6756901B2 (ja) 2020-09-16
WO2018028278A1 (zh) 2018-02-15
EP3499764A4 (en) 2019-11-27
JP2019528618A (ja) 2019-10-10
EP3499764A1 (en) 2019-06-19
KR102197444B1 (ko) 2020-12-31
US10911205B2 (en) 2021-02-02
KR20190034672A (ko) 2019-04-02
US20190190680A1 (en) 2019-06-20
CN107733578A (zh) 2018-02-23

Similar Documents

Publication Publication Date Title
US11533741B2 (en) Uplink transmission method, terminal, and network side device
JP6720371B2 (ja) キャリアアグリゲーションベースの無線通信システムにおける通信方法(communication method in wireless communication system on basis of carrier aggregation)
JP6561130B2 (ja) ハイブリッド自動再送要求−肯定応答伝送方法及び装置
CN107733578B (zh) 一种对下行数据进行反馈的方法及装置
CN106804116B (zh) 一种反馈信息的传输方法和基站以及用户设备
CN109075906A (zh) 传输数据的方法和装置
CN108347782B (zh) 一种上行控制信息发送、接收方法、终端及基站
EP3331305B1 (en) Uplink data transmission method and device
KR20200097342A (ko) 정보 처리 방법, 장치 및 기기
US10779284B2 (en) Data transmission method, user equipment, and base station
US20160329994A1 (en) Method and device for response information transmission, terminal, base station and storage medium
US20220369296A1 (en) Method and apparatus for transmitting downlink control information
US20190207718A1 (en) Information transmission method and device
CN110719150B (zh) 一种信息传输方法、终端及基站
CN104348582A (zh) 用于传输控制信息的方法和设备
CN110100494B (zh) 一种数据传输的方法及设备
CN109905212B (zh) 混合自动重传请求时序关系的指示方法、基站及用户设备
CN108352942A (zh) 信息传输的方法、终端和基站
WO2019109687A1 (zh) 一种ack/nack传输方法及对应装置
US11057104B2 (en) Information transmission method and apparatus
CN112351495A (zh) Uci的传输方法、装置、终端及基站
CN110663209A (zh) 反馈应答信息的传输方法、装置及系统
US20190223042A1 (en) Data transmission method and device
CN110574320A (zh) 一种针对eMTC的HARQ反馈方法及终端设备
CN105071903A (zh) 一种反馈信息的确认方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
CP01 Change in the name or title of a patent holder
CP01 Change in the name or title of a patent holder

Address after: 100191 No. 40, Haidian District, Beijing, Xueyuan Road

Patentee after: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY

Address before: 100191 No. 40, Haidian District, Beijing, Xueyuan Road

Patentee before: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20210527

Address after: 100085 1st floor, building 1, yard 5, Shangdi East Road, Haidian District, Beijing

Patentee after: DATANG MOBILE COMMUNICATIONS EQUIPMENT Co.,Ltd.

Address before: 100191 No. 40, Haidian District, Beijing, Xueyuan Road

Patentee before: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY