CN108540272A - 信息传输方法及装置 - Google Patents

Abstract

本发明实施例公开了信息传输方法及装置。该方法包括：对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；如果确定接收成功，则向所述基站发送确认接收反馈消息或不进行任何反馈，以使所述基站不再重传所述第一多播业务。利用该方法，克服了现有物联网系统多播传输中无法进行接收状态反馈的问题，由此在多播业务传输时引入了接收状态反馈机制以及重传机制，从而提升了多播业务的传输可靠性，同时也提升了多播业务的业务性能。

Description

信息传输方法及装置

技术领域

本发明实施例涉及通信技术领域，尤其涉及信息传输方法及装置。

背景技术

在网络通信领域的发展中，物联网技术已得到越来越多的关注，如在3GPP Rel-13中，3GPP就定义了多种物联网标准，常见的有机器类型通信(Machine-TypeCommunication，MTC)以及窄带蜂窝物联网(Narrow Band Internet of Things，NB-IoT)等，基于上述标准可以实现物与物之间的连接通信，随着物联网技术的发展，对多播业务的需求越来越强烈，由此在3GPP Rel-14中，对MTC以及NB-IoT进行了下行多播业务的增强，使得基站可以同时向多个用户设备(User Equipment，UE)发送消息数据。

目前，在MTC或NB-IoT中进行下行多播传输时，基站为保证UE能够成功接收其多播业务的消息报文，通常对给定的消息报文根据给定的重复次数进行重复传输，UE侧则保持对下行多播业务重复传输的接收解码。

然而，发明人在对物联网多播技术的研究中，发现基于现有的多播数据传输机制进行多播传输时，存在如下缺陷：对于部分信号覆盖较弱的UE而言，在基站的重复次数达到设定值后，可能依旧无法成功接收消息报文，多数情况下，由于进行多播传输的多播业务往往对UE侧是否准确接收较为敏感，如果重复传输结束后仍存在部分接收失败的UE，则很可能导致多播业务整体性能的恶化。

发明内容

本发明实施例提供了信息传输方法及装置，提升了多播业务的传输可靠性，同时提升了多播业务的业务性能。

第一方面，本发明实施例提供了一种信息传输方法，包括：

对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；

如果确定接收成功，则向所述基站发送确认接收反馈消息或不进行任何反馈。

第二方面，本发明实施例提供了一种信息传输方法，包括：

向UE发送第一多播业务，以使所述UE对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；

如果在预设时间段内没有接收到任何确认失败反馈消息，则不再重传所述第一多播业务。

第三方面，本发明实施例还提供了一种信息传输装置，包括：

业务接收确定模块，用于对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；

信息反馈模块，用于当确定接收成功时，向所述基站发送确认接收反馈消息或不进行任何反馈。

第四方面，本发明实施例又提供了一种信息传输装置，包括：

第一业务发送模块，用于向UE发送第一多播业务，以使所述UE对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；

第一消息处理模块，用于当在预设时间段内没有接收到任何确认失败反馈消息时，不再重传所述第一多播业务。

本发明实施例中提供了信息传输方法及装置，该方法包括：基站侧向UE侧发送第一多播业务；UE侧对基站侧发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收该第一多播业务，当确定接收成功时，向基站侧发送确认接收反馈消息或不进行任何反馈；基站侧如果在预设时间段内没有接收到任何确认失败反馈消息，则不再重传该第一多播业务。利用该方法，克服了现有物联网系统多播传输中无法进行接收状态反馈的问题，由此在多播业务传输时引入了接收状态反馈机制以及重传机制，从而提升了多播业务的传输可靠性，同时也提升了多播业务的业务性能。

附图说明

图1为本发明实施例一提供的一种信息传输方法的流程示意图；

图2为本发明实施例二提供的一种信息传输方法的流程示意图；

图3为本发明实施例三提供的一种信息传输方法的流程示意图；

图4为本发明实施例四提供的一种信息传输方法的流程示意图；

图5为本发明实施例五提供的一种信息传输方法的流程示意图；

图6为本发明实施例六提供的多播业务传输的优选实施例的流程示意图；

图7为本发明实施例七提供的一种信息传输装置的结构框图；

图8为本发明实施例八提供的一种信息传输装置的结构框图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

实施例一

图1为本发明实施例一提供的一种信息传输方法的流程示意图，该方法适用于在物联网的网络系统中对多播业务的接收状态进行反馈的情况，该方法可以由信息传输装置执行，其中该装置可由软件和/或硬件实现，并一般集成在物联网系统中处于某个基站覆盖范围内的UE上。

对于物联网系统，如MTC以及NB-IoT而言，现有的进行下行多播业务传输的过程可以表述如下：基站向覆盖范围内的UE发送多播业务的消息报文(包括控制报文和数据报文)；UE首先接收控制报文并对控制报文进行解码，之后根据解码结果接收多播业务的数据报文。上述多播业务的传输中，UE侧有可能没有成功接收多播业务的数据报文由此影响多播业务的业务性能及传输性能。基于本实施例提供的信息传输方法，可以有效地解决上述问题。

需要说明的是，现有多播业务的传输机制中，基站发送多播业务消息报文(控制报文和数据报文)的过程可概括为：基站首先在单小区多播控制信道(Single Cell-Multicast Control Channel，SC-MCCH)上发送一项或多项多播业务的下行控制消息(Downlink Control Information，DCI)的配置信息；然后在窄物理下行控制信道(NarrowPhysical Downlink Control Channel,NPDCCH)上发送DCI(DCI的配置信息及DCI均可看作控制报文)；最终在窄物理下行共享信道(Narrow Physical Downlink Shared Channel，NPDSCH)上发送下行多播数据信道SC-MTCH携带的下行多播数据报文，其中，DCI中指示了下行多播数据信道SC-MTCH的搜索空间参数等配置信息。此外，UE接收并解码消息报文的过程可概括为：UE首先侦听SC-MCCH的搜索空间获得SC-MCCH中的DCI的配置信息，然后基于该DCI的配置信息在NPDCCH上获得DCI，之后侦听DCI获得NPDSCH上的SC-MTCH搜索空间参数等配置信息，最终在SC-MTCH搜索空间内获得多播业务的数据报文。

如图1所示，本发明实施例一提供的一种信息传输方法，包括如下操作：

可以理解的是，本实施例的下述步骤具体应用在UE侧，可以由配置在UE侧的相应装置执行。

S101、对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务。

在本实施例中，所述第一多播业务具体可指物联网系统中以多播形式传输的业务数据，一般在确定多播业务对应的多播组后，可以由基站发送给覆盖范围内的UE，并仅允许属于上述多播组的UE接收该多播业务。

本实施例可以对第一多播业务的消息报文进行解码分析，其解码分析的具体内容可以是：分析该第一多播业务是否满足UE的接收条件，且可在满足接收条件后接收该第一多播业务并确定是否接收成功。

一般地，如果接收并成功解码了第一多播业务中的业务数据，则可认为成功接收了该第一多播业务；否则可认为该第一多播业务接收失败。需要说明的是，本实施例可采用现有的下行多播传输机制对所述第一多播业务的接收和解码。

