CN114630283B - 多播业务的确认模式传输方法、装置、设备及存储介质 - Google Patents

多播业务的确认模式传输方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN114630283B
CN114630283B CN202011460558.XA CN202011460558A CN114630283B CN 114630283 B CN114630283 B CN 114630283B CN 202011460558 A CN202011460558 A CN 202011460558A CN 114630283 B CN114630283 B CN 114630283B
Authority
CN
China
Prior art keywords
multicast
transmission
feedback
timer
receiving
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
CN202011460558.XA
Other languages
English (en)
Other versions
CN114630283A (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.)
Vivo Mobile Communication Co Ltd
Original Assignee
Vivo Mobile Communication 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 Vivo Mobile Communication Co Ltd filed Critical Vivo Mobile Communication Co Ltd
Priority to CN202011460558.XA priority Critical patent/CN114630283B/zh
Priority to PCT/CN2021/135983 priority patent/WO2022121876A1/zh
Publication of CN114630283A publication Critical patent/CN114630283A/zh
Application granted granted Critical
Publication of CN114630283B publication Critical patent/CN114630283B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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
    • 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
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/04—Error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management

Landscapes

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

Abstract

本申请公开了一种多播业务的确认模式传输方法、装置、设备及存储介质，属于通信技术领域，所述方法包括：通过点到多点PTM传输路径接收网络侧设备发送的多播业务MBS数据；基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告。本申请实现了多播AM传输，既保障了多播调度的高资源效率也能够同时提升接收的可靠性，在提升终端接收MBS业务的服务质量和体验的基础上，提升系统效率。

Description

