CN112020151B - 一种数据传输方法及装置 - Google Patents

一种数据传输方法及装置 Download PDF

Info

Publication number
CN112020151B
CN112020151B CN201910472058.9A CN201910472058A CN112020151B CN 112020151 B CN112020151 B CN 112020151B CN 201910472058 A CN201910472058 A CN 201910472058A CN 112020151 B CN112020151 B CN 112020151B
Authority
CN
China
Prior art keywords
transmission
equal
service
less
scenario
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
CN201910472058.9A
Other languages
English (en)
Other versions
CN112020151A (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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201910472058.9A priority Critical patent/CN112020151B/zh
Priority to PCT/CN2020/090306 priority patent/WO2020238638A1/zh
Publication of CN112020151A publication Critical patent/CN112020151A/zh
Application granted granted Critical
Publication of CN112020151B publication Critical patent/CN112020151B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • 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
    • 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/1607—Details of the supervisory signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling

Landscapes

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

Abstract

本申请实施例提供一种数据传输方法及装置，其中方法包括：网络侧设备根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的传输模式；所述网络侧设备根据所述传输模式向终端侧设备传输所述URLLC业务的业务数据。通过本申请实施例提供的方法，URLLC业务的业务数据的传输模式，是根据URLLC业务的业务应用场景确定的，终端侧设备从而可以实时确定URLLC业务的业务数据的传输模式，同时终端侧设备不必通过DCI确定传输模式，节省了信令开销，并提高传输效率。

Description

一种数据传输方法及装置
技术领域
本申请涉及通信技术领域，尤其涉及一种数据传输方法及装置。
背景技术
第五代(the fifth generation，5G)移动网络期望通过一个网络同时支持多种多样的场景和业务。多种多样的场景包括远程驾驶、智慧城市、智能电网、智能工厂等；多种多样的业务包括增强移动宽带(enhanced mobile broadband，eMBB)业务、超高可靠低时延(ultra-high reliability and low latency，URLLC)业务和大规模机器类通信(massivemachine-type communication，mMTC)业务等。其中，URLLC业务指的是高可靠和低时延连接的业务。为了实现在低时延要求下的高可靠性，URLLC业务的下行数据是通过物理下行共享信道(physical downlink shared channel，PDSCH)发送的。网络侧设备发送PDSCH时，在向终端侧设备发送的下行控制信息(downlink control information，DCI)里增加了重复次数指示信息，用于指示PDSCH重复传输次数。由于PDSCH能够重复传输多次，所以可以满足URLLC业务对高可靠和低时延的要求。然而，这种做法，增加了DCI的开销，且PDSCH多次重复传输，若终端设备能在PDSCH第一次传输时就能正确解调PDSCH，则后面的几次重复传输PDSCH所占的资源就被浪费了，从而降低了系统的频谱效率。同样的问题也存在于上行传输，在上行传输中，终端侧设备也需要按照网络侧设备的指示，向网络侧设备重复传输多次数据。
为此，在URLLC业务各种应用场景下，如果高效的进行数据传输，是一个亟待解决的问题。
发明内容
本申请实施例提供一种数据传输方法及装置，用以解决在URLLC业务场景下，如何提高数据传输的效率的问题。
第一方面，本申请实施例提供一种数据传输方法，该方法包括：终端侧设备根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，所述终端侧设备接收来自网络侧设备的第一信息，所述第一信息用于指示所述第一传输模式；所述终端侧设备根据所述第一传输模式接收来自网络侧设备传输的所述URLLC业务的业务数据。
通过上述方法，URLLC业务的业务数据的传输模式，是根据URLLC业务的业务应用场景确定的，终端侧设备从而可以实时确定URLLC业务的业务数据的传输模式，同时终端侧设备不必通过DCI确定传输模式，节省了信令开销，并提高传输效率。
在一种可能的设计中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于0的整数。
在一种可能的设计中，所述URLLC业务的业务应用场景为第一场景时，对应的第一传输模式为所述方式一，所述第一场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第二场景时，第一传输模式为所述方式二，所述第二场景中传输的数据满足以下条件：空口时延小于或等于7ms，上行数据包大小小于或等于250比特，下行数据包大小小于或等于250比特；
或者，所述URLLC业务的业务应用场景为第三场景时，第一传输模式为所述方式一，所述第三场景中传输的数据满足以下条件：空口时延小于或等于1ms，上行数据包大小小于或等于32比特，下行数据包大小小于或等于32比特；
或者，所述URLLC业务的业务应用场景为第四场景时，第一传输模式为所述方式一，所述第四场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第五场景时，第一传输模式为所述方式二，所述第五场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于10000比特，下行数据包大小小于或等于4096比特；
或者，所述URLLC业务的业务应用场景为第六场景时，第一传输模式为所述方式三，所述第六场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于2083比特，下行数据包大小小于或等于5220比特；
或者，所述URLLC业务的业务应用场景为第七场景时，第一传输模式为所述方式二，所述第七场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于1370比特，下行数据包大小小于或等于1370比特。
通过上述方法，通过预先定义传输模式与业务应用场景的对应关系，可以实现根据业务应用场景确定传输模式，提高传输效率。
在一种可能的设计中，所述方法还包括：所述终端侧设备接收来自所述网络侧设备的第二信息，所述第二信息用于指示所述业务数据的信道编码的码率；所述终端侧设备根据所述码率确定所述业务数据的基础图类型，并根据所述码率以及所述基础图类型确定所述业务数据在冗余版本传输时的冗余版本；或者，所述终端侧设备接收来自所述网络侧设备的第三信息，所述第三信息用于指示所述业务数据在冗余版本传输时的冗余版本。
通过上述方法，冗余版本是通过码率以及基础图类型确定的，从而不需要提高信令指示冗余版本，从而节省了信令开销，并提高传输效率。
第二方面，本申请实施例提供一种数据传输方法，包括：网络侧设备根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；所述网络侧设备根据所述第一传输模式向终端侧设备传输所述URLLC业务的业务数据。
通过上述方法，URLLC业务的业务数据的传输模式，是根据URLLC业务的业务应用场景确定的，网络侧设备不必通过DCI向终端侧设备指示传输模式，节省了信令开销，并提高传输效率。
在一种可能的设计中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于或等于0的整数。
在一种可能的设计中，所述URLLC业务的业务应用场景为第一场景时，对应的第一传输模式为所述方式一，所述第一场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第二场景时，第一传输模式为所述方式二，所述第二场景中传输的数据满足以下条件：空口时延小于或等于7ms，上行数据包大小小于或等于250比特，下行数据包大小小于或等于250比特；
或者，所述URLLC业务的业务应用场景为第三场景时，第一传输模式为所述方式一，所述第三场景中传输的数据满足以下条件：空口时延小于或等于1ms，上行数据包大小小于或等于32比特，下行数据包大小小于或等于32比特；
或者，所述URLLC业务的业务应用场景为第四场景时，第一传输模式为所述方式一，所述第四场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第五场景时，第一传输模式为所述方式二，所述第五场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于10000比特，下行数据包大小小于或等于4096比特；
或者，所述URLLC业务的业务应用场景为第六场景时，第一传输模式为所述方式三，所述第六场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于2083比特，下行数据包大小小于或等于5220比特；
或者，所述URLLC业务的业务应用场景为第七场景时，第一传输模式为所述方式二，所述第七场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于1370比特，下行数据包大小小于或等于1370比特。
通过上述方法，通过预先定义传输模式与业务应用场景的对应关系，可以实现根据业务应用场景确定传输模式，提高传输效率。
在一种可能的设计中，所述方法还包括：所述网络侧设备确定根据所述第一传输模式传输所述URLLC业务的业务数据的误块率BLER；当所述BLER大于第一预设阈值时，所述网络侧设备切换至第二传输模式向所述终端侧设备传输所述URLLC业务的业务数据；
其中，所述第二传输模式中，首次传输包括的初传的冗余版本传输次数大于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数，和/或，所述第二传输模式中，重新传输包括的重传的冗余版本传输次数大于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
上述方法中，第二传输模式中，首次传输包括的初传的冗余版本传输次数以及重新传输包括的重传的冗余版本传输次数较高，从而能够提供较高的传输可靠性。
在一种可能的设计中，所述方法还包括：当所述bler小于或等于第二预设阈值时，所述网络侧设备切换至第三传输模式向所述终端侧设备传输所述URLLC业务的业务数据；其中，所述第三传输模式中，首次传输包括的初传的冗余版本传输次数小于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数，和/或，所述第三传输模式中，重新传输包括的重传的冗余版本传输次数小于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
上述方法中，第三传输模式中，首次传输包括的初传的冗余版本传输次数以及重新传输包括的重传的冗余版本传输次数较少，从而能够降低资源开销，提高资源利用率。
在一种可能的设计中，所述方法还包括：所述网络侧设备向所述终端侧设备发送第三信息，所述第三信息用于指示所述第一传输模式。
在一种可能的设计中，所述方法还包括：所述网络侧设备向所述终端侧设备发送第二信息，所述第二信息用于指示所述业务数据的信道编码的码率；所述码率用于确定所述业务数据在冗余版本传输时的冗余版本；
或者，所述网络侧设备向所述终端侧设备发送第三信息，所述第三信息用于指示所述业务数据在冗余版本传输时的冗余版本。
通过上述方法，冗余版本是通过码率以及基础图类型确定的，从而不需要提高信令指示冗余版本，从而节省了信令开销，并提高传输效率。
第三方面，本申请实施例提供一种数据传输方法，包括：终端侧设备根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，所述终端侧设备接收来自网络侧设备的第四信息，所述第四信息用于指示所述第一传输模式；所述终端侧设备根据所述第一传输模式向网络侧设备传输所述URLLC业务的业务数据。
通过上述方法，URLLC业务的业务数据的传输模式，是根据URLLC业务的业务应用场景确定的，终端侧设备从而可以实时确定URLLC业务的业务数据的传输模式，同时终端侧设备不必通过DCI确定传输模式，节省了信令开销，并提高传输效率。
在一种可能的设计中，所述终端侧设备根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式之后，所述方法还包括：所述终端侧设备向所述网络侧设备发送第五信息，所述第五信息用于指示所述第一传输模式。
在一种可能的设计中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于或等于0的整数。
在一种可能的设计中，所述URLLC业务的业务应用场景为第一场景时，对应的第一传输模式为所述方式一，所述第一场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第二场景时，第一传输模式为所述方式二，所述第二场景中传输的数据满足以下条件：空口时延小于或等于7ms，上行数据包大小小于或等于250比特，下行数据包大小小于或等于250比特；
或者，所述URLLC业务的业务应用场景为第三场景时，第一传输模式为所述方式一，所述第三场景中传输的数据满足以下条件：空口时延小于或等于1ms，上行数据包大小小于或等于32比特，下行数据包大小小于或等于32比特；
或者，所述URLLC业务的业务应用场景为第四场景时，第一传输模式为所述方式一，所述第四场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第五场景时，第一传输模式为所述方式二，所述第五场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于10000比特，下行数据包大小小于或等于4096比特；
或者，所述URLLC业务的业务应用场景为第六场景时，第一传输模式为所述方式三，所述第六场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于2083比特，下行数据包大小小于或等于5220比特；
或者，所述URLLC业务的业务应用场景为第七场景时，第一传输模式为所述方式二，所述第七场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于1370比特，下行数据包大小小于或等于1370比特。
通过上述方法，通过预先定义传输模式与业务应用场景的对应关系，可以实现根据业务应用场景确定传输模式，提高传输效率。
第四方面，本申请实施例提供一种数据传输方法，包括：网络侧设备根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，所述网络侧设备接收来自终端侧设备的第五信息，所述第五信息用于指示所述第一传输模式；
网络侧设备根据所述第一传输模式接收来自终端侧设备的所述URLLC业务的业务数据。
通过上述方法，URLLC业务的业务数据的传输模式，是根据URLLC业务的业务应用场景确定的，网络侧设备不必通过DCI向终端侧设备指示传输模式，节省了信令开销，并提高传输效率。
在一种可能的设计中，所述网络侧设备根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式之后，所述方法还包括：
所述网络侧设备向所述终端侧设备发送第四信息，所述第四信息用于指示所述第一传输模式。
在一种可能的设计中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于或等于0的整数。
在一种可能的设计中，所述URLLC业务的业务应用场景为第一场景时，对应的第一传输模式为所述方式一，所述第一场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第二场景时，第一传输模式为所述方式二，所述第二场景中传输的数据满足以下条件：空口时延小于或等于7ms，上行数据包大小小于或等于250比特，下行数据包大小小于或等于250比特；
或者，所述URLLC业务的业务应用场景为第三场景时，第一传输模式为所述方式一，所述第三场景中传输的数据满足以下条件：空口时延小于或等于1ms，上行数据包大小小于或等于32比特，下行数据包大小小于或等于32比特；
或者，所述URLLC业务的业务应用场景为第四场景时，第一传输模式为所述方式一，所述第四场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第五场景时，第一传输模式为所述方式二，所述第五场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于10000比特，下行数据包大小小于或等于4096比特；
或者，所述URLLC业务的业务应用场景为第六场景时，第一传输模式为所述方式三，所述第六场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于2083比特，下行数据包大小小于或等于5220比特；
或者，所述URLLC业务的业务应用场景为第七场景时，第一传输模式为所述方式二，所述第七场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于1370比特，下行数据包大小小于或等于1370比特。
通过上述方法，通过预先定义传输模式与业务应用场景的对应关系，可以实现根据业务应用场景确定传输模式，提高传输效率。
第五方面，本申请提供一种装置。所述装置具备实现上述第一方面或第三方面涉及的终端侧设备的功能，比如，所述装置包括所述终端侧设备执行上述第一方面或第三方面涉及步骤所对应的模块或单元或手段(means)，所述功能或单元或手段(means)可以通过软件实现，或者通过硬件实现，也可以通过硬件执行相应的软件实现。
在一种可能的设计中，所述装置包括处理单元、收发单元，处理单元、收发单元执行的功能可以和上述第一方面或第三方面涉及的终端侧设备执行的步骤相对应。
在一种可能的设计中，所述装置包括处理器，还可以包括收发器，所述收发器用于收发信号，所述处理器执行程序指令，以完成上述第一方面或第三方面中任意可能的设计或实现方式中终端侧设备执行的方法。
其中，所述装置还可以包括一个或多个存储器，所述存储器用于与处理器耦合。所述一个或多个存储器可以和处理器集成在一起，也可以与处理器分离设置，本申请并不限定。
一种可能的方式，存储器保存实现上述第一方面或第三方面涉及的终端侧设备的功能的必要计算机程序指令和/或数据。所述处理器可执行所述存储器存储的计算机程序指令，完成上述第一方面或第三方面任意可能的设计或实现方式中终端侧设备执行的方法。
第六方面，本申请提供一种装置。所述装置具备实现上述第二方面或第四方面涉及的网络侧设备的功能，比如，所述装置包括所述网络侧设备执行上述第二方面或第四方面涉及步骤所对应的模块或单元或手段(means)。所述功能或单元或手段(means)可以通过软件实现，或者通过硬件实现，也可以通过硬件执行相应的软件实现。
在一种可能的设计中，所述装置包括处理单元、收发单元，处理单元、收发单元执行的功能可以和上述第二方面或第四方面中任意可能的设计或实现方式中涉及的网络侧设备执行的步骤相对应。
在另一种可能的设计中，所述通信装置包括处理器，还可以包括收发器，所述收发器用于收发信号，所述处理器执行程序指令，以完成上述第二方面或第四方面中任意可能的设计或实现方式中网络侧设备执行的方法。
其中，所述装置还可以包括一个或多个存储器，所述存储器用于与处理器耦合。所述一个或多个存储器可以和处理器集成在一起，也可以与处理器分离设置，本申请并不限定。
一种可能的方式，存储器保存实现上述第二方面或第四方面中任意可能的设计或实现方式中涉及的网络侧设备的功能的必要计算机程序指令和/或数据。所述处理器可执行所述存储器存储的计算机程序指令，完成上述第二方面或第四方面中任意可能的设计或实现方式中网络侧设备执行的方法。
第七方面，本申请实施例提供一种计算机可读存储介质，所述计算机存储介质中存储有计算机可读指令，当计算机读取并执行所述计算机可读指令时，使得计算机执行上述任一种可能的设计中的方法。
第八方面，本申请实施例提供一种计算机程序产品，当计算机读取并执行所述计算机程序产品时，使得计算机执行上述任一种可能的设计中的方法。可选的，所述计算机可以为上述网络侧设备或终端侧设备。
第九方面，本申请实施例提供一种芯片，所述芯片与存储器相连，用于读取并执行所述存储器中存储的软件程序，以实现上述任一种可能的设计中的方法。可选的，所述芯片可以为上述网络侧设备中的芯片或上述终端侧设备中的芯片。
第十方面，本申请实施例提供一种通信系统，包括第一方面中的终端侧设备以及第二方面中的网络侧设备，或者包括第三方面中的终端侧设备以及第四方面中的网络侧设备。
附图说明
图1示出了适用于本申请实施例的通信方法的通信系统的示意图；
图2为本申请实施例提供的一种数据传输方法流程示意图；
图3为本申请实施例提供的一种冗余版本示意图；
图4为本申请实施例提供的一种数据传输方法流程示意图；
图5为本申请实施例提供的一种数据传输装置结构示意图；
图6为本申请实施例提供的一种数据传输装置结构示意图；
图7为本申请实施例提供的一种数据传输装置结构示意图；
图8为本申请实施例提供的一种数据传输装置结构示意图。
具体实施方式
下面结合说明书附图对本申请实施例做详细描述。
本申请实施例可以应用于各种移动通信系统，例如：新无线(new radio，NR)系统、长期演进(long term evolution，LTE)系统、先进的长期演进(advanced long termevolution，LTE-A)系统、演进的长期演进(evolved long term evolution，eLTE)系统、未来通信系统等其它通信系统，具体的，在此不做限制。
为便于理解本申请实施例，首先以图1中示出的通信系统为例详细说明适用于本申请实施例的通信系统。图1示出了适用于本申请实施例的通信方法的通信系统的示意图。如图1所示，该通信系统包括网络侧设备，以及与网络侧设备连接的终端侧设备1～终端侧设备4。
举例来说，终端侧设备1为交通设备，例如火车，此时网络侧设备与终端侧设备1之间可以传输和交通状况有关的数据。终端侧设备2为电力设备，例如电表，此时网络侧设备与终端侧设备2之间可以传输配电网的电压、电流等数据，其它情况不再赘述。
在本申请实施例中，终端侧设备，为具有无线收发功能的设备或可设置于该设备的芯片。在实际应用中，本申请的实施例中的终端侧设备可以是手机(mobile phone)、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(virtual reality，VR)终端、增强现实(augmented reality，AR)终端、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。本申请的实施例对应用场景不做限定。本申请中将前述具有无线收发功能的设备及可设置于该设备中的芯片统称为终端侧设备。
在本申请实施例中，网络侧设备可以为各种制式下无线接入设备，例如演进型节点B(evolved Node B，eNB)、无线网络控制器(radio network controller，RNC)或节点B(Node B，NB)、家庭基站(例如，home evolved NodeB，或home Node B，HNB)、基带单元(baseband unit，BBU)，无线保真(wireless fidelity，WIFI)系统中的接入点(accesspoint，AP)、无线中继节点、传输点(transmission and reception point，TRP或者transmission point，TP)等，还可以为5G(NR)系统中的gNB或传输点(TRP或TP)，5G系统中的基站的一个或一组(包括多个天线面板)天线面板，或者，还可以为构成gNB或传输点的网络节点等。
本申请实施例描述的网络架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
参见图2，为本申请实施例提供的一种数据传输方法流程示意图。图2所示的流程描述了在下行传输时，如何确定传输模式，具体的，该方法包括：
步骤201：网络侧设备根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式。
步骤202：网络侧设备根据所述第一传输模式向终端侧设备传输所述URLLC业务的业务数据。
步骤203：终端侧设备可以根据所述URLLC业务的业务应用场景确定与所述业务应用场景对应的所述第一传输模式。
另一种可能的实现方式中，所述终端侧设备还可以接收来自网络侧设备的第一信息，所述第一信息用于指示所述第一传输模式。所述终端侧设备可以根据第一信息确定第一传输模式。
步骤204：终端侧设备根据所述第一传输模式接收来自网络侧设备传输的所述URLLC业务的业务数据。
通过上述方法，URLLC业务的业务数据的传输模式，是根据URLLC业务的业务应用场景确定的，从而可以实时确定业务数据的传输模式，同时终端侧设备也可以根据URLLC业务的业务应用场景确定业务数据的传输模式，从而不必通过DCI指示传输模式，节省了信令开销，并提高传输效率。
步骤201中，可以预先约定业务应用场景与传输模式的对应关系，当网络侧设备确定向终端侧设备传输URLLC业务的业务数据时，网络侧设备可以将该URLLC业务的业务应用场景对应的第一传输模式作为传输业务数据所采用的传输模式。
需要说明的是，URLLC业务是低时延、高可靠连接的业务，现有技术中给出了几种URLLC业务的业务应用场景对应的可靠性以及时延要求，具体可以参考表1所示。
表1
Figure GDA0003489744490000091
其中，空口时延可以是指网络侧设备的层二到终端侧设备的层二之间的信号时延。层二可以包括媒体接入控制(medium access control，MAC)层、无线链路控制(radiolink control，RLC)层、分组数据汇聚协议(packet data convergence protocol，PDCP)层、业务数据应用协议(service data adaptation protocol，SDAP)层等。
表1中，不同可靠性以及时延对应的业务应用场景的名称只是示例，例如远程驾驶，也可以称为无人驾驶、自动驾驶等，为描述方便，本申请实施例中均称为远程驾驶。本申请实施例对业务应用场景的名称并不限定。如果两个业务应用场景的可靠性、时延以及数据包大小等要求相同，可以认为实质上是两个相同的业务应用场景。
示例性的，预先约定的业务应用场景与传输模式的对应关系可能存在多种实现方式，本申请实施例对此并不限定。举例来说，结合表1，当业务应用场景为配电网故障管理时，所述业务应用场景对应的第一传输模式可以为方式一；
当业务应用场景为差分保护时，所述业务应用场景对应的第一传输模式可以为方式二；
当业务应用场景为自动化控制时，所述业务应用场景对应的第一传输模式可以为方式一；
当业务应用场景为小数据包数据传输时，所述业务应用场景对应的第一传输模式可以为方式一；
当业务应用场景为大数据包数据传输时，所述业务应用场景对应的第一传输模式可以为方式二；
当业务应用场景为远程驾驶时，所述业务应用场景对应的第一传输模式可以为方式三；
当业务应用场景为智能交通系统时，所述业务应用场景对应的第一传输模式可以为方式二。
其中，方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数。
方式一中，冗余版本传输的次数较多，适用于干扰情况严重，可靠性要求高的业务应用场景。
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输。
方式二中，初传只需要传输1次，适用于数据包较大且对时延要求不高的业务应用场景。
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于或等于0的整数。
当然以上只是示例，业务应用场景与传输模式的对应关系还可能存在其他实现方式，在此不再逐一举例说明。同样的，传输模式也可以存在其他实现模式，在此不再逐一举例说明。
在方式一至方式三中，为了提高数据传输的可靠性，会进行初传或重传的冗余版本传输。冗余版本传输时，是根据冗余版本(redundancy version，RV)，确定传输数据的起始位置的。目前，URLLC业务的业务数据是按照传输块(transport block，TB)为单元进行传输的，经过信道编码之后，一个TB包括冗余数据。同时，为了提高数据传输的可靠性，一个TB可能重复传输多次，每次重复传输的数据可能相同，也可能不同。一个TB的所有数据存储于一个环形缓冲区内，每次传输时，根据冗余版本从该环形缓冲区内确定读取数据的起始位置。环形缓冲区是一种特殊的缓冲区，在环形缓冲区内，数据的起始位置与结束位置相邻，环形缓冲区也可以称为虚拟循环缓存(virtual circular buffer)。
举例来说，如图3所示，为本申请实施例提供的一种冗余版本示意图。图3中所示的一个TB经过编码后的数据长度为Ncb，如果该TB包括4个冗余版本，起始位置分别为该TB经过编码后的数据的起始位置、1/4位置、2/4位置以及3/4位置，对应的冗余版本分别为0、1、2、3。当采用冗余版本为0进行传输时，从起始位置开始传输预设长度的数据；相应的，当采用冗余版本为1进行传输时，从1/4位置开始传输预设长度的数据，其它情况不再赘述。
结合上面的描述，方式一至方式三中，冗余版本传输可以是指无混合自动重传请求(Hybrid Automatic Repeat reQuest-less，HARQ-less)传输，也可以是指混合自动重传请求(Hybrid Automatic Repeat reQuest，HARQ)传输。
如果采用HARQ传输，对于同一个TB，每一次重复传输之前，都是根据终端侧设备反馈的上一次传输的确认(Acknowledgement，ACK)或非确认(Negative Acknowledgement，NACK)来决定是否进行传输。
如果采用HARQ-less传输，对于同一个TB，每一次重复传输之前，不必等待终端侧设备反馈的ACK/NACK，而是可以直接传输。HARQ-less传输中，对于同一个TB，第一次传输可以称作初传，重复传输可以称为重传。
结合上面的描述，第一传输模式中可能包括初传的冗余版本传输以及重传的冗余版本传输，网络侧设备可以通过多种方式向终端侧设备指示初传的冗余版本传输所采用的冗余版本以及重传的冗余版本传输所采用的冗余版本。
一种可能的实现方式中，网络侧设备不直接指示初传的冗余版本传输所采用的冗余版本和/或重传的冗余版本传输所采用的冗余版本，终端侧设备以及网络侧设备可以按照相同的方式确定冗余版本传输对应的冗余版本。
在该实现方式下，可以预先约定业务数据的信道编码的码率以及业务数据编码时采用的基础图(base graph，BG)类型与冗余版本的对应关系，网络侧设备可以根据码率以及基础图类型确定所述业务数据在冗余版本传输时的冗余版本，即确定初传的冗余版本传输所采用的冗余版本和/或重传的冗余版本传输所采用的冗余版本。其中，基础图是一种预定义的Tanner图，在对业务数据进行信道编码时，可以通过对基础图进行复制以及变换等扩展操作，构造出预设长度以及预设码率的码字。
在该实现方式下，网络侧设备可以向终端侧设备发送第二信息，所述第二信息用于指示业务数据的信道编码的码率，用于表示有用数据经过信道编码后占用的比例。终端侧设备接收到第二信息，则可以确定业务数据的信道编码的码率。假设基站要发100bit的有用数据给终端侧设备，在物理层分配了10个资源块(一个资源块包括12个子载波)的资源，调制方式为正交相移键控(QPSK)(即一个时域符号传输2个bit)，则经过信道编码后，产生的数据流的比特数为10*12*2＝240bit。而有用数据是100bit，则信道编码的码率为100/240＝0.4167。终端侧设备可以根据码率确定业务数据编码时采用的基础图类型，并根据所述码率以及所述基础图类型确定所述业务数据在冗余版本传输时的冗余版本。
需要说明的是，现有技术的一种可能的实现方式中，当业务数据的信道编码的码率小于或等于0.25时，采用BG2对业务数据进行编码；当业务数据的信道编码的码率大于0.25时，采用BG1对业务数据进行编码。因此终端侧设备可以结合上面的实现方式，根据码率确定基础图类型。例如，终端侧设备根据第二信息确定码率为0.5时，可以确定基础图类型为BG1。当然以上只是示例，终端侧设备具体如何根据码率确定基础图类型，本申请实施例并不限定，在此不再逐一举例说明。
结合上面的描述，下面分别举例描述在不同场景下，码率以及基础图类型与冗余版本的对应关系。举例来说，方式一中的n取值为3。场景一，当业务数据编码时采用的基础图类型为BG1，且业务数据的信道编码的码率小于或等于0.75，或者业务数据编码时采用的基础图类型为BG2且业务数据的信道编码的码率小于或等于0.25时，3次初传的冗余版本传输的冗余版本分别为2、3以及1；3次重传的冗余版本传输的冗余版本分别为2、3以及1。
场景二，当业务数据编码时采用的基础图类型为BG1，且业务数据的信道编码的码率大于0.75，或者业务数据编码时采用的基础图类型为BG2且业务数据的信道编码的码率大于0.25时，3次初传的冗余版本传输的冗余版本分别为2、3以及1；3次重传的冗余版本传输的冗余版本分别为3、1以及0。此时，方式一中，业务数据在冗余版本传输时的冗余版本可以如表2所示。
表2-方式一
Figure GDA0003489744490000121
需要说明的是，表2中，初传的冗余版本以及重传的冗余版本可以为协议预定义的，网络侧设备可以通过DCI向终端侧设备指示初传的冗余版本以及重传的冗余版本。
表2中，第1次重传之后还可能存在第2次重传、第3次重传等，每次重传以及重传的冗余版本传输的冗余版本，都可以参考第1次重传以及第1次重传的3次冗余版本传输，在此不再赘述。
再举例来说，方式二中的n取值为3。场景一，当业务数据编码时采用的基础图类型为BG1，且业务数据的信道编码的码率小于或等于0.75，或者业务数据编码时采用的基础图类型为BG2且业务数据的信道编码的码率小于或等于0.25时，3次重传的冗余版本传输的冗余版本分别为2、3以及1。
场景二，当业务数据编码时采用的基础图类型为BG1，且业务数据的信道编码的码率大于0.75，或者业务数据编码时采用的基础图类型为BG2且业务数据的信道编码的码率大于0.25时，3次重传的冗余版本传输的冗余版本分别为3、1以及0。此时，方式二中，业务数据在冗余版本传输时的冗余版本可以如表3所示。
表3-方式二
Figure GDA0003489744490000131
表3中，第1次重传之后还可能存在第2次重传、第3次重传等，每次重传以及重传的冗余版本传输的冗余版本，都可以参考第1次重传以及第1次重传的3次冗余版本传输，在此不再赘述。
表3中，初传的冗余版本以及重传的冗余版本可以为协议预定义的，网络侧设备可以通过DCI向终端侧设备指示初传的冗余版本以及重传的冗余版本。
再举例来说，方式三中的n取值为3。场景一，当业务数据编码时采用的基础图类型为BG1，且业务数据的信道编码的码率小于或等于0.75，或者业务数据编码时采用的基础图类型为BG2且业务数据的信道编码的码率小于或等于0.25时，3次初传的冗余版本传输的冗余版本分别为2、3以及1。
场景二，当业务数据编码时采用的基础图类型为BG1，且业务数据的信道编码的码率大于0.75，或者业务数据编码时采用的基础图类型为BG2且业务数据的信道编码的码率大于0.25时，3次初传的冗余版本传输的冗余版本分别为2、3以及0。此时，方式二中，业务数据在冗余版本传输时的冗余版本可以如表4所示。
表4-方式三
Figure GDA0003489744490000132
Figure GDA0003489744490000141
表4中，初传的冗余版本以及重传的冗余版本可以为协议预定义的，网络侧设备可以通过DCI向终端侧设备指示初传的冗余版本以及重传的冗余版本。
表4中，第2次重传、第3次重传等每次重传的冗余版本，都可以参考第1次重传的冗余版本，在此不再赘述。
另一种实现方式中，网络侧设备可以向终端侧设备发送第三信息，第三信息用于指示所述业务数据在冗余版本传输时的冗余版本。
在该实现方式下，终端侧设备可以根据第三信息确定所述业务数据在冗余版本传输时的冗余版本。其中，第三信息可以通过DCI发送。
需要说明的是，网络侧设备通过第三信息指示的冗余版本，可以是协议规定的冗余版本，也可以是根据码率以及基础图类型确定的冗余版本，本申请实施例对此并不限定。
本申请实施例中，网络侧设备还可以根据第一传输模式传输所述URLLC业务的业务数据的误块率(block error rate，BLER)，确定是否切换传输模式。
第一种可能的场景中，当所述BLER大于第一预设阈值时，表明当前第一传输模式的可靠性较低，网络侧设备可以切换至第二传输模式向所述终端侧设备传输所述URLLC业务的业务数据。相应的，网络侧设备不再采用第一传输模式传输业务数据。
本申请实施例中，第二传输模式中，首次传输包括的初传的冗余版本传输次数大于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数。
或者，第二传输模式中，重新传输包括的重传的冗余版本传输次数大于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
或者，第二传输模式中，首次传输包括的初传的冗余版本传输次数大于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数，且重新传输包括的重传的冗余版本传输次数大于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
举例来说，第一传输模式为方式二，切换后的第二传输模式二为方式一。
上述方法中，第二传输模式中，首次传输包括的初传的冗余版本传输次数以及重新传输包括的重传的冗余版本传输次数较高，从而能够提供较高的传输可靠性。
第二种可能的场景中，当BLER小于或等于第二预设阈值时，网络侧设备切换至第三传输模式向所述终端侧设备传输所述URLLC业务的业务数据；其中，第二预设阈值小于第一预设阈值。当BLER较低时，表明当前传输可靠性较高，可以减少冗余版本传输次数，降低资源开销。
其中，第三传输模式中，首次传输包括的初传的冗余版本传输次数小于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数。
或者，第三传输模式中，重新传输包括的重传的冗余版本传输次数小于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
或者，第三传输模式中，首次传输包括的初传的冗余版本传输次数小于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数，且重新传输包括的重传的冗余版本传输次数小于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
举例来说，第一传输模式为方式一，切换后的第三传输模式二为方式二或者方式三。
上述方法中，第三传输模式中，首次传输包括的初传的冗余版本传输次数以及重新传输包括的重传的冗余版本传输次数较少，从而能够降低资源开销，提高资源利用率。
第三种可能的场景中，当BLER大于第二预设阈值，且小于或等于第一预设阈值时，网络侧设备可以继续采用第一传输模式向所述终端侧设备传输所述URLLC业务的业务数据。
本申请实施例还可以应用于URLLC业务的上行传输中，在上行传输的场景中，终端侧设备以及网络侧设备可以分别根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式，此时终端侧设备不需要向网络侧设备指示第一传输模式，从而可以降低信令开销。
具体的，参见图4，为本申请实施例提供的一种数据传输方法流程示意图。该方法包括：
步骤401：终端侧设备根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；
步骤402：终端侧设备根据所述第一传输模式向网络侧设备传输所述URLLC业务的业务数据。
步骤403：网络侧设备根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式。
步骤404：网络侧设备根据所述第一传输模式接收来自终端侧设备的所述URLLC业务的业务数据。
上述流程中，终端侧设备在确定第一传输模式之后，也可以向网络侧设备发送第四信息，第四信息用于指示第一传输模式。此时，在步骤403中，网络侧设备不需要根据URLLC业务的业务应用场景确定第一传输模式，直接根据第四信息确定第一传输模式即可。
相应的，网络侧设备在确定第一传输模式之后，也可以向终端侧设备发送第五信息，第五信息用于指示第一传输模式。此时，在步骤401中，终端侧设备不需要根据URLLC业务的业务应用场景确定第一传输模式，直接根据第五信息确定第一传输模式即可。
关于业务应用场景与第一传输模式的对应关系，业务应用场景、以及第一传输模式的具体内容，可以参考前面的描述，在此不再赘述。
如图5所示，为本申请实施例提供一种数据传输装置的结构示意图。该装置可以用于执行上述各方法实施例中终端侧设备的动作，该装置500包括：处理单元501和收发单元502。
该数据传输装置500执行图2所示流程中终端侧设备的动作时：
处理单元501，用于根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，所述终端侧设备接收来自网络侧设备的第一信息，所述第一信息用于指示所述第一传输模式；
收发单元502，用于根据所述第一传输模式接收来自网络侧设备传输的所述URLLC业务的业务数据。
在一种可能的设计中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于0的整数。
在一种可能的设计中，所述URLLC业务的业务应用场景为第一场景时，对应的第一传输模式为所述方式一，所述第一场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第二场景时，第一传输模式为所述方式二，所述第二场景中传输的数据满足以下条件：空口时延小于或等于7ms，上行数据包大小小于或等于250比特，下行数据包大小小于或等于250比特；
或者，所述URLLC业务的业务应用场景为第三场景时，第一传输模式为所述方式一，所述第三场景中传输的数据满足以下条件：空口时延小于或等于1ms，上行数据包大小小于或等于32比特，下行数据包大小小于或等于32比特；
或者，所述URLLC业务的业务应用场景为第四场景时，第一传输模式为所述方式一，所述第四场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第五场景时，第一传输模式为所述方式二，所述第五场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于10000比特，下行数据包大小小于或等于4096比特；
或者，所述URLLC业务的业务应用场景为第六场景时，第一传输模式为所述方式三，所述第六场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于2083比特，下行数据包大小小于或等于5220比特；
或者，所述URLLC业务的业务应用场景为第七场景时，第一传输模式为所述方式二，所述第七场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于1370比特，下行数据包大小小于或等于1370比特。
在一种可能的设计中，所述收发单元502还用于：
接收来自所述网络侧设备的第二信息，所述第二信息用于指示所述业务数据的信道编码的码率；
所述处理单元501还用于，根据所述码率确定所述业务数据的基础图类型，并根据所述码率以及所述基础图类型确定所述业务数据在冗余版本传输时的冗余版本；
或者，所述收发单元502还用于接收来自所述网络侧设备的第三信息，所述第三信息用于指示所述业务数据在冗余版本传输时的冗余版本。
该数据传输装置500执行图4所示流程中终端侧设备的动作时：
处理单元501，用于根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，所述终端侧设备接收来自网络侧设备的第四信息，所述第四信息用于指示所述第一传输模式；
收发单元502，用于根据所述第一传输模式向网络侧设备传输所述URLLC业务的业务数据。
在一种可能的设计中，所述根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式之后，所述收发单元502还用于：
向所述网络侧设备发送第五信息，所述第五信息用于指示所述第一传输模式。
图6是本申请实施例提供的一种装置的结构示意图。图6所示的装置可以为图5所示的装置的一种硬件电路的实现方式。该通信装置可适用于图2或图4所示出的流程图中，执行上述方法实施例中终端侧设备的功能。为了便于说明，图6仅示出了通信装置的主要部件。可选的，该通信装置可以是终端侧设备，也可以是终端侧设备中的装置，如芯片或者芯片系统，其中所述芯片系统包含至少一个芯片，所述芯片系统还可以包括其他电路结构和/或分立器件。可选的，以该通信装置为终端侧设备为例，如图6所示，该装置600包括处理器601、存储器602、收发器603、天线604以及输入输出装置605。处理器601主要用于对通信协议以及通信数据进行处理，以及对整个无线通信装置进行控制，执行软件程序，处理软件程序的数据，例如用于支持无线通信装置执行上述方法实施例中所描述的动作等。存储器602主要用于存储软件程序和数据。收发器603主要用于基带信号与射频信号的转换以及对射频信号的处理。天线604主要用于收发电磁波形式的射频信号。输入输出装置605，例如触摸屏、显示屏，键盘等主要用于接收用户输入的数据以及对用户输出数据。
图6所示的装置600所具有的功能，具体可以参考图2或图4所示的流程中的描述，在此不再赘述。
如图7所示，为本申请实施例提供一种数据传输装置的结构示意图。该装置可以用于执行上述各方法实施例中网络侧设备的动作，该装置700包括：处理单元701和收发单元702。
该数据传输装置700执行图2所示流程中网络侧设备的动作时：
处理单元701，用于根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；
收发单元702，用于根据所述第一传输模式向终端侧设备传输所述URLLC业务的业务数据。
在一种可能的设计中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于或等于0的整数。
在一种可能的设计中，所述URLLC业务的业务应用场景为第一场景时，对应的第一传输模式为所述方式一，所述第一场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第二场景时，第一传输模式为所述方式二，所述第二场景中传输的数据满足以下条件：空口时延小于或等于7ms，上行数据包大小小于或等于250比特，下行数据包大小小于或等于250比特；
或者，所述URLLC业务的业务应用场景为第三场景时，第一传输模式为所述方式一，所述第三场景中传输的数据满足以下条件：空口时延小于或等于1ms，上行数据包大小小于或等于32比特，下行数据包大小小于或等于32比特；
或者，所述URLLC业务的业务应用场景为第四场景时，第一传输模式为所述方式一，所述第四场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第五场景时，第一传输模式为所述方式二，所述第五场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于10000比特，下行数据包大小小于或等于4096比特；
或者，所述URLLC业务的业务应用场景为第六场景时，第一传输模式为所述方式三，所述第六场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于2083比特，下行数据包大小小于或等于5220比特；
或者，所述URLLC业务的业务应用场景为第七场景时，第一传输模式为所述方式二，所述第七场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于1370比特，下行数据包大小小于或等于1370比特。
在一种可能的设计中，所述收发单元702还用于：
确定根据所述第一传输模式传输所述URLLC业务的业务数据的误块率BLER；
当所述BLER大于第一预设阈值时，所述网络侧设备切换至第二传输模式向所述终端侧设备传输所述URLLC业务的业务数据；
其中，所述第二传输模式中，首次传输包括的初传的冗余版本传输次数大于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数，和/或，所述第二传输模式中，重新传输包括的重传的冗余版本传输次数大于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
在一种可能的设计中，所述收发单元702还用于：
当所述bler小于或等于第二预设阈值时，切换至第三传输模式向所述终端侧设备传输所述URLLC业务的业务数据；
其中，所述第三传输模式中，首次传输包括的初传的冗余版本传输次数小于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数，和/或，所述第三传输模式中，重新传输包括的重传的冗余版本传输次数小于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
在一种可能的设计中，所述收发单元702还用于：
向所述终端侧设备发送第三信息，所述第三信息用于指示所述第一传输模式。
在一种可能的设计中，所述收发单元702还用于：
向所述终端侧设备发送第二信息，所述第二信息用于指示所述业务数据的信道编码的码率；所述码率用于确定所述业务数据在冗余版本传输时的冗余版本；
或者，向所述终端侧设备发送第三信息，所述第三信息用于指示所述业务数据在冗余版本传输时的冗余版本。
该数据传输装置700执行图4所示流程中网络侧设备的动作时：
处理单元701，用于根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，所述网络侧设备接收来自终端侧设备的第五信息，所述第五信息用于指示所述第一传输模式；
收发单元702，用于根据所述第一传输模式接收来自终端侧设备的所述URLLC业务的业务数据。
在一种可能的设计中，所述根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式之后，所述收发单元702还用于：
向所述终端侧设备发送第四信息，所述第四信息用于指示所述第一传输模式。
图8是本申请实施例提供的一种通信装置的结构示意图。图8所示的通信装置可以为图7所示的通信装置的一种硬件电路的实现方式。该通信装置可适用于图2或4所示出的流程图中，执行上述方法实施例中网络侧设备的功能。为了便于说明，图8仅示出了通信装置的主要部件。可选的，该通信装置可以是网络侧设备，也可以是网络侧设备中的装置，如芯片或者芯片系统，其中所述芯片系统包含至少一个芯片，所述芯片系统还可以包括其他电路结构和/或分立器件。可选的，以该通信装置为网络侧设备为例，如图8所示，通信装置800包括处理器801、存储器802、收发器803、天线804等。
图8所示的通信装置800所具有的功能，具体可以参考图2或图4所示的流程中的描述，在此不再赘述。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (28)

1.一种数据传输方法，其特征在于，包括：
终端侧设备根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，所述终端侧设备接收来自网络侧设备的第一信息，所述第一信息用于指示所述第一传输模式；
所述终端侧设备根据所述第一传输模式接收来自网络侧设备传输的所述URLLC业务的业务数据；
其中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于0的整数。
2.根据权利要求1所述的方法，其特征在于，所述URLLC业务的业务应用场景为第一场景时，对应的第一传输模式为所述方式一，所述第一场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第二场景时，第一传输模式为所述方式二，所述第二场景中传输的数据满足以下条件：空口时延小于或等于7ms，上行数据包大小小于或等于250比特，下行数据包大小小于或等于250比特；
或者，所述URLLC业务的业务应用场景为第三场景时，第一传输模式为所述方式一，所述第三场景中传输的数据满足以下条件：空口时延小于或等于1ms，上行数据包大小小于或等于32比特，下行数据包大小小于或等于32比特；
或者，所述URLLC业务的业务应用场景为第四场景时，第一传输模式为所述方式一，所述第四场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第五场景时，第一传输模式为所述方式二，所述第五场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于10000比特，下行数据包大小小于或等于4096比特；
或者，所述URLLC业务的业务应用场景为第六场景时，第一传输模式为所述方式三，所述第六场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于2083比特，下行数据包大小小于或等于5220比特；
或者，所述URLLC业务的业务应用场景为第七场景时，第一传输模式为所述方式二，所述第七场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于1370比特，下行数据包大小小于或等于1370比特。
3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
所述终端侧设备接收来自所述网络侧设备的第二信息，所述第二信息用于指示所述业务数据的信道编码的码率；
所述终端侧设备根据所述码率确定所述业务数据的基础图类型，并根据所述码率以及所述基础图类型确定所述业务数据在冗余版本传输时的冗余版本；
或者，所述终端侧设备接收来自所述网络侧设备的第三信息，所述第三信息用于指示所述业务数据在冗余版本传输时的冗余版本。
4.一种数据传输方法，其特征在于，包括：
网络侧设备根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；
所述网络侧设备根据所述第一传输模式向终端侧设备传输所述URLLC业务的业务数据；
其中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于或等于0的整数。
5.根据权利要求4所述的方法，其特征在于，所述URLLC业务的业务应用场景为第一场景时，对应的第一传输模式为所述方式一，所述第一场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第二场景时，第一传输模式为所述方式二，所述第二场景中传输的数据满足以下条件：空口时延小于或等于7ms，上行数据包大小小于或等于250比特，下行数据包大小小于或等于250比特；
或者，所述URLLC业务的业务应用场景为第三场景时，第一传输模式为所述方式一，所述第三场景中传输的数据满足以下条件：空口时延小于或等于1ms，上行数据包大小小于或等于32比特，下行数据包大小小于或等于32比特；
或者，所述URLLC业务的业务应用场景为第四场景时，第一传输模式为所述方式一，所述第四场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第五场景时，第一传输模式为所述方式二，所述第五场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于10000比特，下行数据包大小小于或等于4096比特；
或者，所述URLLC业务的业务应用场景为第六场景时，第一传输模式为所述方式三，所述第六场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于2083比特，下行数据包大小小于或等于5220比特；
或者，所述URLLC业务的业务应用场景为第七场景时，第一传输模式为所述方式二，所述第七场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于1370比特，下行数据包大小小于或等于1370比特。
6.根据权利要求4或5所述的方法，其特征在于，所述方法还包括：
所述网络侧设备确定根据所述第一传输模式传输所述URLLC业务的业务数据的误块率；
当所述误块率大于第一预设阈值时，所述网络侧设备切换至第二传输模式向所述终端侧设备传输所述URLLC业务的业务数据；
其中，所述第二传输模式中，首次传输包括的初传的冗余版本传输次数大于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数，和/或，所述第二传输模式中，重新传输包括的重传的冗余版本传输次数大于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
7.根据权利要求6所述的方法，其特征在于，所述方法还包括：
当所述误块率小于或等于第二预设阈值时，所述网络侧设备切换至第三传输模式向所述终端侧设备传输所述URLLC业务的业务数据；
其中，所述第三传输模式中，首次传输包括的初传的冗余版本传输次数小于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数，和/或，所述第三传输模式中，重新传输包括的重传的冗余版本传输次数小于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
8.根据权利要求4或5所述的方法，其特征在于，所述方法还包括：
所述网络侧设备向所述终端侧设备发送第三信息，所述第三信息用于指示所述第一传输模式。
9.根据权利要求4或5所述的方法，其特征在于，所述方法还包括：
所述网络侧设备向所述终端侧设备发送第二信息，所述第二信息用于指示所述业务数据的信道编码的码率；所述码率用于确定所述业务数据在冗余版本传输时的冗余版本；
或者，所述网络侧设备向所述终端侧设备发送第三信息，所述第三信息用于指示所述业务数据在冗余版本传输时的冗余版本。
10.一种数据传输方法，其特征在于，包括：
终端侧设备根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，所述终端侧设备接收来自网络侧设备的第四信息，所述第四信息用于指示所述第一传输模式；
所述终端侧设备根据所述第一传输模式向网络侧设备传输所述URLLC业务的业务数据；
其中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于0的整数。
11.根据权利要求10所述的方法，其特征在于，所述终端侧设备根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式之后，所述方法还包括：
所述终端侧设备向所述网络侧设备发送第五信息，所述第五信息用于指示所述第一传输模式。
12.一种数据传输方法，其特征在于，包括：
网络侧设备根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，所述网络侧设备接收来自终端侧设备的第五信息，所述第五信息用于指示所述第一传输模式；
网络侧设备根据所述第一传输模式接收来自终端侧设备的所述URLLC业务的业务数据；
其中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于0的整数。
13.根据权利要求12所述的方法，其特征在于，所述网络侧设备根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式之后，所述方法还包括：
所述网络侧设备向所述终端侧设备发送第四信息，所述第四信息用于指示所述第一传输模式。
14.一种数据传输装置，其特征在于，包括：
处理单元，用于根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，收发单元，用于接收来自网络侧设备的第一信息，所述第一信息用于指示所述第一传输模式；
所述收发单元，用于根据所述第一传输模式接收来自网络侧设备传输的所述URLLC业务的业务数据；
其中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于0的整数。
15.根据权利要求14所述的装置，其特征在于，所述URLLC业务的业务应用场景为第一场景时，对应的第一传输模式为所述方式一，所述第一场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第二场景时，第一传输模式为所述方式二，所述第二场景中传输的数据满足以下条件：空口时延小于或等于7ms，上行数据包大小小于或等于250比特，下行数据包大小小于或等于250比特；
或者，所述URLLC业务的业务应用场景为第三场景时，第一传输模式为所述方式一，所述第三场景中传输的数据满足以下条件：空口时延小于或等于1ms，上行数据包大小小于或等于32比特，下行数据包大小小于或等于32比特；
或者，所述URLLC业务的业务应用场景为第四场景时，第一传输模式为所述方式一，所述第四场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第五场景时，第一传输模式为所述方式二，所述第五场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于10000比特，下行数据包大小小于或等于4096比特；
或者，所述URLLC业务的业务应用场景为第六场景时，第一传输模式为所述方式三，所述第六场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于2083比特，下行数据包大小小于或等于5220比特；
或者，所述URLLC业务的业务应用场景为第七场景时，第一传输模式为所述方式二，所述第七场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于1370比特，下行数据包大小小于或等于1370比特。
16.根据权利要求14或15所述的装置，其特征在于，所述收发单元还用于：
接收来自所述网络侧设备的第二信息，所述第二信息用于指示所述业务数据的信道编码的码率；
所述处理单元还用于，根据所述码率确定所述业务数据的基础图类型，并根据所述码率以及所述基础图类型确定所述业务数据在冗余版本传输时的冗余版本；
或者，所述收发单元还用于接收来自所述网络侧设备的第三信息，所述第三信息用于指示所述业务数据在冗余版本传输时的冗余版本。
17.一种数据传输装置，其特征在于，包括：
处理单元，用于根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；
收发单元，用于根据所述第一传输模式向终端侧设备传输所述URLLC业务的业务数据；
其中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于或等于0的整数。
18.根据权利要求17所述的装置，其特征在于，所述URLLC业务的业务应用场景为第一场景时，对应的第一传输模式为所述方式一，所述第一场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第二场景时，第一传输模式为所述方式二，所述第二场景中传输的数据满足以下条件：空口时延小于或等于7ms，上行数据包大小小于或等于250比特，下行数据包大小小于或等于250比特；
或者，所述URLLC业务的业务应用场景为第三场景时，第一传输模式为所述方式一，所述第三场景中传输的数据满足以下条件：空口时延小于或等于1ms，上行数据包大小小于或等于32比特，下行数据包大小小于或等于32比特；
或者，所述URLLC业务的业务应用场景为第四场景时，第一传输模式为所述方式一，所述第四场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于100比特，下行数据包大小小于或等于100比特；
或者，所述URLLC业务的业务应用场景为第五场景时，第一传输模式为所述方式二，所述第五场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于10000比特，下行数据包大小小于或等于4096比特；
或者，所述URLLC业务的业务应用场景为第六场景时，第一传输模式为所述方式三，所述第六场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于2083比特，下行数据包大小小于或等于5220比特；
或者，所述URLLC业务的业务应用场景为第七场景时，第一传输模式为所述方式二，所述第七场景中传输的数据满足以下条件：空口时延小于或等于3ms，上行数据包大小小于或等于1370比特，下行数据包大小小于或等于1370比特。
19.根据权利要求17或18所述的装置，其特征在于，所述收发单元还用于：
确定根据所述第一传输模式传输所述URLLC业务的业务数据的误块率；
当所述误块率大于第一预设阈值时，切换至第二传输模式向所述终端侧设备传输所述URLLC业务的业务数据；
其中，所述第二传输模式中，首次传输包括的初传的冗余版本传输次数大于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数，和/或，所述第二传输模式中，重新传输包括的重传的冗余版本传输次数大于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
20.根据权利要求19所述的装置，其特征在于，所述收发单元还用于：
当所述误块率小于或等于第二预设阈值时，切换至第三传输模式向所述终端侧设备传输所述URLLC业务的业务数据；
其中，所述第三传输模式中，首次传输包括的初传的冗余版本传输次数小于所述第一传输模式中，首次传输包括的初传的冗余版本传输次数，和/或，所述第三传输模式中，重新传输包括的重传的冗余版本传输次数小于所述第一传输模式中，重新传输包括的重传的冗余版本传输次数。
21.根据权利要求17或18所述的装置，其特征在于，所述收发单元还用于：
向所述终端侧设备发送第三信息，所述第三信息用于指示所述第一传输模式。
22.根据权利要求17或18所述的装置，其特征在于，所述收发单元还用于：
向所述终端侧设备发送第二信息，所述第二信息用于指示所述业务数据的信道编码的码率；所述码率用于确定所述业务数据在冗余版本传输时的冗余版本；
或者，向所述终端侧设备发送第三信息，所述第三信息用于指示所述业务数据在冗余版本传输时的冗余版本。
23.一种数据传输装置，其特征在于，包括：
处理单元，用于根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，收发单元，用于接收来自网络侧设备的第四信息，所述第四信息用于指示所述第一传输模式；
所述收发单元，用于根据所述第一传输模式向网络侧设备传输所述URLLC业务的业务数据；
其中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于0的整数。
24.根据权利要求23所述的装置，其特征在于，所述根据超高可靠低时延URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式之后，所述收发单元还用于：
向所述网络侧设备发送第五信息，所述第五信息用于指示所述第一传输模式。
25.一种数据传输装置，其特征在于，包括：
处理单元，用于根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式；或者，收发单元，用于接收来自终端侧设备的第五信息，所述第五信息用于指示所述第一传输模式；
所述收发单元，用于根据所述第一传输模式接收来自终端侧设备的所述URLLC业务的业务数据；
其中，所述第一传输模式为以下模式中的一种：
方式一，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式二，首次传输包括1次初传，重新传输包括1次重传和n次所述重传的冗余版本传输；n为大于0的整数；
方式三，首次传输包括1次初传和n次所述初传的冗余版本传输，重新传输包括1次重传；n为大于0的整数。
26.根据权利要求25所述的装置，其特征在于，所述根据URLLC业务的业务应用场景确定与所述业务应用场景对应的第一传输模式之后，所述收发单元还用于：
向所述终端侧设备发送第四信息，所述第四信息用于指示所述第一传输模式。
27.一种数据传输装置，其特征在于，所述数据传输装置包括处理器和存储器，所述处理器用于执行存储在所述存储器上的指令，当所述指令被运行时，使得所述数据传输装置执行如权利要求1至13中任一项所述的方法。
28.一种计算机可读存储介质，其特征在于，存储有指令，当所述指令被处理器执行时，实现如权利要求1至13中任一项所述的方法。
CN201910472058.9A 2019-05-31 2019-05-31 一种数据传输方法及装置 Active CN112020151B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201910472058.9A CN112020151B (zh) 2019-05-31 2019-05-31 一种数据传输方法及装置
PCT/CN2020/090306 WO2020238638A1 (zh) 2019-05-31 2020-05-14 一种数据传输方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910472058.9A CN112020151B (zh) 2019-05-31 2019-05-31 一种数据传输方法及装置

Publications (2)

Publication Number Publication Date
CN112020151A CN112020151A (zh) 2020-12-01
CN112020151B true CN112020151B (zh) 2022-11-18

Family

ID=73507039

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910472058.9A Active CN112020151B (zh) 2019-05-31 2019-05-31 一种数据传输方法及装置

Country Status (2)

Country Link
CN (1) CN112020151B (zh)
WO (1) WO2020238638A1 (zh)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106376016A (zh) * 2015-07-20 2017-02-01 北京三星通信技术研究有限公司 一种终端的传输模式间切换方法、装置及系统
KR102279483B1 (ko) * 2017-03-24 2021-07-20 삼성전자 주식회사 무선 통신 시스템에서 하향링크 제어신호 검출 방법 및 장치
WO2019003156A1 (en) * 2017-06-27 2019-01-03 Telefonaktiebolaget Lm Ericsson (Publ) SHARED CHANNEL REMAPPING IN A COEXISTENCE SCENARIO OF MULTIPLE RADIO ACCESS TECHNOLOGIES
US10588148B2 (en) * 2017-08-10 2020-03-10 At&T Intellectual Property I, L.P. Configurable groups of control channel resource sets for wireless communication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Remaining issues on UL data transmission procedure;vivo;《3GPP TSG RAN WG1 Meeting AH 1801 R1-1800204》;20180126;全文 *

Also Published As

Publication number Publication date
CN112020151A (zh) 2020-12-01
WO2020238638A1 (zh) 2020-12-03

Similar Documents

Publication Publication Date Title
US10447425B2 (en) Method and apparatus for determining transport block size
EP4096128A1 (en) Feedback method and device for hybrid automatic repeat request information
CN110521265B (zh) 上行数据传输方法、装置及存储介质
JP6965925B2 (ja) 基地局装置、端末装置、無線通信システム、および通信方法
JP2020506594A (ja) 上りリンク・チャネル電力割り当て方法および装置
CN103378936A (zh) 数据传输方法及装置
CN115380596A (zh) 一种支持多播业务的自动重传请求确认反馈信息的传输方法和装置
CN110870237A (zh) 基于数据块的传输
AU2018286249A1 (en) Communication method, apparatus, and computer-readable storage medium
JP2022517196A (ja) ダウンリンクデータ送信方法、受信方法、装置及び記憶媒体
CN113439402B (zh) 一种译码方法、装置及系统
KR20200138747A (ko) 업 링크 제어 정보 전송 방법 및 장치
JP2023517980A (ja) 通信方法および装置
KR20240136454A (ko) 단말 및 통신 방법
US10652868B2 (en) Terminal apparatus, base station apparatus, and wireless communication method
EP3837788A1 (en) Wireless data transmission apparatus, wireless data reception apparatus and methods
CN112020151B (zh) 一种数据传输方法及装置
CN102480348A (zh) 数据传输方法及通信节点
JP2022068858A (ja) Ｈａｒｑ再送信を処理するデバイス
US10211961B2 (en) Method and system for sending transmission acknowledgement information
CN110999339A (zh) 重复发送次数调整方法、装置以及存储介质
CN113383591B (zh) 一种通信方法及装置
WO2024197904A1 (zh) 一种数据处理方法及相关装置
CN109565368B (zh) 数据传输方法和通信装置
CN118018166A (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