S102、如果确定接收成功，则向所述基站发送确认接收反馈消息或不进行任何反馈。

本步骤可以根据预先设定的反馈规则确定是否进行消息反馈，由此在确定接收并成功解码所述第一多播业务的业务数据后，如果反馈规则中允许接收成功时发送反馈消息，则可向基站发送确定接收的反馈消息，如果不允许，则可不进行任何反馈。可选的，本步骤也可以在确定接收并成功解码所述第一多播业务的业务数据后，实时确定是否进行消息反馈，若确定进行消息反馈，则向基站发送反馈消息。

具体地，本实施例可以采用预先设定的反馈机制向基站发送确认接收反馈消息，其反馈机制主要基于无线通信网络中具有的通信层设定，如基于物理层的反馈机制、基于数据链路层的反馈机制、基于无线链路层的反馈机制以及基于数据汇聚层的反馈机制等。

可以理解的是，基站侧可以在发送该第一多播业务后的一个预设时间段内，确定是否接收到确认失败反馈消息，如果该时间段内没有接收到确认失败反馈消息，就无需重传第一多播业务。

本发明实施例一提供的一种信息传输方法，首先解码分析基站发送的第一多播业务；之后根据分析结果确定是否成功接收了该第一多播业务，当确定接收成功时，就向基站发送确定接收的反馈消息或不进行任何反馈。利用该方法，UE侧能够在成功接收第一多播业务后向基站发送接收状态消息，克服了现有物联网系统多播传输中无法进行接收状态反馈的问题，根据其引入的接收状态反馈机制，更好地提升了多播业务的传输可靠性及业务性能。

实施例二

图2为本发明实施例二提供的一种信息传输方法的流程示意图，本发明实施例以上述实施例为基础进行优化，在本实施例中，该方法优化增加了：如果确定接收失败，则向所述基站发送确认失败反馈消息，以使所述基站以单播或多播的方式重传所述第一多播业务。

进一步地，该方法还优化增加了：对基站所发送的第二多播业务进行解码分析，并根据分析结果确定是否为所述第一多播业务的重传多播业务；若确定为重传多播业务，且确定当前状态为以下任意一种或多种：接收成功、配置为单播重传、已收到单播重传的控制消息和使用基于高层的反馈机制，则不再接收重传的多播业务，否则接收所述重传多播业务，并对所述重传多播业务独立解码或对所述重传多播业务和首传的多播业务进行合并解码。

如图2所示，本发明实施例二提供的一种信息传输方法，具体包括如下操作：

S201、对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务。

示例性地，第一多播业务的消息报文包括了控制报文和数据报文，首先对第一多播业务的控制报文进行解码分析，其分析的内容可以有：确定UE自身的多播组编号是否与控制报文中声明的多播组标识匹配，以及确定控制报文中是否将第一多播业务声明为首次传输。当多播组标识相匹配且第一多播业务为首传时，允许接收该第一多播业务的数据报文，最终确定是否成功解码该数据报文，若是，则可认为接收成功，否则认为接收失败。

S202、如果确定接收成功，则向所述基站发送确认接收反馈消息或不进行任何反馈。

示例性地，可在成功接收第一多播业务后选择向基站发送反馈消息或不进行任何反馈。

S203、如果确定接收失败，则向所述基站发送确认失败反馈消息，以使所述基站以单播或多播的方式重传所述第一多播业务。

在本实施例中，当第一多播业务的业务数据解码失败时，可认为所述第一多播业务接收失败，后续可执行本步骤。具体地，可以向基站发送确认失败的反馈消息，以告知基站需要再次重传该多播业务。

本步骤也可以根据设定的反馈机制发送确认失败反馈消息，且该反馈机制可以依据物联网系统中具有的通信层设定，如基于物理层的反馈机制、基于数据链路层的反馈机制又或者基于无线链路层的反馈机制以及基于数据汇聚层的反馈机制等。在本实施例中，所述确认接收反馈消息可看作ACK消息，所述确认失败反馈消息可看作为NACK消息。

S204、对基站所发送的第二多播业务进行解码分析，并根据分析结果确定是否为所述第一多播业务的重传多播业务。

一般地，基站可以发送一项或多项多播业务，UE也可以对多项多播业务的消息报文进行解码分析。在本实施例中，除解码分析上述第一多播业务外，还可以对第二多播业务进行解码分析，如果所述第二多播业务在所述第一多播业务之前到达，则可参考步骤S201至步骤S203的操作来处理所述第二多播业务，但当第二多播业务在所述第一多播业务之后到达时，则需要执行本步骤的操作。

具体地，本步骤仍需对所述第二多播业务进行解码分析，但在确定第二多播业务是否接收成功之前，需要根据分析结果确定该第二多播业务是否为第一多播业务的重传多播业务，且本实施例可通过分析第二多播业务中是否具有重传标识以及第二多播业务对应的身份标识，来确定第二多播业务是否为第一多播业务的重传多播业务。

进一步地，对基站所发送的第二多播业务进行解码分析，并根据分析结果确定是否为所述第一多播业务的重传多播业务包括：

对基站所发送的第二多播业务进行解码分析，确定在所述第二多播业务的控制报文和/或数据报文中声明的传输类型标识；如果根据所述传输类型标识确定本次多播业务为首传，则确定所述第二多播业务不是所述第一多播业务的重传多播业务；如果根据所述传输类型标识确定本次多播业务为重传，则确定所述第二多播业务为所述第一多播业务的重传多播业务。

在本实施例中，所述传输类型标识具体可理解为用于区分多播业务为首次传输(首传)或重复传输(重传)的标识，可在基站向UE发送多播业务时在多播业务的控制报文或消息报文中声明，如将首传的标识声明为0，重传的标识声明为1，本实施优选的在多播业务的控制报文中声明所述传输类型标识。

此外，如果接收第二多播业务时，还存在其他待接收的多播业务时，通过传输类型标识仅能确定所述第二多播业务为重传，无法确定所述第二多播业务是否为第一多播业务的重传多播业务，针对上述问题，本实施例优化增加了下述解决方案：具体地，在对基站所发送的第二多播业务进行解码分析之后，还包括：确定在所述第二多播业务的控制报文和/或数据报文中声明的多播业务身份标识或多播组身份标识；相应的，根据所述传输类型标识以及所述多播业务身份标识或多播组身份标识，确定第二多播业务是否为所述第一多播业务的重传多播业务。

在本实施例中，所述第二多播业务的控制报文中声明的多播业务身份标识或多播组身份标识可以用来确定所述第二多播业务是否与所述第一多播业务具有相同的身份标识，之后如果确定传输类型标识为重传，就可以准确的将所述第二多播业务确定为所述第一多播业务的重传多播业务。

可以理解的是，当第二多播业务为第一多播业务的重传时，可以执行步骤S204；当第二多播业务为新的首传多播业务时，也可以参考步骤S201至步骤S203的操作来处理所述第二多播业务，本实施例不作详述。