多播业务的确认模式传输方法、装置、设备及存储介质
技术领域
本申请属于通信技术领域，具体涉及一种多播业务的确认模式传输方法、装置、设备及存储介质。
背景技术
在相关技术中，基于无线链路控制(Radio Link Control，RLC)非确认模式(UnAcknowledged Mode，UM)研究并标准化了一些提升可靠性的机制，例如增加混合自动重传请求(Hybrid Automatic Repeat reQuest，HARQ)重传次数，自主重传，以及高层的分组数据汇聚协议(Packet Data Convergence Protocol，PDCP))重复(duplication)机制等，但需要注意，这些机制对资源的消耗都是巨大的，主要是针对同时对可靠性和时延均要求比较高的业务进行的，相当于通过牺牲资源换来低时延高可靠性的极致服务质量(Qualityof Service，QoS)指标。
而多播(multicast broadcast service，MBS，或译为组播/广播)业务，也存在很多对时延要求不敏感，只对可靠性有较高要求的业务。如果对这样的业务使用现有的RLCUM提升可靠性的机制，则会消耗过多资源，达到的低时延并非是业务需求，得不偿失，导致网络资源效率低下。
发明内容
本申请实施例的目的是提供一种多播业务的确认模式传输方法、装置、设备及存储介质，能够解决相关技术为了满足高可靠性要求所导致的网络资源效率低下的问题。
为了解决上述技术问题，本申请是这样实现的：
第一方面，提供了一种多播业务的确认模式传输方法，应用于终端，该方法包括：
通过点到多点PTM传输路径接收网络侧设备发送的多播业务MBS数据；
基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告。
第二方面，提供了一种多播业务的确认模式传输方法，应用于网络侧设备，该方法包括：
通过点到多点PTM传输路径向多个终端发送多播业务MBS数据；
通过点到点PTP传输路径接收所述多个终端反馈的状态报告。
第三方面，提供了一种多播业务的确认模式传输装置，应用于终端，该装置包括：
数据接收单元，用于通过点到多点PTM传输路径接收网络侧设备发送的多播业务MBS数据；
状态反馈单元，用于基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告。
第四方面，提供了一种多播业务的确认模式传输装置，应用于网络侧设备，该装置包括：
数据发送单元，用于通过点到多点PTM传输路径向多个终端发送多播业务MBS数据；
状态接收单元，用于通过点到点PTP传输路径接收所述多个终端反馈的状态报告。
第五方面，提供了一种终端，该终端包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的多播业务的确认模式传输方法的步骤。
第六方面，提供了一种网络侧设备，该网络侧设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第二方面所述的多播业务的确认模式传输方法的步骤。
第七方面，提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的多播业务的确认模式传输方法的步骤，或者实现如第二方面所述的多播业务的确认模式传输方法的步骤。
第八方面，提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行网络侧设备程序或指令，实现如第一方面所述的方法，或实现如第二方面所述的方法。
在本申请实施例中，实现了多播AM传输，既保障了多播调度的高资源效率也能够同时提升接收的可靠性，在提升终端接收MBS业务的服务质量和体验的基础上，提升系统效率。
附图说明
图1为本申请实施例可应用的一种无线通信系统的框图；
图2为本申请实施例提供的多播业务的确认模式传输方法的流程示意图之一；
图3本申请实施例提供的UE侧使用common RLC entity的协议栈示意图；
图4为本申请实施例提供的UE侧使用common PDCP entity的协议栈示意图；
图5为本申请实施例提供的多播业务的确认模式传输方法的示意图之二；
图6为本申请实施例提供的多播业务的确认模式传输装置的结构示意图之一；
图7为本申请实施例提供的多播业务的确认模式传输装置的结构示意图之二；
图8为实现本申请实施例的一种通信设备的结构示意图；
图9为实现本申请实施例的一种终端的硬件结构示意图；
图10为实现本申请实施例的一种网络侧设备的硬件结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”所区别的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”一般表示前后关联对象是一种“或”的关系。
值得指出的是，本申请实施例所描述的技术不限于长期演进型(Long TermEvolution，LTE)/LTE的演进(LTE-Advanced，LTE-A)系统，还可用于其他无线通信系统，诸如码分多址(Code Division Multiple Access，CDMA)、时分多址(Time DivisionMultiple Access，TDMA)、频分多址(Frequency Division Multiple Access，FDMA)、正交频分多址(Orthogonal Frequency Division Multiple Access，OFDMA)、单载波频分多址(Single-carrier Frequency-Division Multiple Access，SC-FDMA)和其他系统。本申请实施例中的术语“系统”和“网络”常被可互换地使用，所描述的技术既可用于以上提及的系统和无线电技术，也可用于其他系统和无线电技术。然而，以下描述出于示例目的描述了新空口(New Radio，NR)系统，并且在以下大部分描述中使用NR术语，尽管这些技术也可应用于NR系统应用以外的应用，如第6代(6th Generation，6G)通信系统。
图1示出本申请实施例可应用的一种无线通信系统的框图。无线通信系统包括终端11和网络侧设备12。其中，终端11也可以称作终端设备或者用户终端(User Equipment，UE)，终端11可以是手机、平板电脑(Tablet Personal Computer)、膝上型电脑(LaptopComputer)或称为笔记本电脑、个人数字助理(Personal Digital Assistant，PDA)、掌上电脑、上网本、超级移动个人计算机(ultra-mobile personal computer，UMPC)、移动上网装置(Mobile Internet Device，MID)、可穿戴式设备(Wearable Device)或车载设备(VUE)、行人终端(PUE)等终端侧设备，可穿戴式设备包括：手环、耳机、眼镜等。需要说明的是，在本申请实施例并不限定终端11的具体类型。网络侧设备12可以是基站或核心网，其中，基站可被称为节点B、演进节点B、接入点、基收发机站(Base Transceiver Station，BTS)、无线电基站、无线电收发机、基本服务集(Basic Service Set，BSS)、扩展服务集(ExtendedService Set，ESS)、B节点、演进型B节点(eNB)、家用B节点、家用演进型B节点、WLAN接入点、WiFi节点、发送接收点(Transmitting Receiving Point，TRP)或所述领域中其他某个合适的术语，只要达到相同的技术效果，所述基站不限于特定技术词汇，需要说明的是，在本申请实施例中仅以NR系统中的基站为例，但是并不限定基站的具体类型。
下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的多播业务的确认模式传输方法、装置、设备及存储介质进行详细地说明。
RLC确认模式(Acknowledged Mode，AM)是一种可靠性比较高的传输方式，通过RLC实体接收端的反馈和相应接收到反馈之后发送端的重传，可以进一步提升误块率要求，通常用于高可靠性且对时延不敏感的业务。
相比RLC UM模式来说，RLC AM引入了RLC层的反馈机制，可以进一步解决HARQ达到最大重传次数仍旧未正确以及HARQ反馈的误检(例如NACK->ACK)导致的额外丢包。
为了解决相关技术为了满足高可靠性要求所导致的网络资源效率低下的问题，本申请实施例提供了多播业务的确认模式传输方法，即对多播业务传输采用AM模式。
图2为本申请实施例提供的多播业务的确认模式传输方法的流程示意图之一，该方法的执行主体可以是终端，如图2所示，该方法包括以下步骤：
步骤200、通过点到多点PTM传输路径接收网络侧设备发送的多播业务MBS数据；
为了达成本申请的发明目的，在本申请实施例中，为接收高可靠性多播业务的UE配置两条传输路径，分别是点到多点(Point to Multipoint，PTM)传输路径和点到点(Point to point，PTP)传输路径，均执行AM模式，从而实现多播AM传输。
需要说明的是，传输路径可以既包含实体，即PTP对应的L2实体和PTM对应的L2实体是各自独立的；传输路径也包含调度的差别，例如PTP是由小区无线网络临时标识(CellRadio Network Temporary Identity，C-RNTI)调度的，单播(unicast)方式，PTM是由组呼无线网络临时标识(Group Radio Network Temporary Identity，G-RNTI)调度的，多播方式。
终端通过点到多点PTM传输路径接收网络侧设备发送的多播业务MBS数据。
步骤201、基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告。
多播业务数据的接收情况包括以下各项中的一项：
不存在接收缺口gap；
存在接收gap。
终端基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告。
可选的，若所述多播业务数据的接收情况为存在接收gap，终端生成一个状态报告，通过点到点PTP传输路径向所述网络侧设备反馈状态报告。其中，状态报告携带gap处的数据的SN号作为NACK-SN，并且可以包含丢失的分段数据信息，以通知发送端即网络侧设备对gap处的协议数据单元(protocol Data Unit，PDU)和/或PDU分段进行重传。
在一个可选的实施例中，所述基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告，包括：
在确定存在接收缺口gap的情况下，通过PTP传输路径向网络侧设备反馈状态报告，所述状态报告中携带NACK_SN信息，所述NACK_SN信息为所述接收gap处的数据的序列号(Sequence Number，SN)和/或SN分段信息。
其中，所述确定存在接收缺口gap，包括：
在检测到接收gap时，启动重组定时器；若在所述重组定时超时的情况下，所述gap处的数据仍然没有补全，则确定所述gap处的数据为丢包。
需要说明的是，状态报告的内容包括：ACK_SN，这个域为必选；NACK_SN，可以包含PDU或者分段信息，为可选；
如果状态报告仅包含ACK_SN，则意味着该ACK_SN之前的所有数据包都被确认ACK了；
如果状态报告包含ACK_SN和NACK_SN信息，则意味着该ACK_SN前，除了显式携带的NACK_SN对应的PDU或分段是NACK的需要重传，其余所有其它数据包也都是被确认ACK了。
在本申请实施例中，通过为接收高可靠性多播业务的UE配置PTM传输路径和PTP传输路径，实现了多播AM传输，既保障了多播调度的高资源效率也能够同时提升接收的可靠性，在提升终端接收MBS业务的服务质量(Quality of Service，QoS)和体验的基础上，进一步提升系统效率。
在一些可选的实施例中，所述PTP传输路径和PTM传输路径共用无线链路控制RLC层实体，在RLC层执行确认模式AM；或者，
所述PTP传输路径和PTM传输路径共用分组数据汇聚协议PDCP层实体，在PDCP层执行确认模式AM。
AM的典型特点是接收端通过检测到接收缺口gap，可以触发状态报告上报，携带NACK-SN信息，由发送端对这些NACK-SN对应的PDU进行重传，从而有针对性地进行重传，提升可靠性。按照传统单播的AM，是在RLC层实现AM传输的。
因此，在一些可选的实施例中，多播也可以借鉴单播AM的方式，使用两条传输路径PTM和PTP来实现多播RLC AM传输，即所述PTP传输路径和PTM传输路径使用共同的无线链路控制层实体(common RLC entity)，在RLC层执行确认模式AM。
图3为本申请实施例提供的UE侧使用common RLC entity的协议栈示意图。可以理解的是，现有RLC实体的功能基本可以继承。终端RLC层的状态报告反馈可以使用上行链路(UP link,UL)PTP传输路径进行传输，重传和初传可以由网络侧设备根据实现算法决定在PTM传输路径还是PTP传输路径进行传输，无论是采用PTM还是PTP，接收到的数据包交给统一的RLC实体进行处理，包括SN重复检测和重排序等。
本申请实施例还提供另一种多播AM的实现方式——在PDCP层实现AM传输，即所述PTP传输路径和PTM传输路径共用分组数据汇聚协议PDCP层实体，在PDCP层执行确认模式AM。按照现有双连接(Dual connectivity，DC)架构以及重复(duplication)架构，各种分流承载(split bearer)和重复承载(duplication bearer)的架构特点，都是使用共同的PDCP实体(common PDCP entity)。
图4为本申请实施例提供的UE侧使用common PDCP entity的协议栈示意图。其中，由于现有的PDCP层仅在切换时进行状态反馈和恢复，并不具备丢包检测和主动请求重传的功能，因此为了在common PDCP entity实现AM传输，PDCP层需要引入类似于RLC AM的丢包检测和主动触发状态报告的功能，假设将RLC AM的类似的机制引入到PDCP以进行状态报告触发和重传过程。同样的，PDCP层的状态反馈也是通过UL PTP传输路径进行传输。
以上两种架构是实现多播AM模式的可行架构，common RLC的架构中，现有RLC实体的AM功能直接使用，且能够基于RLC PDU分段(segment)进行状态反馈和重传。而commonPDCP架构需要将RLC AM的类似机制在PDCP实体再次实现一次，且只能基于PDCP PDU，等同于RLC服务数据单元(Service Data Unit，SDU)，即不能是分段只能是完整数据包进行状态反馈和重传，因此重传的效率是低于common RLC的架构的。但common PDCP的架构的最大好处是复用了双连接分流承载(legacy DC split bearer)的架构，配置较方便。
Common RLC架构是实现多播AM较为高效的架构。基本上RLC AM实体的大部分功能直接使用即可，但因为此时RLC AM一个发送端实体对应了多个接收端实体，因此相比于现有单播RLC AM来说，多播RLC AM有一些特殊的地方。
简单来说，因为在单播RLC AM时，一个发送端实体对应于一个接收端实体，因此发送端可以完全根据接收端的状态进行更新，以确保RLC AM接收端本身不会发生任何丢包行为，因为当前RLC AM如果发生了到达RLC AM最大重传次数，仍旧不能将接收端的一个gap进行修复，直接会触发无线链路失败(radio link failure，RLF)行为，释放链路或者重选，对RLC实体是重建立re-establishment或者release+set，即单播时RLC AM实体接收端本身不允许出现任何一个接收gap没有被填满的情况。
而对于多播RLC AM，由于是一个发送端实体对应于多个接收端实体，相当于一个网络节点同时为多个UE发送数据，此时类似单播RLC AM实体的严格不允许任何接收gap存在的这种机制不再适用，否则多播业务就会因为一个UE的链路特别恶化而影响其它链路情况良好的UE的MBS业务接收。
基于上述的分析和比较，需要给多播RLC AM接收侧即UE侧引入新的机制，以便于进行接收窗口的更新，避免锁死。
同样的，common PDCP架构下，也需要给多播PDCP AM接收侧即UE侧引入新的机制，以便于进行接收窗口的更新，避免锁死。
在一些可选的实施例中，所述多播业务的确认模式传输方法，还包括：
在所述状态报告的反馈满足第一预设条件的情况下，更新接收窗口；
其中，所述第一预设条件包括以下至少一项：
反馈次数计数器的数值达到或超过最大反馈次数；
反馈定时器超时。
可选的，终端对状态报告的反馈进行维护，并继续反馈和对所述gap处的数据进行等待；
在所述状态报告的反馈满足第一预设条件的情况下，停止反馈和对所述gap处的数据的等待，更新接收窗口。
一种可选的UE自行更新接收窗口的机制是基于反馈次数计数器。
在一个可选的实施例中，网络侧为MBS业务的一个承载，配置了RLC/PDCP AM传输，且同时配置RLC/PDCP AM传输的最大反馈次数。
终端维护反馈次数计数器，该反馈次数计数器初始值为0；
当终端检测到一个接收gap，即终端接收PDU的SN为0，1，2，……，n-1，之后又接收到n+1，则认为SN＝n的这个数据包为接收gap；
如果该RLC/PDCP AM实体配置了重组定时器大小，即RLC/PDCP AM具有HARQfeedback，前后数据包由于HARQ反馈和重传可能发生先发后至、后发先至的情况，此时检测到接收gap之后，需要启动重组定时器，在重组定时器运行期间如果接收到gap处数据，则正常更新接收状态和接收窗口，当重组定时器超时，gap处数据仍旧没有补全，则该gap处数据被认为一个真正的丢包；其中，重组定时器是针对一定SN区间内的gap进行生效的；
对上述已经经过重组定时器等待的gap处数据，UE需要生成一个状态报告，其中，携带gap处的数据的SN号作为NACK-SN，并且可以包含丢失的分段数据信息，将状态报告通过PTP leg发送给网络侧的RLC AM发送端，此时第一次被包含在状态报告中作为NACK-SN的数据包，其对应的反馈次数计数器+1；
UE侧重启重组定时器，如果重组定时器超时，重组定时器启动的SN位置之前仍旧存在gap丢包，则再次组织状态报告进行上报，此时被包含在状态报告中作为NACK-SN的数据包，其对应的反馈次数计数器+1；
如果某一个数据包SN＝x的反馈计数器等于或者大于了网络侧配置的最大反馈次数，则UE行为是放弃该SN＝x处的数据包等待，将其记录的状态全部清零，例如清零反馈计数器，并将该gap处视为补全，将接收窗口的下边界移动到下一个gap处。
使用了如上的机制，可以使UE侧进行接收窗口的自行更新，给定最大RLC反馈次数(一般来说每一次反馈会触发一次重传)，相当于反馈达到最大次数之后，认为剩余的错误不再花力气补救，以使得传输可以继续，避免耽误其它UE的多播业务接收。
需要说明的是，所述反馈次数计数器的更新，包括：
以共用协议层协议数据单元PDU序列号SN为粒度，每当一个共用协议层PDU SN被作为状态报告中的NACK_SN信息时，所述反馈次数计数器加一；或者，
以共用协议层PDU SN分段为粒度，每当一个共用协议层PDU SN分段被作为状态报告中的NACK_SN信息时，所述反馈次数计数器加一。
需要说明的是，共用协议层是指RLC或者PDCP，在所述PTP传输路径和PTM传输路径共用RLC层实体的情况下，共用协议层为RLC层；在所述PTP传输路径和PTM传输路径共用PDCP层实体的情况下，共用协议层为PDCP层。
可以基于SN粒度或SN分段粒度来更新反馈次数计数器。
每当一个共用协议层PDU SN被作为状态报告中的NACK_SN信息时，可以理解为：终端只要组织状态报告，状态报告包含了NACK_SN＝m，该反馈次数计数器即加一；或者，只要组织并发送了状态报告，状态报告包含了NACK_SN＝m，计数器即加一。
例如，在一个RLC状态报告中同时包含一个SN的两个或者两个以上的分段时，也仍旧为该SN对应的反馈次数计数器只加1。
每当一个共用协议层PDU SN分段被作为状态报告中的NACK_SN信息时，可以理解为：终端只要组织状态报告，状态报告包含了该PDU SN分段信息，该反馈次数计数器即加一；或者，只要组织并发送了状态报告，状态报告包含了该PDU SN分段信息，计数器即加一。
例如，在一个RLC状态报告中同时包含一个SN的两个或者两个以上的分段时，以包含的具体分段的个数为该SN分段对应的反馈次数计数器依次增加1，即第一个分段对应的反馈次数计数器+1，第二个分段对应的反馈次数计数器+1，依次类推。
上述两种反馈次数计数器的更新方式，在数据包较小的情况下，没有差别，在数据包较大，一个数据包被分成多个分段的情况下，以共用协议层协议数据单元PDU序列号SN为粒度更利于对SN的重传效果进行监控，以共用协议层PDU SN分段为粒度更利于对整体重传成功率进行监控，各有好处，可以根据实际情况进行选择和使用。
本申请还提供一种可选的UE自行更新接收窗口的机制，基于反馈定时器。
在一个可选的实施例中，网络侧为MBS业务的一个承载，配置了RLC/PDCP AM传输，且同时配置RLC/PDCP AM传输的反馈定时器长度。
其中，反馈定时器长度可以显式配置；反馈定时器长度也可以隐式配置，例如以该业务的PDB(packet delay budget)来推算反馈定时器长度，例如timer＝PDB–offset，其中offset可以为0或者一次HARQ传输时长或者固定值。
可选的，反馈定时器长度是重组定时器若干倍。
反馈定时器的作用是对一个或者多个PDU或者PDU分段的数据包其反馈的时长进行一定的限制，避免无限等待，可以进一步主动更新接收窗口。
可选的，所述反馈定时器的粒度，包括：
对每个共用协议层PDU，维护一个独立的反馈定时器；或者，
对每个共用协议层PDU分段，维护一个独立的反馈定时器；或者，
对一次重组定时器范围内新增的gap处的共用协议层PDU和分段合集，维护一个反馈定时器；或者，
对所有当前经过了重组定时器超时的gap处的共用协议层PDU和分段合集，维护一个反馈定时器。
以共用协议层为RLC为例，反馈定时器的粒度，可以有如下之一选择：
对每个RLC PDU启动和维护一个独立的反馈定时器，一个PDU的不同分段共享同一个反馈定时器，这是反馈定时器的第二细的粒度；
对每个RLC PDU分段，启动和维护一个独立的反馈定时器，这是反馈定时器的最细粒度；
对一次重组定时器范围内新增的gap处的PDU和分段合集，启动和维护一个反馈定时器，需要使用[SN1(可选的包含segment信息),SN2(可选的包含segment信息)]来标识定时器对应的SN的起止位置，这是反馈定时器第三细的粒度；
对所有当前经过了重组定时器超时的gap处的PDU和分段合集，启动和维护一个反馈定时器，需要有SN3(可选的包含segment信息)来标识定时器对应的SN范围的最高位置，可以复用重组定时器的SN记录的方式进行更新，这是反馈定时器最粗的粒度；
反馈定时器越细，效果越精准，但开销和复杂度增大，因此需要在效果和代价之间进行折中选择，最终实施时选择其一即可。
可选的，所述反馈定时器的初始启动点包括：
在第一次检测到接收gap时；或者，
在第一次经过了重组定时器超时，所述接收gap仍然存在；或者，
所述状态报告的第一次发送时刻。
可以理解的是，可以在第一次检测到gap的时候，就启动相应的反馈定时器；也可以在第一次经过了重组定时器超时，仍旧认为是丢包gap时，再启动相应反馈定时器；也可以在第一次组织状态报告发送之后，启动相应的反馈定时器。
反馈定时器超时，意味着对反馈定时器所记录的SN空间之内，放弃再次反馈和等待，将接收窗口更新到下一个gap处；例如，反馈定时器的启动，一般会记录一下feedback-SN，意味着该反馈定时器对小于该SN的所有窗口内的数据包有效，一旦定时器超时，则小于该SN的窗口内的gap都不再等待，对于区间内已经完整接收的PDU直接按照升序递交高层，对于区间内已经接收的PDU分段，直接删除。
使用了如上的机制，可以使UE侧进行接收窗口的自行更新，给定反馈定时器长度，相当于反馈达到定时器长度之后，认为剩余的错误不再花力气补救，以使得传输可以继续，避免耽误其它UE的多播业务接收。
需要说明的是，如果所述多播业务数据接收正确且连续接收，终端直接更新接收窗口，例如连续接收SN为0，1，2，3，4，5的数据包，则每次接收到一个数据包，都会把接收窗口下边界更新为SN+1。
可选的，更新接收窗口，包括：
将接收窗口的下边界移动到下一个gap处；
根据所述接收窗口的下边界确定所述接收窗口的上边界。
在本申请实施例中，通过使用多播AM方式进行业务传输，使UE侧进行接收窗口的自行更新，为有很高的业务可靠性要求的数据在确保高资源效率下提供更好的QoS保障，有利于保障网络资源效率，在确保系统效率的基础上极大提升UE的MBS业务接收体验。
在上述实施例的基础上，所述多播业务的确认模式传输方法，还包括：
接收网络侧设备配置的AM传输的最大反馈次数，和/或，接收网络侧设备配置的AM传输的反馈定时器的长度。
可以理解的是，终端接收网络侧设备配置的AM传输的最大反馈次数，和/或，反馈定时器的长度，根据最大反馈次数和/或反馈定时器的长度，进行接收窗口的更新，从而不会因为一个UE链路特别恶化而影响到其他链路情况良好的UE的多播业务的接收，可以在确保系统效率的基础上极大提升UE的MBS业务接收体验。
现有单播RLC AM中，发送端和接收端都是执行严格的下边界驱动的窗口维护方式，主要目的是为了精确的维护收发端的状态，避免任何一个丢包。而在多播RLC AM中，由于确保所有UE都避免任何一个丢包的代价较大，会因为一个UE而拖累其它UE的传输进度。
因此一种解决思路是，放低对接收窗口的维护严格程度，采取上边界驱动的窗口机制。在一些可选的实施例中，所述多播业务的确认模式传输方法，还包括：
若接收到的新多播数据包的SN位于接收窗口之内，则进行重排序和重复检测判断，若存在重复的数据包，则删除所述重复的数据包，若存在非重复的数据包，则利用所述非重复数据包填补所述接收gap；
若接收到的新多播数据包的SN位于接收窗口之外，则将所述接收窗口的上边界更新为所述新多播数据包的SN加一，并根据所述上边界确定下边界。
其中，所述接收窗口的上边界初始值为零，或者，所述接收窗口的上边界初始值为接收到的第一个数据包的SN加一。
可以理解的是，若终端通过PTM或PTP传输路径接收到的新多播数据包的SN位于接收窗口之内(高于或者等于下边界且低于上边界)，则进行重排序和重复检测判断，若存在重复的数据包，则删除所述重复的数据包，若存在非重复的数据包，则利用所述非重复数据包填补所述接收gap，将连续的数据包按序递交高层。
若终端通过PTM或PTP传输路径接收到的新多播数据包的SN位于接收窗口之外，则将所述接收窗口的上边界更新为所述新多播数据包的SN加一，并根据所述上边界确定下边界，其中，接收窗口的下边界＝接收窗口上边界–SN空间大小的一半，同时考虑SN翻转的情况，对上述等式进行模SN空间大小操作。
同时将落于边界外的SN计数器和定时器清除，将窗外未完整接收的分段PDU清除，将完整接收的PDU按升序递交高层。
需要说明的是，对于网络侧，仍旧是采取下边界驱动的发送窗口机制，确保发送窗口能够及时更新，以避免速率降低和对链路较好UE的窗口的更新速度甚至失步的影响。
在本申请实施例中，通过采取上边界驱动的窗口机制，使UE侧进行接收窗口的自行更新，为有很高的业务可靠性要求的数据在确保高资源效率下提供更好的QoS保障，有利于保障网络资源效率，在确保系统效率的基础上极大提升UE的MBS业务接收体验。
图5为本申请实施例提供的多播业务的确认模式传输方法的示意图之二，该方法的执行主体可以是网络侧设备，如图5所示，该方法包括以下步骤：
步骤500、通过点到多点PTM传输路径向多个终端发送多播业务MBS数据；
为了达成本申请的发明目的，在本申请实施例中，为发送高可靠性多播业务的网络侧设备配置两条传输路径，分别是点到多点(Point to Multipoint，PTM)传输路径和点到点(Point to point，PTP)传输路径，均执行AM模式，从而实现多播AM传输。
需要说明的是，传输路径可以既包含实体，即PTP对应的L2实体和PTM对应的L2实体是各自独立的；传输路径也包含调度的差别，例如PTP是由小区无线网络临时标识(CellRadio Network Temporary Identity，C-RNTI)调度的，单播(unicast)方式，PTM是由组呼无线网络临时标识(Group Radio Network Temporary Identity，G-RNTI)调度的，多播方式。
网络侧设备通过点到多点PTM传输路径向多个终端发送多播业务MBS数据。
步骤501、通过点到点PTP传输路径接收所述多个终端反馈的状态报告。
网络侧设备通过点到点PTP传输路径接收所述多个终端反馈的状态报告，网络侧设备根据终端反馈的状态报告，确定多播业务数据在接收端的状态，从而有针对性地进行重传，提升可靠性。
本申请实施例中，网络侧设备使用多播AM方式进行业务传输，为有很高的业务可靠性要求的数据在确保高资源效率下提供更好的QoS保障，有利于保障网络资源效率，在确保系统效率的基础上大大提升UE的MBS业务接收体验。
在一些可选的实施例中，所述PTP传输路径和PTM传输路径共用无线链路控制RLC层实体，在RLC层执行确认模式AM；或者，
所述PTP传输路径和PTM传输路径共用分组数据汇聚协议PDCP层实体，在PDCP层执行确认模式AM。
可以理解的是，网络侧设备也可以使用前述实施例中提及的common RLC entity架构或common PDCP entity架构，具体内容可以参考终端侧的描述，在此不再赘述。
可选的，在终端使用common RLC entity架构时，网络侧设备也应该对等使用common RLC entity架构；同样地，在终端使用common PDCP entity架构时，网络侧设备也应该对等使用common PDCP entity架构。
在一些可选的实施例中，所述多播业务的确认模式传输方法，还包括：
在接收到至少一个终端的状态报告中携带NACK_SN信息的情况下，通过PTP传输路径和/或PTM传输路径对所述NACK_SN处的数据进行重传；
可以理解的是，网络侧设备在接收到至少一个终端的状态报告中携带NACK_SN信息的情况下，可以选择PTP传输路径或者PTM传输路径对所述NACK_SN处的数据进行重传，也可以选择通过PTP传输路径和PTM传输路径同时重传。
其中，所述NACK_SN信息为接收gap处的数据的序列号SN和/或SN分段信息。
在多播情况下，网络侧设备共用协议层实体相当于需要根据多个UE的接收状态进行发送端状态维护，也与单播收发实体一对一具有很大的不同，不能因为个别UE的长时间或者多次重传恢复不成功，一直持续等待，导致影响了整个发送进度，影响其它UE的接收效果。因此，需要给网络侧设备引入新的机制，以便于进行发送窗口的更新。
在一些可选的实施例中，所述多播业务的确认模式传输方法，还包括：
在接收到所有终端的状态报告中均仅包含ACK_SN的情况下，更新发送窗口；
需要说明的是，状态报告中仅包含ACK_SN，可以理解为状态报告中不包括NACK-SN，并不排除状态报告中包括STATUS control PDU header。
可以理解的是，所有终端的状态报告中均仅包含ACK_SN，说明所有终端均已确认接收到网络侧设备发送的多播业务数据，此时，网络侧设备可以直接更新发送窗口。
可选的，在满足第二预设条件的情况下，更新发送窗口；
其中，所述满足第二预设条件包括以下至少一项：
重传定时器超时；
重传次数计数器的数值达到或超过最大重传次数。
本申请实施例提供两种更新发送窗口的机制。
一种是基于重传定时器来更新发送窗口，重传定时器超时，则放弃该重传定时器对应SN或者分段或者区间处的重传尝试，将发送窗口下边界更新到下一个未超时的未全部确认SN处。
可选的，所述重传定时器的启动点包括：
第一次接收到终端的状态报告中携带非确认消息；或者，
第一次重传。
可选的，所述重传定时器的粒度为：
对于每一个共用协议层PDU，维护一个重传定时器；
对于每一个共用协议层PDU分段，维护一个重传定时器；
对于一个区间内的PDU/PDU分段，维护一个重传定时器。
另一种是基于重传次数计数器来更新发送窗口。如果是PTP重传，则可以为每个UE独立维护重传次数计数器，如果是PTM重传，则可以为数据包维护重传次数计数器，如果是二者混合重传，则基于UE维护。
当重传次数计数器达到或者超过最大重传次数，则放弃该重传次数计数器对应SN或者分段处的针对该UE的重传尝试，当所有UE的最大重传次数都达到，则将发送窗口下边界更新到下一个未达到最大重传的SN处。
可选的，所述重传次数计数器的更新包括：
对于每个终端的一个共用协议层PDU或PDU分段维护一个重传次数计数器，或者，对于每一个共用协议层PDU或PDU分段维护一个重传次数计数器；
在对所述PDU或PDU分段进行了一次重传时，所述重传次数计数器加一。
可选的，所述更新发送窗口包括：
将发送窗口的下边界更新到下一个未被所有终端确认的序列号SN处或分段处；或者，
将发送窗口的下边界更新到下一个重传定时器未超时的未被所有终端确认的SN处或分段处；或者，
将发送窗口的下边界更新到下一个重传次数计数器的数值未达到最大重传次数的未被所有终端确认的SN处或分段处；
根据所述发送窗口的下边界确定所述发送窗口的上边界。
需要说明的是，发送窗口的下边界初值为0，每次被所有UE确认或者定时器超时或者达到最大重传次数，则更新下边界到下一个没有满足前面三个条件的SN处，上边界为下边界数值+SN空间一半。例如，SN长度12bit时，SN空间一半为2048。
在本申请实施例中，通过使用多播AM方式进行业务传输，使网络侧设备进行发送窗口的自行更新，允许个别UE传输质量差，为有很高的业务可靠性要求的数据在确保高资源效率下提供更好的QoS保障，有利于保障网络资源效率，在确保系统效率的基础上极大提升UE的MBS业务接收体验。
在一些可选的实施例中，所述多播业务的确认模式传输方法，还包括：
为多播业务MBS的一个承载配置确认模式AM传输，并配置所述AM传输的最大反馈次数和/或反馈定时器的长度。
可以理解的是，网络侧设备为终端配置AM传输的最大反馈次数，和/或，反馈定时器的长度，以使得终端根据最大反馈次数和/或反馈定时器的长度，进行接收窗口的更新，从而不会因为一个UE链路特别恶化而影响到其他链路情况良好的UE的多播业务的接收，可以在确保系统效率的基础上极大提升UE的MBS业务接收体验。
在一些可选的实施例中，所述多播业务的确认模式传输方法，还包括：
在接收到终端发送的状态报告中携带NACK_SN信息且所述NACK_SN信息位于发送窗口之外的情况下，执行以下各项中的一项：
对发送窗口之外的gap处的数据不予重传；
若发送窗口之外的gap处的数据的重传次数未达到最大重传次数，则利用PTP传输路径进行重传；
对发送窗口之外的gap处的数据不使用PTM传输路径进行重传，使用PTP传输路径进行重传。
可以理解的是，网络侧设备也可能会接收到终端发送的状态报告中携带位于发送窗口之外的NACK_SN信息，对于位于发送窗口之外的NACK_SN信息所表示的gap处的数据可以采用如下几种方式中的任一种进行处理：
对发送窗口之外的gap处的数据不予重传；
若发送窗口之外的gap处的数据的重传次数未达到最大重传次数，则利用PTP传输路径进行重传；
对发送窗口之外的gap处的数据不使用PTM传输路径进行重传，使用PTP传输路径进行重传。
在本申请实施例中，给出了网络侧对于发送窗口之外的数据的处理方式，为有很高的业务可靠性要求的数据在确保高资源效率下提供更好的QoS保障，有利于保障网络资源效率，在确保系统效率的基础上极大提升UE的MBS业务接收体验。
特别的，对于个别UE如果链路质量过于差，导致耽误了整体多播的进度，则网络侧设备可以选择为该UE建立独立的Unicast方式进行多播业务的传输，即为该MRB建立独立于其它UE的PDCP和RLC实体，或者与其它UE common PDCP实体但是独立的RLC实体，进行独立传输，以同时确保单个UE和整体多播传输效果。
在一些可选的实施例中，所述多播业务的确认模式传输方法，还包括：
对不适合进行多播传输的终端进行重配置，使用PTP RLC/PDCP确认模式实体进行多播传输；
其中，所述不适合进行多播传输的终端包括以下各项中的一项：
在预设时长范围未接收到终端反馈的确认消息；
针对终端的一个共用协议层PDU或者分段，重传达到了最大次数，仍然无法接收到所述终端反馈的确认消息；
终端的多播信道的测量或者反馈低于预设门限，或者，单播信道的测量或者反馈低于预设门限；
其他不适合进行多播传输的终端情形。
特别地，本实施例中，不在UE侧引入任何的更新机制，UE按照现有单播AM的机制进行操作。在网络侧，找出对于不能满足多播AM传输进度的UE，进行重配置，将其使用单独的RLC实体进行多播业务传输。网络侧挑选配置独立实体的条件如下一条或者组合：
如果某个UE，并不能在一定的时长范围内，完成一个PDU的传输，即没有收到对应RLC ACK，则判定其需要配置独立RLC单播实体进行传输；
如果某个UE，对于一个PDU或者分段，重传达到了最大次数，仍旧没有成功，即没有收到对应RLC ACK，则判定其需要配置独立RLC单播实体进行传输；
如果某个UE，它的链路质量较差，例如多播信道的测量或者反馈，或者单播信道的测量或者反馈，低于一定的门限，则判定其需要配置独立RLC单播实体进行传输；
其他不适合进行多播传输的终端情形，例如这个UE与其它UE不在一个方向，不利于网络侧多播传输的调度，则判定其需要配置独立RLC单播实体进行传输。
当网络侧将所有不适合进行多播AM传输的UE都剔除出去，则网络侧可以确保对现有的多播RLC AM范围内的UE，不能有任何一个gap，与现有收发端处理类似，只有全部UEACK之后才会认为成功，即更新窗口。
在上述实施例的基础上，所述对不适合进行多播传输的终端进行重配置，包括：
为不适合进行多播传输的终端建立独立于配置了多播确认模式的其他终端的PDCP实体和RLC实体；或者，
为所述不适合进行多播传输的终端建立独立的RLC实体，所述不适合进行多播传输的终端与配置了多播确认模式的其他终端共用PDCP实体。
在本申请实施例中，通过对不适合进行多播传输的UE进行重配置，使这些UE通过单独的RLC实体进行多播业务传输，为有很高的业务可靠性要求的数据在确保高资源效率下提供更好的QoS保障，有利于保障网络资源效率，在确保系统效率的基础上极大提升UE的MBS业务接收体验。
需要说明的是，本申请实施例提供的多播业务的确认模式传输方法，执行主体可以为多播业务的确认模式传输装置，或者，该多播业务的确认模式传输装置中的用于执行多播业务的确认模式传输方法的控制模块。本申请实施例中以多播业务的确认模式传输装置执多播业务的确认模式传输方法为例，说明本申请实施例提供的多播业务的确认模式传输装置。
图6为本申请实施例提供的多播业务的确认模式传输装置的结构示意图之一，该装置应用于终端，包括：数据接收单元610和状态反馈单元620，其中，
数据接收单元610，用于通过点到多点PTM传输路径接收网络侧设备发送的多播业务MBS数据；
状态反馈单元620，用于基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告。
在本申请实施例中，通过为接收高可靠性多播业务的UE配置PTM传输路径和PTP传输路径，实现了多播AM传输，既保障了多播调度的高资源效率也能够同时提升接收的可靠性，在提升终端接收MBS业务的服务质量和体验的基础上，进一步提升系统效率。
可选的，所述PTP传输路径和PTM传输路径共用无线链路控制RLC层实体，在RLC层执行确认模式AM；或者，
所述PTP传输路径和PTM传输路径共用分组数据汇聚协议PDCP层实体，在PDCP层执行确认模式AM。
可选的，所述多播业务的确认模式传输装置还包括：
接收窗口更新单元，用于在所述状态报告的反馈满足第一预设条件的情况下，更新接收窗口；
其中，所述第一预设条件包括以下至少一项：
反馈次数计数器的数值达到或超过最大反馈次数；
反馈定时器超时。
可选的，所述多播业务的确认模式传输装置还包括：
配置信息接收单元，用于接收网络侧设备配置的AM传输的最大反馈次数，和/或，接收网络侧设备配置的AM传输的反馈定时器的长度。
可选的，所述状态反馈单元620用于：
在确定存在接收缺口gap的情况下，通过PTP传输路径向网络侧设备反馈状态报告，所述状态报告中携带NACK_SN信息，所述NACK_SN信息为所述接收gap处的数据的序列号SN和/或SN分段信息。
可选的，所述反馈次数计数器的更新，包括：
以共用协议层协议数据单元PDU序列号SN为粒度，每当一个共用协议层PDU SN被作为状态报告中的NACK_SN信息时，所述反馈次数计数器加一；或者，
以共用协议层PDU SN分段为粒度，每当一个共用协议层PDU SN分段被作为状态报告中的NACK_SN信息时，所述反馈次数计数器加一。
可选的，所述反馈定时器的粒度，包括：
对每个共用协议层PDU，维护一个独立的反馈定时器；或者，
对每个共用协议层PDU分段，维护一个独立的反馈定时器；或者，
对一次重组定时器范围内新增的gap处的共用协议层PDU和分段合集，维护一个反馈定时器；或者，
对所有当前经过了重组定时器超时的gap处的共用协议层PDU和分段合集，维护一个反馈定时器。
可选的，所述反馈定时器的初始启动点包括：
在第一次检测到接收gap时；或者，
在第一次经过了重组定时器超时，所述接收gap仍然存在；或者，
所述状态报告的第一次发送时刻。
可选的，所述多播业务的确认模式传输装置，还包括：
第一处理单元，用于若接收到的新多播数据包的SN位于接收窗口之内，则进行重排序和重复检测判断，若存在重复的数据包，则删除所述重复的数据包，若存在非重复的数据包，则利用所述非重复数据包填补所述接收gap；
第二处理单元，用于若接收到的新多播数据包的SN位于接收窗口之外，则将所述接收窗口的上边界更新为所述新多播数据包的SN加一，并根据所述上边界确定下边界。
其中，所述接收窗口的上边界初始值为零，或者，所述接收窗口的上边界初始值为接收到的第一个数据包的SN加一。
在本申请实施例中，通过使用多播AM方式进行业务传输，使UE侧进行接收窗口的自行更新，为有很高的业务可靠性要求的数据在确保高资源效率下提供更好的QoS保障，有利于保障网络资源效率，在确保系统效率的基础上极大提升UE的MBS业务接收体验。
本申请实施例中的多播业务的确认模式传输装置可以是装置，也可以是终端中的部件、集成电路、或芯片。该装置可以是移动终端，也可以为非移动终端。示例性的，移动终端可以包括但不限于上述所列举的终端11的类型，非移动终端可以为服务器、网络附属存储器(Network Attached Storage，NAS)、个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。
本申请实施例中的多播业务的确认模式传输装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。
本申请实施例提供的多播业务的确认模式传输装置能够实现图2至图4的方法实施例实现的各个过程，并达到相同的技术效果，为避免重复，这里不再赘述。
图7为本申请实施例提供的多播业务的确认模式传输装置的结构示意图之二，该装置应用于网络侧设备，包括：数据发送单元710和状态接收单元720，其中，
数据发送单元710，用于通过点到多点PTM传输路径向多个终端发送多播业务MBS数据；
状态接收单元720，用于通过点到点PTP传输路径接收所述多个终端反馈的状态报告。
本申请实施例中，网络侧设备使用多播AM方式进行业务传输，为有很高的业务可靠性要求的数据在确保高资源效率下提供更好的QoS保障，有利于保障网络资源效率，在确保系统效率的基础上大大提升UE的MBS业务接收体验。
可选的，所述PTP传输路径和PTM传输路径共用无线链路控制RLC层实体，在RLC层执行确认模式AM；或者，
所述PTP传输路径和PTM传输路径共用分组数据汇聚协议PDCP层实体，在PDCP层执行确认模式AM。
可选的，所述多播业务的确认模式传输装置，还包括：
数据重传单元，用于在接收到至少一个终端的状态报告中携带NACK_SN信息的情况下，通过PTP传输路径和/或PTM传输路径对所述NACK_SN处的数据进行重传；
其中，所述NACK_SN信息为接收gap处的数据的序列号SN和/或SN分段信息。
可选的，所述多播业务的确认模式传输装置，还包括：
发送窗口更新单元，用于在接收到所有终端的状态报告中均仅包含ACK_SN的情况下，更新发送窗口；或者，
在满足第二预设条件的情况下，更新发送窗口；
其中，所述满足第二预设条件包括以下至少一项：
重传定时器超时；
重传次数计数器的数值达到或超过最大重传次数。
可选的，所述多播业务的确认模式传输装置，还包括：
配置单元，用于为多播业务MBS的一个承载配置确认模式AM传输，并配置所述AM传输的最大反馈次数和/或反馈定时器的长度。
可选的，所述重传定时器的启动点包括：
第一次接收到终端的状态报告中携带非确认消息；或者，
第一次重传。
可选的，所述重传定时器的粒度为：
对于每一个共用协议层PDU，维护一个重传定时器；
对于每一个共用协议层PDU分段，维护一个重传定时器；
对于一个区间内的PDU/PDU分段，维护一个重传定时器。
可选的，所述重传次数计数器的更新包括：
对于每个终端的一个共用协议层PDU或PDU分段维护一个重传次数计数器，或者，对于每一个共用协议层PDU或PDU分段维护一个重传次数计数器；
在对所述PDU或PDU分段进行了一次重传时，所述重传次数计数器加一。
可选的，所述更新发送窗口包括：
将发送窗口的下边界更新到下一个未被所有终端确认的序列号SN处或分段处；或者，
将发送窗口的下边界更新到下一个重传定时器未超时的未被所有终端确认的SN处或分段处；或者，
将发送窗口的下边界更新到下一个重传次数计数器的数值未达到最大重传次数的未被所有终端确认的SN处或分段处；
根据所述发送窗口的下边界确定所述发送窗口的上边界。
可选的，所述多播业务的确认模式传输装置，还包括：
第一处理单元，用于在接收到终端发送的状态报告中携带NACK_SN信息且所述NACK_SN信息位于发送窗口之外的情况下，执行以下各项中的一项：
对发送窗口之外的gap处的数据不予重传；
若发送窗口之外的gap处的数据的重传次数未达到最大重传次数，则利用PTP传输路径进行重传；
对发送窗口之外的gap处的数据不使用PTM传输路径进行重传，使用PTP传输路径进行重传。
可选的，所述多播业务的确认模式传输装置，还包括：
第二处理单元，用于对不适合进行多播传输的终端进行重配置，使用PTP RLC/PDCP确认模式实体进行多播传输；
其中，所述不适合进行多播传输的终端包括以下各项中的一项：
在预设时长范围未接收到终端反馈的确认消息；
针对终端的一个共用协议层PDU或者分段，重传达到了最大次数，仍然无法接收到所述终端反馈的确认消息；
终端的多播信道的测量或者反馈低于预设门限，或者，单播信道的测量或者反馈低于预设门限；
其他不适合进行多播传输的终端情形。
可选的，所述对不适合进行多播传输的终端进行重配置，包括：
为不适合进行多播传输的终端建立独立于配置了多播确认模式的其他终端的PDCP实体和RLC实体；或者，
为所述不适合进行多播传输的终端建立独立的RLC实体，所述不适合进行多播传输的终端与配置了多播确认模式的其他终端共用PDCP实体。
在本申请实施例中，通过使用多播AM方式进行业务传输，使网络侧设备进行发送窗口的自行更新，允许个别UE传输质量差，为有很高的业务可靠性要求的数据在确保高资源效率下提供更好的QoS保障，有利于保障网络资源效率，在确保系统效率的基础上极大提升UE的MBS业务接收体验。
本申请实施例中的多播业务的确认模式传输装置可以是装置，也可以是终端中的部件、集成电路、或芯片。该装置可以是移动终端，也可以为非移动终端。示例性的，移动终端可以包括但不限于上述所列举的终端11的类型，非移动终端可以为服务器、网络附属存储器(Network Attached Storage，NAS)、个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。
本申请实施例中的多播业务的确认模式传输装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。
本申请实施例提供的多播业务的确认模式传输装置能够实现图5的方法实施例实现的各个过程，并达到相同的技术效果，为避免重复，这里不再赘述。
可选的，如图8所示，本申请实施例还提供一种通信设备800，包括处理器801，存储器802，存储在存储器802上并可在所述处理器801上运行的程序或指令，例如，该通信设备800为终端时，该程序或指令被处理器801执行时实现上述多播业务的确认模式传输方法实施例的各个过程，且能达到相同的技术效果。该通信设备800为网络侧设备时，该程序或指令被处理器801执行时实现上述多播业务的确认模式传输方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
图9为实现本申请实施例的一种终端的硬件结构示意图。
该终端900包括但不限于：射频单元901、网络模块902、音频输出单元903、输入单元904、传感器905、显示单元906、用户输入单元907、接口单元908、存储器909、以及处理器910等部件。
本领域技术人员可以理解，终端900还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器910逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图9中示出的终端结构并不构成对终端的限定，终端可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。
应理解的是，本申请实施例中，输入单元904可以包括图形处理器(GraphicsProcessing Unit，GPU)9041和麦克风9042，图形处理器9041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。显示单元906可包括显示面板9061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板9061。用户输入单元907包括触控面板9071以及其他输入设备9072。触控面板9071，也称为触摸屏。触控面板9071可包括触摸检测装置和触摸控制器两个部分。其他输入设备9072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。
本申请实施例中，射频单元901将来自网络侧设备的下行数据接收后，给处理器910处理；另外，将上行的数据发送给网络侧设备。通常，射频单元901包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。
存储器909可用于存储软件程序或指令以及各种数据。存储器909可主要包括存储程序或指令区和存储数据区，其中，存储程序或指令区可存储操作系统、至少一个功能所需的应用程序或指令(比如声音播放功能、图像播放功能等)等。此外，存储器909可以包括高速随机存取存储器，还可以包括非易失性存储器，其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。
处理器910可包括一个或多个处理单元；可选的，处理器910可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序或指令等，调制解调处理器主要处理无线通信，如基带处理器。可以理解的是，上述调制解调处理器也可以不集成到处理器910中。
其中，射频单元901，用于通过点到多点PTM传输路径接收网络侧设备发送的多播业务MBS数据；
处理器910，用于基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告。
在本申请实施例中，通过为接收高可靠性多播业务的UE配置PTM传输路径和PTP传输路径，实现了多播AM传输，既保障了多播调度的高资源效率也能够同时提升接收的可靠性，在提升终端接收MBS业务的服务质量和体验的基础上，进一步提升系统效率。
可选的，所述PTP传输路径和PTM传输路径共用无线链路控制RLC层实体，在RLC层执行确认模式AM；或者，
所述PTP传输路径和PTM传输路径共用分组数据汇聚协议PDCP层实体，在PDCP层执行确认模式AM。
可选的，处理器910，还用于在所述状态报告的反馈满足第一预设条件的情况下，更新接收窗口；
其中，所述第一预设条件包括以下至少一项：
反馈次数计数器的数值达到或超过最大反馈次数；
反馈定时器超时。
可选的，射频单元901还用于接收网络侧设备配置的AM传输的最大反馈次数，和/或，接收网络侧设备配置的AM传输的反馈定时器的长度。
可选的，所述基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告，包括：
在确定存在接收缺口gap的情况下，通过PTP传输路径向网络侧设备反馈状态报告，所述状态报告中携带NACK_SN信息，所述NACK_SN信息为所述接收gap处的数据的序列号SN和/或SN分段信息。
可选的，所述反馈次数计数器的更新，包括：
以共用协议层协议数据单元PDU序列号SN为粒度，每当一个共用协议层PDU SN被作为状态报告中的NACK_SN信息时，所述反馈次数计数器加一；或者，
以共用协议层PDU SN分段为粒度，每当一个共用协议层PDU SN分段被作为状态报告中的NACK_SN信息时，所述反馈次数计数器加一。
可选的，所述反馈定时器的粒度，包括：
对每个共用协议层PDU，维护一个独立的反馈定时器；或者，
对每个共用协议层PDU分段，维护一个独立的反馈定时器；或者，
对一次重组定时器范围内新增的gap处的共用协议层PDU和分段合集，维护一个反馈定时器；或者，
对所有当前经过了重组定时器超时的gap处的共用协议层PDU和分段合集，维护一个反馈定时器。
可选的，所述反馈定时器的初始启动点包括：
在第一次检测到接收gap时；或者，
在第一次经过了重组定时器超时，所述接收gap仍然存在；或者，
所述状态报告的第一次发送时刻。
在本申请实施例中，通过使用多播AM方式进行业务传输，使UE侧进行接收窗口的自行更新，为有很高的业务可靠性要求的数据在确保高资源效率下提供更好的QoS保障，有利于保障网络资源效率，在确保系统效率的基础上极大提升UE的MBS业务接收体验。
可选的，处理器910还用于：若接收到的新多播数据包的SN位于接收窗口之内，则进行重排序和重复检测判断，若存在重复的数据包，则删除所述重复的数据包，若存在非重复的数据包，则利用所述非重复数据包填补所述接收gap；
若接收到的新多播数据包的SN位于接收窗口之外，则将所述接收窗口的上边界更新为所述新多播数据包的SN加一，并根据所述上边界确定下边界。
其中，所述接收窗口的上边界初始值为零，或者，所述接收窗口的上边界初始值为接收到的第一个数据包的SN加一。
本申请实施例还提供了一种网络侧设备。如图10所示，该网络设备1000包括：天线1001、射频装置1002、基带装置1003。天线1001与射频装置1002连接。在上行方向上，射频装置1002通过天线1001接收信息，将接收的信息发送给基带装置1003进行处理。在下行方向上，基带装置1003对要发送的信息进行处理，并发送给射频装置1002，射频装置1002对收到的信息进行处理后经过天线1001发送出去。
上述频带处理装置可以位于基带装置1003中，以上实施例中网络侧设备执行的方法可以在基带装置1003中实现，该基带装置1003包括处理器1004和存储器1005。
基带装置1003例如可以包括至少一个基带板，该基带板上设置有多个芯片，如图10所示，其中一个芯片例如为处理器1004，与存储器1005连接，以调用存储器1005中的程序，执行以上方法实施例中所示的网络设备操作。
该基带装置1003还可以包括网络接口1006，用于与射频装置1002交互信息，该接口例如为通用公共无线接口(common public radio interface，简称CPRI)。
具体地，本发明实施例的网络侧设备还包括：存储在存储器1005上并可在处理器1004上运行的指令或程序，处理器1004调用存储器1005中的指令或程序执行图7所示各模块执行的方法，并达到相同的技术效果，为避免重复，故不在此赘述。
本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述多播业务的确认模式传输方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
其中，所述处理器为上述实施例中所述的终端中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。
本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行网络侧设备程序或指令，实现上述多播业务的确认模式传输方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
应理解，本申请实施例提到的芯片还可以称为系统级芯片，系统芯片，芯片系统或片上系统芯片等。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。
上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (41)