S205、若确定为重传多播业务，且确定当前状态为以下任意一种或多种：接收成功、配置为单播重传、已收到单播重传的控制消息和使用基于高层的反馈机制，则不再接收重传的多播业务，否则接收所述重传多播业务，并对所述重传多播业务独立解码或对所述重传多播业务和首传的多播业务进行合并解码。

在本实施例中，在确定第二多播业务为第一多播业务的重传时，本步骤需要进一步判定UE的当前状态，若其当前状态为上述的任意一种或多种时，可以忽略该第二多播业务，不进行任何处理。

其中，所述接收成功可理解为成功接收第一多播业务的数据报文或者已经成功接收第二多播业务进行重传的数据报文；所述配置为单播重传具体可理解为基站确定以单播重传的形式向该UE发送重传多播业务；所述已收到单播重传的控制消息可以理解该UE已接收到该单播重传的控制消息，需要说明的是，基站进行多播重传时，会向多播组中的所有UE发送重传多播业务，因此，成功接收第一多播业务或者已单播接收第二多播业务的UE也会收到多播方式发送的第二多播业务，但此时UE可以选择忽略多播方式发送的第二多播业务。

此外，所述使用基于高层的反馈机制具体可理解为该UE向基站发送反馈消息时所采用的反馈机制是基于除物理层之外的其他通信层实现的。需要说明的是，基站往往设定对基于高层的反馈机制发送反馈消息的进行采用单播重传，因此，本实施例可以在确定使用基于高层的反馈机制发送反馈消息时，同样忽略该第二多播业务。

在本实施例中，在确定接收重传多播业务时，可以独立对该重传多播业务的数据报文进行解码，也可采用将所述重传多播业务和首传的多播业务合并解码方式来实现多播业务数据报文的解码。

可以理解的是，对于解码失败的重传多播业务而言，仍可参考步骤S201至步骤S205的操作对所述重传多播业务进行处理，本实施例不作详述。

本发明实施例二提供的一种信息传输方法，优化增加了当确定接收第一多播业务失败时要进行的具体操作，此时，需要向基站发送确定接收失败的的反馈消息，从而使基站重传该第一多播业务。利用该方法，UE侧能够实时的向基站侧反馈接收状态，从而使基站根据其反馈的接收状态确定是否重传多播业务，更好的提升了多播业务的传输可靠性及业务性能。

实施例三

图3为本发明实施例三提供的一种信息传输方法的流程示意图，本发明实施例在上述实施例基础上进行优化，在本实施例中，向所述基站发送反馈消息优化包括了：基于高层的反馈机制或基于物理层的反馈机制向所述基站发送反馈消息。

在上述优化的基础上，本实施例还进一步增加了：根据基站配置确定使用基于高层的反馈机制或基于物理层的反馈机制；或，根据是否支持高层反馈机制和/或是否处于连接态，决定使用基于高层的反馈机制或基于物理层的反馈机制。

如图3所示，本发明实施例三提供的一种信息传输方法，具体包括如下操作：

S301、对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务。

S302、根据基站配置确定使用基于高层的反馈机制或基于物理层的反馈机制；或，根据是否支持高层反馈机制和/或是否处于连接态，决定使用基于高层的反馈机制或基于物理层的反馈机制。

本实施例中，无论确认接收反馈消息还是确认失败，都可以基于高层的反馈机制或基于物理层的反馈机制向所述基站发送反馈消息，其中，所述基于高层的反馈机制具体可看做基于除物理层之外的其他逻辑层设定的反馈机制。因此，本步骤用于确定待采用的反馈机制。

本实施例中，发送反馈消息时所采用的反馈机制可以由基站预先配置也可以由UE根据自身的条件实时配置。具体地，由基站预先配置各UE所采用的反馈机制时，可以随意决定各UE可采用的反馈机制；或者根据各UE所属的多播组来决定，又或者根据配置时各UE所处的空闲态或连接态来决定。

当由UE根据自身的条件配置时，UE可以根据自身性能来确定是否支持高层的反馈机制，或根据当前的网络状态(如处于连接态)来确定是否支持高层的反馈机制，如果支持，则优先选取高层的反馈机制来发送反馈消息。

与物理层的反馈机制相比，优先选取高层的反馈机制的原因在于可以在反馈消息中灵活的加入基站所需的标识信息，而选择物理层的反馈机制时，基站需要预先设定物理层的反馈机制的标识信息，之后将接收到的反馈消息与预设信息进行比对，才能确定所接收反馈消息由哪个UE发送，以及确定发送的反馈消息是确认接收成功了哪个多播业务或者确认接收失败了哪个多播业务。

S303、如果确定接收成功，则根据确定的反馈机制向所述基站发送确认接收反馈消息或不进行任何反馈。

在本实施例中，所述确定接收反馈消息中具体可以包括UE的身份标识，所接收成功第一多播业务的身份标识以及确认接收成功标识，由此可以让基站更快的确定哪个UE接收成功了第一多播业务。

在本实施例中，当确定的反馈机制为高层的反馈机制时，所述基于高层的反馈机制向所述基站发送反馈消息的实现过程，可具有优化为：控制处于连接态的UE向所述基站发起上行业务传输请求；根据所述基站反馈的允许响应消息，以上行业务的方式向所述基站发送高层反馈消息。

需要说明的是，进行高层的反馈机制发送反馈消息之前，需要保持UE的网络状态处于连接态，如果当前处于空闲态，则首先需要向基站发送连接请求，与基站建立网络连接，以保证处于连接态。

在本实施例中，当确定的反馈机制为物理层的反馈机制时，所述基于物理层的反馈机制向所述基站发送反馈消息的实现过程，可具体优化为：控制UE在所述NPRACH上发送设定的随机接入前导码作为物理反馈消息。

在本实施例中，作为物理反馈消息的随机接入前导码的具体值可以由基站预先设定。

在上述优化的基础上，所述随机接入前导码的具体值可以是下述几种形式：所述随机接入前导码的基本单位设定为复用NB-IoT中NPRACH的随机接入前导码结构，4个符号组上发送的信号均为‘1’或均为‘-1’，或4个符号组上发送的信号为[W1 W2 W3 W4]，每个符号组内所有符号上发送相同的信号；或者，所述随机接入前导码的基本单位设定为N个符号组，其中，每个符号组包括1个循环前缀CP和长度为M的ZC序列。

在本实施例中，当所述随机接入前导码的4个符号组上发送的信号为[W1 W2 W3W4]时，其W1、W2、W3以及W4的取值可以有多种，本实施例中Wx的优选为‘1’或‘-1’，其中x为属于[1,4]的整数；所述随机接入前导码的基本单位设定为N个符号组时，所述随机接入前导码具体可理解为single-tone PRACH前导码，其长度为M的ZC序列可以具有不同取值。基站侦听到所述随机接入前导码的具体值后，可根据预先设定的信息表，确定所述随机接入前导码所表示的具体含义。

S304、如果确定接收失败，则根据确定的反馈机制向所述基站发送确认失败反馈消息，以使所述基站以单播或多播的方式重传所述第一多播业务。