1.一种多播业务的确认模式传输方法，应用于终端，其特征在于，包括：
通过点到多点PTM传输路径接收网络侧设备发送的多播业务MBS数据；
基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告；
所述PTP传输路径和PTM传输路径共用分组数据汇聚协议PDCP层实体，在PDCP层执行确认模式AM，所述PDCP层实体具有丢包检测和触发状态报告的能力。
2.根据权利要求1所述的多播业务的确认模式传输方法，其特征在于，还包括：
在所述状态报告的反馈满足第一预设条件的情况下，更新接收窗口；
其中，所述第一预设条件包括以下至少一项：
反馈次数计数器的数值达到或超过最大反馈次数；
反馈定时器超时。
3.根据权利要求2所述的多播业务的确认模式传输方法，其特征在于，还包括：
接收网络侧设备配置的AM传输的最大反馈次数，和/或，接收网络侧设备配置的AM传输的反馈定时器的长度。
4.根据权利要求1所述的多播业务的确认模式传输方法，其特征在于，所述基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告，包括：
在确定存在接收缺口gap的情况下，通过PTP传输路径向网络侧设备反馈状态报告，所述状态报告中携带NACK_SN信息，所述NACK_SN信息为所述接收gap处的数据的序列号SN和/或SN分段信息。
5.根据权利要求2所述的多播业务的确认模式传输方法，其特征在于，所述反馈次数计数器的更新，包括：
以共用协议层协议数据单元PDU序列号SN为粒度，每当一个共用协议层PDU SN被作为状态报告中的NACK_SN信息时，所述反馈次数计数器加一；或者，
以共用协议层PDU SN分段为粒度，每当一个共用协议层PDU SN分段被作为状态报告中的NACK_SN信息时，所述反馈次数计数器加一。
6.根据权利要求2所述的多播业务的确认模式传输方法，其特征在于，所述反馈定时器的粒度，包括：
对每个共用协议层PDU，维护一个独立的反馈定时器；或者，
对每个共用协议层PDU分段，维护一个独立的反馈定时器；或者，
对一次重组定时器范围内新增的gap处的共用协议层PDU和分段合集，维护一个反馈定时器；或者，
对所有当前经过了重组定时器超时的gap处的共用协议层PDU和分段合集，维护一个反馈定时器。
7.根据权利要求2所述的多播业务的确认模式传输方法，其特征在于，所述反馈定时器的初始启动点包括：
在第一次检测到接收gap时；或者，
在第一次经过了重组定时器超时，所述接收gap仍然存在；或者，
所述状态报告的第一次发送时刻。
8.根据权利要求1所述的多播业务的确认模式传输方法，其特征在于，还包括：
若接收到的新多播数据包的SN位于接收窗口之内，则进行重排序和重复检测判断，若存在重复的数据包，则删除所述重复的数据包，若存在非重复的数据包，则利用所述非重复的数据包填补接收gap；
若接收到的新多播数据包的SN位于接收窗口之外，则将所述接收窗口的上边界更新为所述新多播数据包的SN加一，并根据所述上边界确定下边界；
其中，所述接收窗口的上边界初始值为零，或者，所述接收窗口的上边界初始值为接收到的第一个数据包的SN加一。
9.一种多播业务的确认模式传输方法，应用于网络侧设备，其特征在于，包括：
通过点到多点PTM传输路径向多个终端发送多播业务MBS数据；
通过点到点PTP传输路径接收所述多个终端反馈的状态报告；
所述PTP传输路径和PTM传输路径共用分组数据汇聚协议PDCP层实体，在PDCP层执行确认模式AM，所述PDCP层实体具有丢包检测和触发状态报告的能力。
10.根据权利要求9所述的多播业务的确认模式传输方法，其特征在于，还包括：
在接收到至少一个终端的状态报告中携带NACK_SN信息的情况下，通过PTP传输路径和/或PTM传输路径对所述NACK_SN处的数据进行重传；
其中，所述NACK_SN信息为接收gap处的数据的序列号SN和/或SN分段信息。
11.根据权利要求9所述的多播业务的确认模式传输方法，其特征在于，还包括：
在接收到所有终端的状态报告中均仅包含ACK_SN的情况下，更新发送窗口；或者，
在满足第二预设条件的情况下，更新发送窗口；
其中，所述满足第二预设条件包括以下至少一项：
重传定时器超时；
重传次数计数器的数值达到或超过最大重传次数。
12.根据权利要求11所述的多播业务的确认模式传输方法，其特征在于，还包括：
为多播业务MBS的一个承载配置确认模式AM传输，并配置所述AM传输的最大反馈次数和/或反馈定时器的长度。
13.根据权利要求11所述的多播业务的确认模式传输方法，其特征在于，所述重传定时器的启动点包括：
第一次接收到终端的状态报告中携带非确认消息；或者，
第一次重传。
14.根据权利要求11所述的多播业务的确认模式传输方法，其特征在于，所述重传定时器的粒度为：
对于每一个共用协议层PDU，维护一个重传定时器；
对于每一个共用协议层PDU分段，维护一个重传定时器；
对于一个区间内的PDU/PDU分段，维护一个重传定时器。
15.根据权利要求11所述的多播业务的确认模式传输方法，其特征在于，所述重传次数计数器的更新包括：
对于每个终端的一个共用协议层PDU或PDU分段维护一个重传次数计数器，或者，对于每一个共用协议层PDU或PDU分段维护一个重传次数计数器；
在对所述PDU或PDU分段进行了一次重传时，所述重传次数计数器加一。
16.根据权利要求11所述的多播业务的确认模式传输方法，其特征在于，所述更新发送窗口包括：
将发送窗口的下边界更新到下一个未被所有终端确认的序列号SN处或分段处；或者，
将发送窗口的下边界更新到下一个重传定时器未超时的未被所有终端确认的SN处或分段处；或者，
将发送窗口的下边界更新到下一个重传次数计数器的数值未达到最大重传次数的未被所有终端确认的SN处或分段处；
根据所述发送窗口的下边界确定所述发送窗口的上边界。
17.根据权利要求9所述的多播业务的确认模式传输方法，其特征在于，还包括：
在接收到终端发送的状态报告中携带NACK_SN信息且所述NACK_SN信息位于发送窗口之外的情况下，执行以下各项中的一项：
对发送窗口之外的gap处的数据不予重传；
若发送窗口之外的gap处的数据的重传次数未达到最大重传次数，则利用PTP传输路径进行重传；
对发送窗口之外的gap处的数据不使用PTM传输路径进行重传，使用PTP传输路径进行重传。
18.根据权利要求9所述的多播业务的确认模式传输方法，其特征在于，还包括：
对不适合进行多播传输的终端进行重配置，使用PTP RLC/PDCP确认模式实体进行多播传输；
其中，所述不适合进行多播传输的终端包括以下各项中的一项：
在预设时长范围未接收到终端反馈的确认消息；
针对终端的一个共用协议层PDU或者分段，重传达到了最大次数，仍然无法接收到所述终端反馈的确认消息；
终端的多播信道的测量或者反馈低于预设门限，或者，单播信道的测量或者反馈低于预设门限；
其他不适合进行多播传输的终端情形。
19.根据权利要求18所述的多播业务的确认模式传输方法，其特征在于，所述对不适合进行多播传输的终端进行重配置，包括：
为不适合进行多播传输的终端建立独立于配置了多播确认模式的其他终端的PDCP实体和RLC实体；或者，
为所述不适合进行多播传输的终端建立独立的RLC实体，所述不适合进行多播传输的终端与配置了多播确认模式的其他终端共用PDCP实体。
20.一种多播业务的确认模式传输装置，应用于终端，其特征在于，包括：
数据接收单元，用于通过点到多点PTM传输路径接收网络侧设备发送的多播业务MBS数据；
状态反馈单元，用于基于所述多播业务数据的接收情况，通过点到点PTP传输路径向所述网络侧设备反馈状态报告；
所述PTP传输路径和PTM传输路径共用分组数据汇聚协议PDCP层实体，在PDCP层执行确认模式AM，所述PDCP层实体具有丢包检测和触发状态报告的能力。
21.根据权利要求20所述的多播业务的确认模式传输装置，其特征在于，还包括：
接收窗口更新单元，用于在所述状态报告的反馈满足第一预设条件的情况下，更新接收窗口；
其中，所述第一预设条件包括以下至少一项：
反馈次数计数器的数值达到或超过最大反馈次数；
反馈定时器超时。
22.根据权利要求21所述的多播业务的确认模式传输装置，其特征在于，还包括：
配置信息接收单元，用于接收网络侧设备配置的AM传输的最大反馈次数，和/或，接收网络侧设备配置的AM传输的反馈定时器的长度。
23.根据权利要求20所述的多播业务的确认模式传输装置，其特征在于，所述状态反馈单元，用于：
在确定存在接收缺口gap的情况下，通过PTP传输路径向网络侧设备反馈状态报告，所述状态报告中携带NACK_SN信息，所述NACK_SN信息为所述接收gap处的数据的序列号SN和/或SN分段信息。
24.根据权利要求21所述的多播业务的确认模式传输装置，其特征在于，所述反馈次数计数器的更新，包括：
以共用协议层协议数据单元PDU序列号SN为粒度，每当一个共用协议层PDU SN被作为状态报告中的NACK_SN信息时，所述反馈次数计数器加一；或者，
以共用协议层PDU SN分段为粒度，每当一个共用协议层PDU SN分段被作为状态报告中的NACK_SN信息时，所述反馈次数计数器加一。
25.根据权利要求21所述的多播业务的确认模式传输装置，其特征在于，所述反馈定时器的粒度，包括：
对每个共用协议层PDU，维护一个独立的反馈定时器；或者，
对每个共用协议层PDU分段，维护一个独立的反馈定时器；或者，
对一次重组定时器范围内新增的gap处的共用协议层PDU和分段合集，维护一个反馈定时器；或者，
对所有当前经过了重组定时器超时的gap处的共用协议层PDU和分段合集，维护一个反馈定时器。
26.根据权利要求21所述的多播业务的确认模式传输装置，其特征在于，所述反馈定时器的初始启动点包括：
在第一次检测到接收gap时；或者，
在第一次经过了重组定时器超时，所述接收gap仍然存在；或者，
所述状态报告的第一次发送时刻。
27.根据权利要求20所述的多播业务的确认模式传输装置，其特征在于，还包括：
第一处理单元，用于若接收到的新多播数据包的SN位于接收窗口之内，则进行重排序和重复检测判断，若存在重复的数据包，则删除所述重复的数据包，若存在非重复的数据包，则利用所述非重复的数据包填补接收gap；
第二处理单元，用于若接收到的新多播数据包的SN位于接收窗口之外，则将所述接收窗口的上边界更新为所述新多播数据包的SN加一，并根据所述上边界确定下边界；
其中，所述接收窗口的上边界初始值为零，或者，所述接收窗口的上边界初始值为接收到的第一个数据包的SN加一。
28.一种多播业务的确认模式传输装置，应用于网络侧设备，其特征在于，包括：
数据发送单元，用于通过点到多点PTM传输路径向多个终端发送多播业务MBS数据；
状态接收单元，用于通过点到点PTP传输路径接收所述多个终端反馈的状态报告；
所述PTP传输路径和PTM传输路径共用分组数据汇聚协议PDCP层实体，在PDCP层执行确认模式AM，所述PDCP层实体具有丢包检测和触发状态报告的能力。
29.根据权利要求28所述的多播业务的确认模式传输装置，其特征在于，还包括：
数据重传单元，用于在接收到至少一个终端的状态报告中携带NACK_SN信息的情况下，通过PTP传输路径和/或PTM传输路径对所述NACK_SN处的数据进行重传；
其中，所述NACK_SN信息为接收gap处的数据的序列号SN和/或SN分段信息。
30.根据权利要求28所述的多播业务的确认模式传输装置，其特征在于，还包括：
发送窗口更新单元，用于在接收到所有终端的状态报告中均仅包含ACK_SN的情况下，更新发送窗口；或者，
在满足第二预设条件的情况下，更新发送窗口；
其中，所述满足第二预设条件包括以下至少一项：
重传定时器超时；
重传次数计数器的数值达到或超过最大重传次数。
31.根据权利要求30所述的多播业务的确认模式传输装置，其特征在于，还包括：
配置单元，用于为多播业务MBS的一个承载配置确认模式AM传输，并配置所述AM传输的最大反馈次数和/或反馈定时器的长度。
32.根据权利要求30所述的多播业务的确认模式传输装置，其特征在于，所述重传定时器的启动点包括：
第一次接收到终端的状态报告中携带非确认消息；或者，
第一次重传。
33.根据权利要求30所述的多播业务的确认模式传输装置，其特征在于，所述重传定时器的粒度为：
对于每一个共用协议层PDU，维护一个重传定时器；
对于每一个共用协议层PDU分段，维护一个重传定时器；
对于一个区间内的PDU/PDU分段，维护一个重传定时器。
34.根据权利要求30所述的多播业务的确认模式传输装置，其特征在于，所述重传次数计数器的更新包括：
对于每个终端的一个共用协议层PDU或PDU分段维护一个重传次数计数器，或者，对于每一个共用协议层PDU或PDU分段维护一个重传次数计数器；
在对所述PDU或PDU分段进行了一次重传时，所述重传次数计数器加一。
35.根据权利要求30所述的多播业务的确认模式传输装置，其特征在于，所述更新发送窗口包括：
将发送窗口的下边界更新到下一个未被所有终端确认的序列号SN处或分段处；或者，
将发送窗口的下边界更新到下一个重传定时器未超时的未被所有终端确认的SN处或分段处；或者，
将发送窗口的下边界更新到下一个重传次数计数器的数值未达到最大重传次数的未被所有终端确认的SN处或分段处；
根据所述发送窗口的下边界确定所述发送窗口的上边界。
36.根据权利要求28所述的多播业务的确认模式传输装置，其特征在于，还包括：
第一处理单元，用于在接收到终端发送的状态报告中携带NACK_SN信息且所述NACK_SN信息位于发送窗口之外的情况下，执行以下各项中的一项：
对发送窗口之外的gap处的数据不予重传；
若发送窗口之外的gap处的数据的重传次数未达到最大重传次数，则利用PTP传输路径进行重传；
对发送窗口之外的gap处的数据不使用PTM传输路径进行重传，使用PTP传输路径进行重传。
37.根据权利要求28所述的多播业务的确认模式传输装置，其特征在于，还包括：
第二处理单元，用于对不适合进行多播传输的终端进行重配置，使用PTP RLC/PDCP确认模式实体进行多播传输；
其中，所述不适合进行多播传输的终端包括以下各项中的一项：
在预设时长范围未接收到终端反馈的确认消息；
针对终端的一个共用协议层PDU或者分段，重传达到了最大次数，仍然无法接收到所述终端反馈的确认消息；
终端的多播信道的测量或者反馈低于预设门限，或者，单播信道的测量或者反馈低于预设门限；
其他不适合进行多播传输的终端情形。
38.根据权利要求37所述的多播业务的确认模式传输装置，其特征在于，所述对不适合进行多播传输的终端进行重配置，包括：
为不适合进行多播传输的终端建立独立于配置了多播确认模式的其他终端的PDCP实体和RLC实体；或者，
为所述不适合进行多播传输的终端建立独立的RLC实体，所述不适合进行多播传输的终端与配置了多播确认模式的其他终端共用PDCP实体。
39.一种终端，其特征在于，包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1-8任一项所述的多播业务的确认模式传输方法的步骤。
40.一种网络侧设备，其特征在于，包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求9-19任一项所述的多播业务的确认模式传输方法的步骤。
41.一种可读存储介质，其特征在于，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如权利要求1-8任一项所述的多播业务的确认模式传输方法的步骤，或者实现如权利要求9-19任一项所述的多播业务的确认模式传输方法的步骤。
CN202011460558.XA 2020-12-11 2020-12-11 多播业务的确认模式传输方法、装置、设备及存储介质 Active CN114630283B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202011460558.XA CN114630283B (zh) 2020-12-11 2020-12-11 多播业务的确认模式传输方法、装置、设备及存储介质
PCT/CN2021/135983 WO2022121876A1 (zh) 2020-12-11 2021-12-07 多播业务的确认模式传输方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011460558.XA CN114630283B (zh) 2020-12-11 2020-12-11 多播业务的确认模式传输方法、装置、设备及存储介质