在本实施例中，所述确认失败反馈消息也可根据选定的高层的反馈机制发送或根据选定的物理层的反馈机制发送。

进一步地，确认失败反馈消息中包含UE声明的身份标识，所述身份标识包括所属多播组的标识以及接收失败多播业务的身份标识和/或UE自身的身份标识。

在本实施例中，如果确认失败反馈消息中包含了UE声明的身份标识，则基站接收所属多播业务组的标识后，可以高效的确定哪个UE对哪个多播业务的接收状态为接收失败。可以理解的是，所述确认失败反馈消息中还包含了用于确定接收失败的接收失败标识。

进一步地，当根据所述物理层的反馈机制发送确认失败反馈消息时，所述确认失败反馈消息中可以包含以下任意组合：所述基站为不同的多播业务组或不同身份标识的多播业务配置的随机接入前导码中[W1 W2 W3 W4]的取值、所述基站为不同的多播业务组或不同身份标识的多播业务配置的随机接入前导码中的ZC序列、所述基站为不同的多播业务组或不同身份标识的多播业务配置NPRACH资源时频区域，其中，W1、W2、W3以及W4分别为设置在第1、第2、第3以及第4符号组上的信号值；和/或，以下任意组合：所述基站为不同身份标识的UE配置的随机接入前导码中[W1 W2 W3 W4]的取值、所述基站为不同身份标识的UE配置的随机接入前导码中的ZC序列、所述基站为不同身份标识的UE配置的NPRACH资源时频区域。

在本实施例中，作为确认失败反馈消息的随机接入前导码可以表示为[W1 W2 W3W4]，当W1,W2,W3以及W4的取值均为‘-1’时，仅可表明多播业务接收失败，因此还需根据为该随机接入前导码设定的NPRACH资源时频区域，来确定发送该随机接入前导码的UE的身份标识和/或接收失败的多播业务的身份标识当W1,W2,W3以及W4的取值不同时，其W1,W2,W3以及W4的不同取值不仅表示可以表明多播业务接收失败，还可以确定发送该随机接入前导码的UE的身份标识和/或接收失败的多播业务的身份标识，此时发送该随机接入前导码使用的NPRACH资源时频区域可以是设定值(基站预先设定的同样可用来确定UE和/或多播业务的身份标识)，也可以是随机的(相当于没有预先设定)。

在本实施例中，确认失败反馈消息为4个符号组且[W1 W2 W3 W4]为不同值时，所能确认UE的身份标识和/或多播业务的身份标识的数量有限，由此可以考虑采用N个符号组为基本单位的随机接入前导码作为确认失败反馈消息，此时，每个符号组中M长度的ZC序列可以有不同的取值，所以基于每个符号组的ZC序列可以用来确认更多不同UE的身份标识和/或不同多播业务的身份标识，且发送该随机接入前导码使用的NPRACH资源时频区域可以是设定值(基站预先设定的同样可用来确定UE和/或多播业务的身份标识)，也可以是随机的(相当于没有预先设定)。

S305、对基站所发送的第二多播业务进行解码分析，并根据分析结果确定是否为所述第一多播业务的重传多播业务。

S306、若确定为重传多播业务，且确定当前状态为以下任意一种或多种：接收成功、配置为单播重传、已收到单播重传的控制消息和使用基于高层的反馈机制，则不再接收重传的多播业务，否则接收所述重传多播业务，并对所述重传多播业务独立解码或对所述重传多播业务和首传的多播业务进行合并解码。

可以理解的是，对于解码失败的重传多播业务而言，仍可参考步骤S301至步骤S305的操作对所述重传多播业务进行处理，本实施例不作详述。

本发明实施例三提供的一种信息传输方法，具体描述了在物联网系统多播传输中引入接收状态反馈机制的实现操作，同时增加了发送反馈消息时所采用反馈机制的确定操作，同时描述了不同反馈机制对应的具体实现步骤。利用该方法，克服了现有物联网系统多播传输中无法进行接收状态反馈的问题，根据其引入的接收状态反馈机制提升了多播业务的传输可靠性及业务性能。

实施例四

图4为本发明实施例四提供的一种信息传输方法的流程示意图，该方法适用于在物联网的网络系统中进行下行多播业务传输的情况，该方法可以由信息传输装置执行，其中该装置可以由软件和/或硬件实现，并一般集成在物联网系统中的基站上。

如图4所示，本发明实施例四提供的一种信息传输方法，包括如下操作：

S401、向UE发送第一多播业务，以使所述UE对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务。

在本实施例中，所述第一多播业务对应于上述实施例中UE接收的第一多播业务。需要说明的是，可以采用物联网系统中现有的下行多播传输机制向所述UE发送所述第一多播业务。

S402、如果在预设时间段内没有接收到任何确认失败反馈消息，则不再重传所述第一多播业务。

在本实施例中，在预设时间内可能不会接收到任何反馈，或者可能接收到反馈消息，但所述反馈消息中包含了接收成功的标识，如表示接收状态的标识位的值为‘1’，此时可认为是该反馈消息是确认接收反馈消息，出现上述情况时可认为UE侧存在成功接收该第一多播业务的UE，但此时并不能保证UE侧的全部UE均接收成功，因此，需要确定预设时间段内是否接收到包含有接收失败标识的确认失败反馈消息，如果没有接收到，则无需重传所述第一多播业务。

在本实施例中，可以在发送所述第一多播业务后开启反馈消息的接收计时，如果计时超过设定时间段仍没有接收到确认失败反馈消息，则无需重传所述第一多播业务。

本发明实施例四提供的一种信息传输方法，首先向UE发送多播业务，然后确定在预设时间段内是否接收到消息反馈时，当没有接收到确认失败反馈消息时无需向UE重传该多播业务。利用该方法，可以根据UE的反馈消息确定是否重传多播业务，由此引入了相对于接收状态反馈机制的重传机制，从而提升了多播业务的传输可靠性以及业务性能。

实施例五

图5为本发明实施例五提供的一种信息传输方法的流程示意图，本发明实施例以上述实施例为基础进行优化，在本实施例中，该方法还优化增加了：如果接收到所述UE发送的确认失败反馈消息，则以单播或多播的方式重传所述第一多播业务。

进一步地，该方法还优化增加了：向所述UE发送第二多播业务，并在所述第二多播业务的消息报文中声明传输类型标识，以使所述UE根据所述传输类型标识确定本次多播业务是否为重传多播业务。

如图5所示，本发明实施例五提供的一种信息传输方法，具体包括如下操作：

S501、向UE发送第一多播业务，以使所述UE对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务。

S502、如果或在预设时间段内没有接收到任何确认失败反馈消息，则不再重传所述第一多播业务。

S503、如果接收到所述UE发送的确认失败反馈消息，则以单播或多播的方式重传所述第一多播业务。

在本实施例中，可以对接收的反馈消息进行分析确认，如果所述反馈消息中包含了接收失败的标识，如表示接收状态的标识位的值为‘-1’，则可认为是该反馈消息是确认失败反馈消息，即所述第一多播业务接收失败，需要重传所述第一多播业务。

具体地，本实施例可以根据确认失败反馈消息确定发送该反馈消息的UE的身份标识，根据其身份标识或该确认失败反馈消息所基于的反馈机制来确定采用何种重传方式(单播重传或多播重传)对所述第一多播业务进行重传。在本实施例中，所述确认接收反馈消息可看作为ACK消息，所述确认失败反馈消息可看作NACK消息。

进一步地，以单播或多播的方式重传所述第一多播业务包括：

若收到的确认失败反馈消息均为基于高层的反馈消息时使用单播重传；若收到的确认失败反馈消息部分为基于高层的反馈消息，部分为基于物理层的反馈消息时，采用多播重传，或对基于高层的反馈消息的发送UE进行单播重传，对基于物理层的反馈消息的发送UE进行多播重传；若收到的确认失败反馈消息均为基于物理层的反馈消息时使用多播重传；若收到的基于高层的确认失败反馈消息和/或基于物理层的确认失败反馈消息的总数超过给定阈值时使用多播重传；若无法确定收到的确认失败消息的发送UE身份标识时采用多播重传；若预先为待接收重传的UE设置了重传方式时，直接采用设置的重传方式进行重传。

可以理解的是，本实施例可以根据上述方式中的任意一种或任意多种的组合来确定重传所述第一多播业务时选定的重传方式。

S504、向所述UE发送第二多播业务，并在所述第二多播业务的消息报文中声明传输类型标识，以使所述UE根据所述传输类型标识确定本次多播业务是否为重传多播业务。

在本实施例中，基站可以除发送上述第一多播业务外，还可以发送所述第二多播业务，为了区分所述第二多播业务是否为所述第一多播业务的重传多播业务，本实施例在所述第二多播业务的消息报文中对传输类型标识进行声明。所述传输类型标识具体可理解为用于区分多播业务为首次传输(首传)或重复传输(重传)的标识，其声明方式有多种，本实施例可优选的在传输类型的标识位上将首传的标识声明为0，重传的标识声明为1。

需要理解的是，所述第二多播业务的消息报文中还额外声明了业务自身的身份标识或者业务对应多播组的身份标识，所声明的传输类型标识结合业务自身的身份标识或业务对应多播组的身份标识，可以让UE端更准确的对第二多播业务进行判定。

进一步地，在所述第二多播业务的消息报文中声明传输类型标识包括：

在所述第二多播业务的SC-MCCH中，声明SC-MTCH的DCI的配置信息时，使用所述DCI的配置信息的reserved域中的预设字段，或在所述DCI的配置信息中额外增设预设字段作为传输类型的标识位；或者，在所述第二多播业务的数据信道SC-MTCH中，和/或在所述DCI中，使用reserved域中的预设字段，或额外增设预设字段作为传输类型的标识位；或者，在网络系统消息中，或在SC-MCCH中，将特定个数的物理资源块PRB(s)配为专门的重传指示块。

在本实施例中，可以在进行下行多播业务传输时，在其发送控制报文或发送数据报文的时候声明传输类型标识，或者，当为多播业务的重传时，还可以采用特定个数的PRB来作为专门的重传指示块，由此可以将在上述PRB上进行传输的SC-MTCH均默认为重传。

本发明实施例五提供的一种信息传输方法，优化增加了接收到多播业务接收失败的反馈消息时需要进行的操作，此时，需要以单播或多播的形式重新向UE发送多播业务，从而保证UE能够成功接收该多播业务；此外，该方法还优化增加了传输类型的声明操作，以使UE确定多播业务为首传还是重传。利用该方法，在发送多播业务后可以清楚知道是否需要进行多播业务重传，从而更好的提升了多播业务的传输可靠性及业务性能。

在上述优化的基础上，本实施例中还优化增加了随机接入前导码的配置操作，具体地，其配置步骤表示为：为不同的多播业务组或不同身份标识的多播业务配置随机接入前导码中[W1 W2 W3 W4]的不同取值，其中，W1、W2、W3以及W4分别为设置在第1、第2、第3以及第4符号组上的信号值；或为不同的多播业务组或不同身份标识的多播业务配置随机接入前导码中不同的ZC序列；和/或，为不同的多播业务组或不同身份标识的多播业务配置不同的NPRACH资源时频区域；和/或，为不同身份标识的UE配置随机接入前导码中[W1 W2 W3W4]的不同取值；和/或，为不同身份标识的UE配置随机接入前导码中不同的ZC序列；和/或，为不同身份标识的UE配置不同的NPRACH资源时频区域。

需要说明的是，基于本发明实施例以及上述实施例的信息传输方法进行多播业务传输时，基站端可以预先设定UE端进行消息反馈时所采用的反馈机制，同时，基站端还需要为不同身份标识的UE和/或不同身份标识的多播业务配置物理层的反馈机制中作为反馈消息的随机接入前导码的取值，以使各UE在基于物理层的反馈机制进行消息反馈时，能够向基站发送属于各UE自身的随机接入前导码。此外，基站端还可以为不同身份标识的UE和/或不同身份标识的多播业务配置发送所述随机接入前导码时所使用的NPRACH资源时频区域。从而保证基站可以更好地对基于物理层的反馈机制发送的反馈消息中所包含的UE的身份标识和/或所对应多播业务的身份标识进行识别。

实施例六

图6为本发明实施例六提供的多播业务传输的优选实施例的流程示意图。本实施例的应用场景为物联网系统NB-IoT中的一个基站，该基站覆盖范围内具有4个UE，分别为UE1、UE2、UE3以及UE4，其中，基站可以基于本发明上述实施例提供的信息传输方法向4个UE进行下行多播业务传输。

如图6所示，本发明实施例六中的多播业务传输，具体包括如下操作：

S601、基站侧发送一项多播业务，在SC-MCCH中声明该多播业务的DCI的配置信息，在NPDCCH上发送的DCI中声明该多播业务的数据报文为首传。

S602、各UE分别对DCI的配置信息和DCI进行解码分析，确定该多播业务的数据报文为首传后，接收并解码分析该多播业务的数据报文。

在该步骤中，UE1解码成功，即UE1正确接收该数据报文，且选择不进行任何反馈；UE2解码失败，UE2确定自身当前处于连接态且自身支持高层的反馈机制，由此UE2选择基于高层的反馈机制进行确认失败反馈消息的发送；UE3也解码失败，UE3根据基站的预配置确定采用基于物理层的反馈机制进行确认失败反馈消息的发送，且UE3获取到基站为其配置的作为确认失败反馈消息的随机接入前导码为4符号组的结构，同时每符号组内所有符号上发送的信号相同，该4符号组信号表示为[1 1 1 -1]；UE4同样解码失败，UE4确定自身当前处于空闲态且基站预先配置处于空闲态的UE需采用基于高层的反馈机制，由此，UE4同样确定基于物理层的反馈机制进行确认失败反馈消息的发送，且UE4获取到基站基站为其配置的作为确认失败反馈消息的随机接入前导码也为4符号组的结构，但该4符号组信号表示为[-1 -1 -1 -1]。