Publications (2)

Publication Number Publication Date
CN114630283A CN114630283A (zh) 2022-06-14
CN114630283B true CN114630283B (zh) 2023-06-23

Family

ID=81894961

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011460558.XA Active CN114630283B (zh) 2020-12-11 2020-12-11 多播业务的确认模式传输方法、装置、设备及存储介质

Country Status (2)

Country Link
CN (1) CN114630283B (zh)
WO (1) WO2022121876A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117395311A (zh) * 2022-07-05 2024-01-12 中兴通讯股份有限公司 报文处理方法及其装置、存储介质、程序产品

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104836646B (zh) * 2014-02-12 2018-03-23 普天信息技术研究院有限公司 一种rlc am模式传输可靠性增强方法
CN109792587B (zh) * 2016-09-29 2021-02-12 华为技术有限公司 一种多播业务的发送方法和设备
US11134469B2 (en) * 2018-08-21 2021-09-28 Qualcomm Incorporated Reliability for multicast transmissions
CN111901765A (zh) * 2020-04-27 2020-11-06 中兴通讯股份有限公司 模式配置方法、装置、设备和存储介质
CN114071372B (zh) * 2020-08-07 2023-04-07 大唐移动通信设备有限公司 多播广播业务mbs传输方法、终端及网络设备