S6031、UE2以上行业务的方式向基站发起上行业务传输请求，并在得到基站的允许后向基站发送确认失败反馈消息。

该步骤中，UE2所发送的确认失败反馈消息中包含了UE2的身份标识、该多播业务的身份标识以及接收失败标识。

S6032、UE3在NPRACH上发送预先获取的4符号组结构信号表示为[1 1 1 -1]的随机接入前导码。

S6033、UE4在NPRACH上使用基站为该UE4预先配置的NPRACH资源时频区域发送预先获取的4符号组结构信号表示为[-1 -1 -1 -1]的随机接入前导码。

S604、基站接收UE2、UE3以及UE4的反馈消息，根据UE2携带内容确定UE2的身份标识、该多播业务的身份标识并确定该反馈消息为确认失败反馈消息；根据UE3的4符号组信号取值确定UE3需要重传该多播业务；根据UE4使用的NPRACH资源时频区域确定UE4需要重传该多播业务。

在该步骤中，基站根据UE2采用的高层的反馈机制，确定对UE2进行单播重传该多播业务，根据UE3以及UE4使用物理层的反馈机制，确定对UE3和UE4进行多播重传。

S605、基站对UE2进行单播重传，并复用现有单播业务消息重传机制对该多播业务进行重传声明；对UE3和UE4进行多播重传，并在NPDCCH上发送该多播业务的DCI中声明该多播业务的数据报文为重传。

本步骤在NPDCCH上发送的DCI中声明该多播业务的数据报文为重传时，具体采用在该多播业务的DCI中额外增设1bit进行重传声明。

S606、各UE分别对再次接收的DCI的配置信息和DCI进行解码分析，确定是否为该多播业务的重传多播业务。

在该步骤中，UE1通过DCI解析出为该多播业务的重传业务，由于自身已经成功接收该业务，忽略该多播业务的数据报文。

S607、UE2已接收到单播重传业务的控制消息，忽略该重传多播业务；UE3和UE4接收该重传多播业务，并将重传与首传合并进行解码。

本发明实施例六提供的多播业务传输的优选实施例，采用了上述发明实施例提供的信息传输方法，克服了现有物联网系统多播传输中无法进行接收状态反馈的问题，从而使得该优选实施例中的基站在发送多播业务后可以清楚知道是否需要进行业务重传，更好地提升了多播业务的传输可靠性及业务性能。

实施例七

图7为本发明实施例七提供的一种信息传输装置的结构框图，该装置适用于在物联网的网络系统中对多播业务的接收状态反馈进行的情况，可由软件和/或硬件实现，并一般集成在物联网系统中处于某个基站覆盖范围内的UE上。如图7所示，该装置包括：业务接收确定模块71和信息反馈模块72。

其中，业务接收确定模块71，用于对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务。

信息反馈模块72，用于当确定接收成功时，向所述基站发送确认接收反馈消息或不进行任何反馈。

在本实施例中，该装置首先通过业务接收确定模块71对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；然后通过信息反馈模块72在确定接收成功时，向所述基站发送确认接收反馈消息或不进行任何反馈。

本发明实施例七提供的一种信息传输装置，克服了现有物联网系统多播传输中无法进行接收状态反馈的问题，根据其引入的接收状态反馈机制，更好地提升了多播业务的传输可靠性及业务性能。

进一步地，信息反馈模块72，还用于当确定接收失败时，向所述基站发送确认失败反馈消息，以使所述基站以单播或多播的方式重传所述第一多播业务。

在上述优化的基础上，该装置还优化包括了：

重传业务确定模块73，用于对基站所发送的第二多播业务进行解码分析，并根据分析结果确定是否为所述第一多播业务的重传多播业务。

重传业务处理模块74，用于当确定为重传多播业务，且且确定当前状态为以下任意一种或多种：接收成功、配置为单播重传、已收到单播重传的控制消息和使用基于高层的反馈机制，则不再接收重传的多播业务，否则接收所述重传多播业务，并对所述重传多播业务独立解码或对所述重传多播业务和首传的多播业务进行合并解码。

进一步地，重传业务确定模块73，具体用于：

对基站所发送的第二多播业务进行解码分析，确定在所述第二多播业务的控制报文和/或数据报文中声明的传输类型标识；如果根据所述传输类型标识确定本次多播业务为首传，则确定所述第二多播业务不是所述第一多播业务的重传多播业务；如果根据所述传输类型标识确定本次多播业务为重传，则确定所述第二多播业务为所述第一多播业务的重传多播业务。

在上述优化的基础上，重传业务确定模块73，还用于在对基站所发送的第二多播业务进行解码分析之后，确定在所述第二多播业务的控制报文和/或数据报文中声明的多播业务身份标识或多播组身份标识；

相应的，重传业务确定模块73根据所述传输类型标识以及所述多播业务身份标识或多播组身份标识，确定第二多播业务是否为所述第一多播业务的重传多播业务。

进一步地，所述信息反馈模块72，具体用于：基于高层的反馈机制或基于物理层的反馈机制向所述基站发送反馈消息。

在上述优化的基础上，基于高层的反馈机制向所述基站发送反馈消息包括：控制处于连接态的UE向所述基站发起上行业务传输请求；根据所述基站反馈的允许响应消息，以上行业务的方式向所述基站发送高层反馈消息。

在上述优化的基础上，基于物理层的反馈机制向所述基站发送反馈消息包括：控制UE在所述NPRACH上发送设定的随机接入前导码作为物理反馈消息。

进一步地，所述随机接入前导码的基本单位设定为复用窄带蜂窝物联网中NPRACH的随机接入前导码结构，4个符号组上发送的信号均为‘1’或均为‘-1’，或4个符号组上发送的信号为[W1 W2 W3 W4]，每个符号组内所有符号上发送相同的信号；或者，所述随机接入前导码的基本单位设定为N个符号组，其中，每个符号组包括1个循环前缀CP和长度为M的ZC序列。

进一步地，所述信息反馈模块72具体用于：用于根据基站配置确定使用基于高层的反馈机制或基于物理层的反馈机制；或，根据是否支持高层反馈机制和/或是否处于连接态，决定使用基于高层的反馈机制或基于物理层的反馈机制。

在本实施例中，确认失败反馈消息中包含UE声明的身份标识，所述身份标识包括所属多播组的标识以及接收失败多播业务的身份标识和/或UE自身的身份标识。

在上述优化的基础上，所述确认失败反馈消息中包含以下任意组合：所述基站为不同的多播业务组或不同身份标识的多播业务配置的随机接入前导码中[W1 W2 W3 W4]的取值、所述基站为不同的多播业务组或不同身份标识的多播业务配置的随机接入前导码中的ZC序列、所述基站为不同的多播业务组或不同身份标识的多播业务配置不同的NPRACH资源时频区域，其中，W1、W2、W3以及W4分别为设置在第1、第2、第3以及第4符号组上的信号值；

和/或，以下任意组合：所述基站为不同身份标识的UE配置的随机接入前导码中[W1 W2 W3 W4]的取值、所述基站为不同身份标识的UE配置的随机接入前导码中的ZC序列、所述基站为不同身份标识的UE配置的NPRACH资源时频区域。

实施例八

图8为本发明实施例八提供的一种信息传输装置的结构框图，该装置适用于在物联网的网络系统中进行下行多播业务传输的情况，该装置可以由软件和/或硬件实现，并一般集成在物联网系统中的基站上。如图8所示，该装置包括：第一业务发送模块81和第一消息处理模块82。

其中，第一业务发送模块81，用于向UE发送第一多播业务，以使所述UE对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；

第一消息处理模块82，用于当在预设时间段内没有接收到任何确认失败反馈消息时，不再重传所述第一多播业务。

在本实施例中，该装置首先通过第一业务发送模块81向UE发送第一多播业务，以使所述UE对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；然后通过第一消息处理模块82在预设时间段内没有接收到任何确认失败反馈消息时，不再重传所述第一多播业务。

本发明实施例八提供的一种信息传输装置，可以根据UE的反馈消息确定是否重传多播业务，由此引入了相对于接收状态反馈机制的重传机制，从而提升了多播业务的传输可靠性以及业务性能。

进一步地，该装置还优化包括了：

第二消息处理模块83，用于当接收所述UE发送的确认失败反馈消息时，以单播或多播的方式重传所述第一多播业务。

在上述优化的基础上，第二消息处理模块83，具体用于：

当接收所述UE发送的确认失败反馈消息时，通过下述一种或多种条件确定所述第一多播业务的重传方式：

若收到的确认失败反馈消息均为基于高层的反馈消息时使用单播重传；若收到的确认失败反馈消息部分为基于高层的反馈消息，部分为基于物理层的反馈消息时，采用多播重传，或对基于高层的反馈消息的发送UE进行单播重传，对基于物理层的反馈消息的发送UE进行多播重传；若收到的确认失败反馈消息均为基于物理层的反馈消息时使用多播重传；若收到的基于高层的确认失败反馈消息和/或物理层的确认失败反馈消息的总数超过给定阈值时使用多播重传；若无法确定收到的确认失败消息的发送UE身份标识时采用多播重传；若预先为待接收重传的UE设置了重传方式时，直接采用设置的重传方式进行重传。

进一步地，该装置还优化包括了：

第二业务发送模块84，向所述UE发送第二多播业务，并在所述第二多播业务的消息报文中声明传输类型标识，以使所述UE根据所述传输类型标识确定本次多播业务是否为重传多播业务。

在上述优化的基础上，第二业务发送模块84，具体可用于：

在所述第二多播业务的SC-MCCH中，声明SC-MTCH的DCI的配置信息时，使用所述DCI的配置信息的reserved域中的预设字段，或在所述DCI的配置信息中额外增设预设字段作为传输类型的标识位；或者，在所述第二多播业务的数据信道SC-MTCH中，和/或在所述DCI中，使用reserved域中的预设字段，或额外增设预设字段作为传输类型的标识位；或者，在网络系统消息中，或在SC-MCCH中，将特定个数的物理资源块PRB(s)配为专门的重传指示块。

在上述优化的基础上，该装置还优化包括：

信息预配置模块75，用于为不同的多播业务组或不同身份标识的多播业务配置随机接入前导码中[W1 W2 W3 W4]的不同取值，其中，W1、W2、W3以及W4分别为设置在第1、第2、第3以及第4符号组上的信号值；

或为不同的多播业务组或不同身份标识的多播业务配置随机接入前导码中不同的ZC序列；

和/或，为不同的多播业务组或不同身份标识的多播业务配置不同的NPRACH资源时频区域；

和/或，为不同身份标识的UE配置随机接入前导码中[W1 W2 W3 W4]的不同取值；

和/或，为不同身份标识的UE配置随机接入前导码中不同的ZC序列；

和/或，为不同身份标识的UE配置不同的NPRACH资源时频区域。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (27)

1.一种信息传输方法，其特征在于，包括：

对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；

如果确定接收成功，则向所述基站发送确认接收反馈消息或不进行任何反馈。

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

如果确定接收失败，则向所述基站发送确认失败反馈消息，以使所述基站以单播或多播的方式重传所述第一多播业务。

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

对基站所发送的第二多播业务进行解码分析，并根据分析结果确定是否为所述第一多播业务的重传多播业务；

若确定为重传多播业务，且确定当前状态为以下任意一种或多种：接收成功、配置为单播重传、已收到单播重传的控制消息和使用基于高层的反馈机制，则不再接收重传的多播业务，否则接收所述重传多播业务，并对所述重传多播业务独立解码或对所述重传多播业务和首传的多播业务进行合并解码。

4.根据权利要求3所述的方法，其特征在于，对基站所发送的第二多播业务进行解码分析，并根据分析结果确定是否为所述第一多播业务的重传多播业务包括：

对基站所发送的第二多播业务进行解码分析，确定在所述第二多播业务的控制报文和/或数据报文中声明的传输类型标识；

如果根据所述传输类型标识确定本次多播业务为首传，则确定所述第二多播业务不是所述第一多播业务的重传多播业务；

如果根据所述传输类型标识确定本次多播业务为重传，则确定所述第二多播业务为所述第一多播业务的重传多播业务。

5.根据权利要求4所述的方法，其特征在于，在对基站所发送的第二多播业务进行解码分析之后，还包括：

确定在所述第二多播业务的控制报文和/或数据报文中声明的多播业务身份标识或多播组身份标识；

相应的，根据所述传输类型标识以及所述多播业务身份标识或多播组身份标识，确定第二多播业务是否为所述第一多播业务的重传多播业务。

6.根据权利要求1-5任一项所述的方法，其特征在于，向所述基站发送反馈消息包括：

基于高层的反馈机制或基于物理层的反馈机制向所述基站发送反馈消息。

7.根据权利要求6所述的方法，其特征在于，基于高层的反馈机制向所述基站发送反馈消息包括：

控制处于连接态的UE向所述基站发起上行业务传输请求；

根据所述基站反馈的允许响应消息，以上行业务的方式向所述基站发送高层反馈消息。

8.根据权利要求6所述的方法，其特征在于，基于物理层的反馈机制向所述基站发送反馈消息包括：控制用户设备UE在所述NPRACH上发送设定的随机接入前导码作为物理反馈消息。

9.根据权利要求8所述的方法，其特征在于，所述随机接入前导码的基本单位设定为复用窄带蜂窝物联网中NPRACH的随机接入前导码结构，4个符号组上发送的信号均为‘1’或均为‘-1’，或4个符号组上发送的信号为[W1W2W3W4]，每个符号组内所有符号上发送相同的信号；

或者，所述随机接入前导码基本单位设定为N个符号组，其中，每个符号组包括1个循环前缀CP和长度为M的ZC序列。

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

根据基站配置确定使用基于高层的反馈机制或基于物理层的反馈机制；

或，根据是否支持高层反馈机制和/或是否处于连接态，决定使用基于高层的反馈机制或基于物理层的反馈机制。