Also Published As

Publication number Publication date
CN114630283A (zh) 2022-06-14
WO2022121876A1 (zh) 2022-06-16

Similar Documents

Publication Publication Date Title
US7940771B2 (en) Apparatus and method for requesting packet retransmission in a wireless communication system
EP4044478A1 (en) Harq process management method and apparatus, terminal, and storage medium
US8830944B1 (en) Method for acknowledging RLC data packet transmission and RLC AM entity sender
EP3410623B1 (en) Method for sending status information in mobile telecommunications system and receiver of mobile telecommunications
JP4772904B2 (ja) 移動通信システムにおける状態報告の送受信方法及び装置
US7773524B2 (en) Apparatus and method for using automatic repeat request scheme in a broadband wireless access communication system
US8306061B2 (en) Method for retransmitting data unit using delivery status information
US9565007B2 (en) Method of receiving a point-to-multipoint service in a wireless communication system
CN115038049B (zh) 多播业务的接收方法、配置方法、终端及网络侧设备
JP2014064319A (ja) 無線通信システムの状態情報送信方法及び受信装置
US10050825B2 (en) Method and equipment for throughput recovery during resumption from outage scenarios
US20080123573A1 (en) Method and apparatus of packet discard in a wireless communications system
KR20090116601A (ko) 광대역 무선 접속 시스템에서의 효율적인 Ｈｙｂｒｉｄ ＡＲＱ 및 ＡＲＱ 동작 방안
KR20090101793A (ko) 이동 통신 시스템에서 매체 접근 제어 프로토콜 데이터유닛의 전송 성공 여부 판단 방법 및 장치
KR20080111396A (ko) 이동통신 시스템에서의 무선자원 향상 방법, 상태정보 보고방법 및 수신장치
US8132068B2 (en) Dual receiving window method and apparatus for automatic retransmission request
CN114630283B (zh) 多播业务的确认模式传输方法、装置、设备及存储介质
KR100849323B1 (ko) 이동 통신 시스템에서 자동 재전송을 수행하는 방법 및 장치
US20230171844A1 (en) Multicast service receiving method, multicast service configuration method, terminal, and network-side device
CN113938438B (zh) 数据处理方法、数据处理装置及第一终端
WO2022089312A1 (zh) 边链路中继系统中的业务维持方法及中继设备、介质
CN116015565B (zh) 数据重传方法、装置、设备及存储介质
Tykhomyrov et al. On ARQ feedback intensity of the IEEE 802.16 ARQ mechanism
WO2023065219A1 (en) Method and apparatus for status reporting for multicast/broadcast service (mbs)
CN118828722A (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