11.根据权利要求2所述的方法，其特征在于，所述确认失败反馈消息中包含UE声明的身份标识，所述身份标识包括所属多播组的标识以及接收失败多播业务的身份标识和/或UE自身的身份标识。

12.根据权利要求9所述的方法，其特征在于，所述确认失败反馈消息中包含以下任意组合：所述基站为不同的多播业务组或不同身份标识的多播业务配置的随机接入前导码中[W1W2W3W4]的取值、所述基站为不同的多播业务组或不同身份标识的多播业务配置的随机接入前导码中的ZC序列、所述基站为不同的多播业务组或不同身份标识的多播业务配置的NPRACH资源时频区域，其中，W1、W2、W3以及W4分别为设置在第1、第2、第3以及第4符号组上的信号值；

和/或，以下任意组合：所述基站为不同身份标识的UE配置的随机接入前导码中[W1W2W3W4]的取值、所述基站为不同身份标识的UE配置的随机接入前导码中的ZC序列、所述基站为不同身份标识的UE配置的NPRACH资源时频区域。

13.一种信息传输方法，其特征在于，包括：

向用户设备UE发送第一多播业务，以使所述UE对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；

如果在预设时间段内没有接收到任何确认失败反馈消息，则不再重传所述第一多播业务。

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

如果接收到所述UE发送的确认失败反馈消息，则以单播或多播的方式重传所述第一多播业务。

15.根据权利要求14所述的方法，其特征在于，以单播或多播的方式重传所述第一多播业务包括：

若收到的确认失败反馈消息均为基于高层的反馈消息时使用单播重传；

若收到的确认失败反馈消息部分为基于高层的反馈消息，部分为基于物理层的反馈消息时，采用多播重传，或对基于高层的反馈消息的发送UE进行单播重传，对基于物理层的反馈消息的发送UE进行多播重传；

若收到的确认失败反馈消息均为基于物理层的反馈消息时使用多播重传；

若收到的基于高层的确认失败反馈消息和/或基于物理层的确认失败反馈消息的总数超过给定阈值时使用多播重传；

若无法确定收到的确认失败消息的发送UE身份标识时采用多播重传；

若预先为待接收重传的UE设置了重传方式时，直接采用设置的重传方式进行重传。

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

向所述UE发送第二多播业务，并在所述第二多播业务的消息报文中声明传输类型标识，以使所述UE根据所述传输类型标识确定本次多播业务是否为重传多播业务。

17.根据权利要求16所述的方法，其特征在于，在所述第二多播业务的消息报文中声明传输类型标识包括：

在所述第二多播业务的下行多播控制信道SC-MCCH中，声明下行多播数据信道SC-MTCH的下行控制信息DCI的配置信息时，使用所述DCI的配置信息的reserved域中的预设字段，或在所述DCI的配置信息中额外增设预设字段作为传输类型的标识位；

或者，在所述第二多播业务的数据信道SC-MTCH中，和/或在所述DCI中，使用reserved域中的预设字段，或额外增设预设字段作为传输类型的标识位；

或者，在网络系统消息中，或在SC-MCCH中，将特定个数的物理资源块PRB(s)配为专门的重传指示块。

18.根据权利要求13-17任一项所述的方法，其特征在于，还包括：

为不同的多播业务组或不同身份标识的多播业务配置随机接入前导码中[W1W2W3W4]的不同取值，其中，W1、W2、W3以及W4分别为设置在第1、第2、第3以及第4符号组上的信号值；

或为不同的多播业务组或不同身份标识的多播业务配置随机接入前导码中不同的ZC序列；

和/或，为不同的多播业务组或不同身份标识的多播业务配置不同的NPRACH资源时频区域；

和/或，为不同身份标识的UE配置随机接入前导码中[W1W2W3W4]的不同取值；

和/或，为不同身份标识的UE配置随机接入前导码中不同的ZC序列；

和/或，为不同身份标识的UE配置不同的NPRACH资源时频区域。

19.一种信息传输装置，其特征在于，包括：

业务接收确定模块，用于对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；

信息反馈模块，用于当确定接收成功时，向所述基站发送确认接收反馈消息或不进行任何反馈。

20.根据权利要求19所述的装置，其特征在于，所述信息反馈模块，还用于当确定接收失败时，向所述基站发送确认失败反馈消息，以使所述基站以单播或多播的方式重传所述第一多播业务。

21.根据权利要求19所述的装置，其特征在于，还包括：

重传业务确定模块，用于对基站所发送的第二多播业务进行解码分析，并根据分析结果确定是否为所述第一多播业务的重传多播业务；

重传业务处理模块，用于当确定为重传多播业务，且且确定当前状态为以下任意一种或多种：接收成功、配置为单播重传、已收到单播重传的控制消息和使用基于高层的反馈机制，则不再接收重传的多播业务，否则接收所述重传多播业务，并对所述重传多播业务独立解码或对所述重传多播业务和首传的多播业务进行合并解码。

22.根据权利要求19-21任一项所述的装置，其特征在于，所述信息反馈模块具体用于：

基于高层的反馈机制或基于物理层的反馈机制向所述基站发送反馈消息。

23.根据权利要求22所述的装置，其特征在于，所述信息反馈模块具体用于：

根据基站配置确定使用基于高层的反馈机制或基于物理层的反馈机制；

或，根据是否支持高层反馈机制和/或是否处于连接态，决定使用基于高层的反馈机制或基于物理层的反馈机制。

24.一种信息传输装置，其特征在于，包括：

第一业务发送模块，用于向UE发送第一多播业务，以使所述UE对基站发送的第一多播业务进行解码分析，并根据分析结果确定是否成功接收所述第一多播业务；

第一消息处理模块，用于当在预设时间段内没有接收到任何确认失败反馈消息时，不再重传所述第一多播业务。

25.根据权利要求24所述的装置，其特征在于，还包括：

第二消息处理模块，用于当接收所述UE发送的确认失败反馈消息时，以单播或多播的方式重传所述第一多播业务。

26.根据权利要求24所述的装置，其特征在于，还包括：

第二业务发送模块，用于向所述UE发送第二多播业务，并在所述第二多播业务的控制报文中声明传输类型标识，以使所述UE根据所述传输类型标识确定本次多播业务是否为重传多播业务。

27.根据权利要求24-26任一项所述的装置，其特征在于，还包括：

信息预配置模块，用于为不同的多播业务组或不同身份标识的多播业务配置随机接入前导码中[W1W2W3W4]的不同取值，其中，W1、W2、W3以及W4分别为设置在第1、第2、第3以及第4符号组上的信号值；

或为不同的多播业务组或不同身份标识的多播业务配置随机接入前导码中不同的ZC序列；

和/或，为不同的多播业务组或不同身份标识的多播业务配置不同的NPRACH资源时频区域；

和/或，为不同身份标识的UE配置随机接入前导码中[W1W2W3W4]的不同取值；

和/或，为不同身份标识的UE配置随机接入前导码中不同的ZC序列；

和/或，为不同身份标识的UE配置不同的NPRACH资源时频区域。