CN108242975B - 一种多信令下发的方法及装置 - Google Patents

Abstract

本发明涉及无线通信技术领域，特别涉及一种多信令下发的方法及装置。该方法为：发送端接收每一条控制信令消息相应的响应消息，确定各条响应消息的待处理顺序，并对各条响应消息进行格式解析处理，以及基于处理结果对各条响应消息进行完整性验证，若判定一条响应消息通过完整性验证，且存在前序的至少一条响应消息未通过完整性验证，则上报上述一条响应消息，直至所有响应消息上报完成。采用上述方法，在多信令下发的过程中，发送端在接收到完整的响应消息后，不需要等待其前序的响应消息上报完成后再上报该完整的响应消息，这样，就降低了掉线指标，在提高下发效率的同时，提高了关键业绩指标。

Description

一种多信令下发的方法及装置

技术领域

本发明涉及无线通信技术领域，特别涉及一种多信令下发的方法及装置。

背景技术

在长期演进(Long Term Evolution，LTE)系统现网实际运行的过程中，会经常出现基站(Evolved Node B，eNB)本地的无线资源控制协议层(Radio Resource Control，RRC)向用户终端(User Equipment，UE)并行下发多条控制面消息的情况，UE在接收上述eNB并行下发的控制面消息后，需要基于接收到的各条控制面消息分别生成相应的响应消息，并将响应消息返回给eNB。

现有技术下，当发送端本地的RRC层需要向接收端并行发送多条控制面消息时，发送端通过本地的介质访问控制(Medium Access Control，MAC)和物理层(Physical Layer，PHY)向接收端发送控制面消息，接收端在接收到发送端发送的多条控制面消息后，需要基于上述多条控制面消息分别生成相应的响应消息，并将上述响应消息通过接收端本地的MAC和PHY层返回给发送端，当发送端本地的无线链路控制层(Radio Link Control，RLC)在接收到接收端返回的响应消息时，需要根据协议规定按照发送端并行发送多条控制面消息时的发送顺序递交响应消息给发送端本地的RRC层。

然而，采用上述方法，仍然存在许多不足之处，发送端本地的RLC层在接收接收端返回的响应消息时，发送端本地的RLC层只能按照发送端并行发送多条控制面消时，发送端的发送顺序向发送端本地的RRC层递交相应的响应消息，那么，在前面的响应消息未接收完整的情况下，即便是后面已接收完整的比较重要的响应消息也无法递交至发送端本地的RRC层，定时器超时后，发送端就会释放本次会话，从而产生一次掉话，增加了掉线指标，降低了控制面消息下发效率的同时，降低了关键业绩指标(Key Performance Indication，KPI指标)。

综上所述，需要设计一种新的多信令下发的方法来弥补现有技术中存在的不足之处。

发明内容

本发明实施例提供一种多信令下发的方法及装置，用以解决现有技术中存在控制面信令消息下发效率低、掉线指标高的问题。

本发明实施例提供的具体技术方案如下：

一种多信令下发的方法，包括：

发送端向接收端下发至少两条控制信令消息；

发送端分别接收接收端返回的针对每一条控制信令消息的响应消息，并确定各条响应消息的待处理顺序；

发送端对接收到的各条响应消息进行格式解析处理，并基于处理结果对各条响应消息进行完整性验证，其中，发送端每判定一条响应消息通过完整性验证，若基于所述待处理顺序确定所述一条响应消息存在前序的至少一条响应消息，且所述前序的至少一条响应消息中存在未通过完整性验证的响应消息，则上报所述一条响应消息，直至所有响应消息上报完成。

可选的，发送端确定各条响应消息的待处理顺序，具体包括：

发送端基于所述至少两条控制信令消息的发送顺序，确定接收端返回的，针对每一条控制信令消息的响应消息的待处理顺序。

可选的，发送端对任意一条响应消息进行完整性验证，包括：

发送端针对接收到的所述任意一条响应消息进行解封装处理，以确定所述任意一条响应消息中包含的各个数据包的序号；

发送端基于已确定的各个数据包的序号，在确定所有数据包接收完毕时，判定所述任意一条响应消息通过完整性验证。

可选的，进一步包括：

若发送端确定所述任意一条响应消息在设定时长内未通过完整性验证，则启动延时定时器；

发送端在所述延时定时器超时之前继续接收所述任意一条响应消息。

可选的，发送端向接收端下发至少两条控制信令消息之后，在接收响应消息之前，进一步包括：

发送端基于所述至少两条控制信令消息的消息数目创建相应大小的接收窗口，所述接收窗口用于接收并验证响应消息。

可选的，在发送端判定任意一条响应消息通过完整性验证，并基于所述待处理顺序确定所述任意一条响应消息存在前序的至少一条响应消息，且所述前序的至少一条响应消息中存在未通过完整性验证的响应消息时，上报所述任意一条响应消息之后，进一步包括：

若发送端判定上报的所述任意一条响应消息在接收窗口内，则确定与所述任意一条响应消息对应的控制信令消息下发成功，并将接收窗口的大小减小1。

一种多信令下发的装置，包括：

下发单元，用于向接收端下发至少两条控制信令消息；

接收单元，用于分别接收接收端返回的针对每一条控制信令消息的响应消息，并确定各条响应消息的待处理顺序；

执行单元，用于对接收到的各条响应消息进行格式解析处理，并基于处理结果对各条响应消息进行完整性验证，其中，发送端每判定一条响应消息通过完整性验证，若基于所述待处理顺序确定所述一条响应消息存在前序的至少一条响应消息，且所述前序的至少一条响应消息中存在未通过完整性验证的响应消息，则上报所述一条响应消息，直至所有响应消息上报完成。

可选的，在确定各条响应消息的待处理顺序时，所述接收单元用于：

基于所述至少两条控制信令消息的发送顺序，确定接收端返回的，针对每一条控制信令消息的响应消息的待处理顺序。

可选的，在对任意一条响应消息进行完整性验证时，所述执行单元用于：

针对接收到的所述任意一条响应消息进行解封装处理，以确定所述任意一条响应消息中包含的各个数据包的序号；

基于已确定的各个数据包的序号，在确定所有数据包接收完毕时，判定所述任意一条响应消息通过完整性验证。

可选的，所述执行单元进一步用于：

若确定所述任意一条响应消息在设定时长内未通过完整性验证，则启动延时定时器；

在所述延时定时器超时之前继续接收所述任意一条响应消息。

可选的，在向接收端下发至少两条控制信令消息之后，在接收响应消息之前，所述下发单元进一步用于：

基于所述至少两条控制信令消息的消息数目创建相应大小的接收窗口，所述接收窗口用于接收并验证响应消息。

可选的，在判定任意一条响应消息通过完整性验证，并基于所述待处理顺序确定所述任意一条响应消息存在前序的至少一条响应消息，且所述前序的至少一条响应消息中存在未通过完整性验证的响应消息时，上报所述任意一条响应消息之后，所述执行单元进一步用于：

若判定上报的所述任意一条响应消息在接收窗口内，则确定与所述任意一条响应消息对应的控制信令消息下发成功，并将接收窗口的大小减小1。

本发明有益效果如下：

综上所述，本发明实施例中，在发送端向接收端下发至少两条控制信令消息的过程中，当发送端接收接收端返回的针对每一条控制信令消息的响应消息时，确定各条响应消息的待处理顺序，并对接收到的各条响应消息进行格式解析处理，以及基于处理结果对各条响应消息进行完整性验证，其中，发送端每判定一条响应消息通过完整性验证，若基于上述待处理顺序确定上述一条响应消息存在前序的至少一条响应消息未通过完整性验证，则上报上述一条响应消息，直至所有响应消息上报完成。

采用上述方法，在多信令下发的过程中，发送端接收到任意一个完整的响应消息后，不再需要等待其前序的响应消息上报完成后再上报上述任意一个响应消息，这样，就避免了由于前序的响应消息接收不完整而导致后序的已接收完整的响应消息无法上报，从而降低了掉线指标，在提高下发效率的同时，提高了关键业绩指标。

附图说明

图1为本发明实施例中，一种多信令下发的方法流程图；

图2为本发明实施例中，发送端本地的RLC中一种PDU格式示意图；

图3为本发明实施例中，eNB本地的RRC向UE下发UECapabilityInformation消息和RRCConnectionReconfiguration消息的详细流程；

图4为本发明实施例中，一种多信令下发的装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，并不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了解决现有技术中存在的在连续下发多条控制信令消息的过程中，下发效率低、掉线指标高以及关键业绩指标低的问题，本发明实施例中，设计了一种多信令下发方法及装置，该方法为：发送端分别接收接收端返回的针对每一条控制信令消息的响应消息，并确定各条响应消息的待处理顺序，并对接收到的各条响应消息进行格式解析处理，以及基于处理结果对各条响应消息进行完整性验证，其中，发送端每判定一条响应消息通过完整性验证，若基于上述待处理顺序确定上述一条响应消息存在前序的至少一条响应消息未通过完整性验证，则上报上述一条响应消息，直至所有响应消息上报完成。

下面将通过具体实施例对本发明的方案进行详细描述，当然，本发明并不限于以下实施例。

参阅图1所示，本发明实施例中，一种多信令下发的方法流程如下：

步骤101：发送端向接收端下发至少两条控制信令消息。

发送端基于自身需要和/或在接收到控制信令消息下发指令时，向接收端连续下发至少两条控制信令消息。

例如，在长期演进(Long Term Evolution，LTE)系统现网运行的过程中，基站(Evolved Node B，eNB)本地的无线资源控制协议(Radio Resource Control，RRC)在检测到需要查询用户终端(User Equipment，UE)的异系统能力时，eNB本地的RRC向UE发送“UECapabilityInformation”消息，以查询UE的异系统能力；若在此时收到核心网发出的演进的无线接入承载(Evolved Radio Access Bearer，E-RAB)的服务质量(Quality ofService，QoS)属性修改的通知，那么，eNB又向UE发送“RRCConnectionReconfiguration”消息。

发送端基于上述至少两条控制信令消息的消息数目创建相应大小的接收窗口，其中，所述窗口用于接收并验证响应消息。

例如，eNB向UE下发查询UE异系统能力的“UECapabilityInformation”和指示UE进行演进的无线接入承载的服务质量属性修改的“RRCConnectionReconfiguration”2条控制信令消息后，eNB基于下发的控制信令消息的消息数目(如，2条)创建一个相应大小的接收窗口(如，大小为2)。

进一步的，发送端在向接收端每下发一条控制信令消息后，可以针对该控制信令消息启动一个定时器，其中，该定时器用于确定发送端能否在相应的设定时间内接收到与该控制信令消息相应的响应消息。

例如，eNB向UE下送查询UE异系统能力的“UECapabilityInformation”消息，并启动定时器T_U；eNB向UE下发指示UE进行演进的无线接入承载的服务质量属性修改的“RRCConnectionReconfiguration”消息，并启动定时器T_R。

步骤102：接收端接收上述至少两条控制信令消息。

例如，UE接收eNB下发的查询UE异系统能力的“UECapabilityInformation”消息和用于指示UE进行E-RAB的QoS属性修改的“RRCConnectionReconfiguration”消息。

步骤103：接收端针对上述至少两条控制信令消息分别生成相应的响应消息，并将上述响应消息返回给发送端。

具体的，接收端在接收到发送端发送的至少两条控制信令消息后，根据各控制信令消息的指示完成相应的操作，并生成相应的响应消息，以及将生成的响应消息返回给发送端。

例如，UE在接收到eNB下发的用于查询UE的异系统能力的“UECapabilityInformation”消息后，根据该消息携带的查询内容完成相应的查询操作，生成相应的查询响应消息，并将该响应消息返回给eNB。

又例如，UE在接收到eNB下发的用于指示UE进行E-RAB的QoS属性修改的“RRCConnectionReconfiguration”消息后，根据该消息携带的修改参数，完成相应的配置修改，生成相应的修改响应消息，并将该响应消息返回eNB。

步骤104：发送端分别接收接收端返回的针对每一条控制信令消息的响应消息，并确定各条响应消息的待处理顺序。

具体的，接收端在接收到发送端下发的至少两条控制信令消息后，会针对接收到的每一条控制信令消息分别生成相应的响应消息，并将该响应消息返回给发送端。

发送端分别接收接收端返回的针对每一条控制信令消息的响应消息，并基于上述至少两条控制信令消息的发送顺序，确定接收端返回的，针对每一条控制信令消息的响应消息的待处理顺序。

换言之，发送端基于各个控制信令消息发送时的发送顺序，确定接收处理与上述各个控制信令消息相应的各个响应消息的待处理顺序。

例如，假设eNB向UE先下发“UECapabilityInformation”消息，后下发“RRCConnectionReconfiguration”消息，那么，UE在接收到eNB下发的“UECapabilityInformation”消息时，会针对“UECapabilityInformation”生成相应的响应消息U，UE在接收到eNB下发的“RRCConnectionReconfiguration”消息时，会针对“RRCConnectionReconfiguration”生成相应的响应消息R，UE将生成的响应消息U和响应消息R返回给eNB。eNB分别接收UE返回的响应消息U和响应消息R，并根据发送“UECapabilityInformation”消息和“RRCConnectionReconfiguration”消息时的发送顺序，确定响应消息U为响应消息R的前序的响应消息。

步骤105：发送端对接收到的各条响应消息进行格式解析处理，并基于处理结果对各条响应消息进行完整性验证。

实际应用中，首先，发送端会针对接收到的任意一条响应消息进行解封装处理，以确定该任意一条响应消息中包含的各个数据包的序号；然后，发送端会基于已确定的各个数据包的序号，在确定所有数据包接收完毕时，判定该任意一条响应消息通过完整性验证。

例如，eNB确定针对“UECapabilityInformation”消息生成的响应消息U在协议数据单元(Packet Data Unit，PDU)序号为0、1、2和3的PDU中放置，而eNB确定针对“RRCConnectionReconfiguration”消息生成的响应消息R在PDU序号为4和5的PDU中放置，eNB在接收到UE返回的各PDU后，对各PDU进行格式解析处理，确定各PDU的PDU序号，并基于已确定的各PDU的PDU序号，确定响应消息U和/或响应消息R包含的PDU是否接收完毕，以及在确定PDU序号为0、1、2和3的PDU接收完毕时，判定响应消息U通过完整性验证，在确定PDU序号为4和5的PDU接收完毕后，判定响应消息R通过完整性验证。

进一步的，发送端在判定一条响应消息通过完整性验证时，若基于待处理顺序确定上述一条响应消息存在前序的至少一条响应消息，且上述前序的至少一条响应消息中存在未通过完整性验证的响应消息，则上报上述一条响应消息，直至所有响应消息上报完成。

例如，假设eNB确定UE返回的针对“UECapabilityInformation”消息生成的响应消息U在协议数据单元(Packet Data Unit，PDU)序号为0、1、2和3的PDU中放置，而eNB确定UE返回的针对“RRCConnectionReconfiguration”消息生成的响应消息R在PDU序号为4和5的PDU中放置，且响应消息U为响应消息R的前序的响应消息。若eNB本地的无线链路控制层(Radio Link Control，RLC)在接收到PDU序号为1、2、4和5的PDU，eNB就确定响应消息R通过完整性验证，而此时PDU序号为0和3的PDU未接收到，则响应消息U未通过完整性验证，且响应消息U为响应消息R的前序的响应消息，那么，eNB本地的RLC将响应消息R递交给eNB本地的RRC。

当然，若接收端网络覆盖好，发送端在接收响应消息时没有发生丢包和/或传输延，发送端就可能按照上述待处理顺序完成接收各响应消息，那么，接收端本地的RLC就会按照待处理顺序将各响应消息上报给本地的RRC。

例如，假设UE针对“UECapabilityInformation”消息生成的响应消息U在PDU序号为0、1、2和3的PDU中放置，而eNB确定针对“RRCConnectionReconfiguration”消息生成的响应消息R在PDU序号为4和5的PDU中放置，且响应消息U为响应消息R的前序的响应消息。eNB本地的RLC确定响应消息U包含的PDU序号为0、1、2和3的PDU接收完毕时，PDU序号为4和/或5的PDU未接收完毕，则eNB本地的RLC先将响应消息U上报给本地的RRC，并在确定响应消息R包含的PDU序号为4和5的PDU接收完毕时，将响应消息R上报给本地的RRC。

更进一步的，若发送端确定上述任意一条响应消息在设定时长内未通过完整性验证，则启动延时定时器，发送端在上述延时定时器超时之前继续接收上述任意一条响应消息。

实际应用中，发送端在向接收端下发一个重要的控制信令消息时，会启动一个相应的定时器，若在上述定时器设定时长内接收到接收端针对上述控制信令消息返回的响应消息，则确定上述控制信令消息下发成功，停止上述定时器；若在上述定时器设定时长内未接收到上述控制信令消息相应的响应消息，则启动延时定时器，并在延时定时器超时之前继续接收上述控制信令消息相应的响应消息。

例如，假设eNB向UE下发用于指示UE进行演进的无线接入承载的服务质量属性修改的“RRCConnectionReconfiguration”，并启动定时器T_R，其中，T_R的设定时长为10秒，若eNB在下发“RRCConnectionReconfiguration”后10秒内未接收到UE针对“RRCConnectionReconfiguration”返回的响应消息R，则启动延时定时器T_R’，其中T_R’的设定时长为5秒，eNB在延时定时器T_R’超时之前继续接收响应消息R。

参阅图2所示，本发明实施例中，发送端本地的RLC的一种PDU格式，其中，SN(Serial Number，序列号)为RLC的PDU序列号，LI字段为PDU中携带的SDU的长度，FI字段指示PDU是否为一个SDU的开始或结束，那么，RLC依据PDU中的LI和FI字段，可以解析出SDU。

当然，本发明实施例可以采用但不限于以上RLC的PDU格式。

下面将通过举例说明本发明实施例在业务场景里的应用。

参阅图3所示，本发明实施例中，eNB本地的RRC向UE下发UECapabilityInformation消息和RRCConnectionReconfiguration消息的详细流程如下：

例如，eNB本地的RRC向本地的PDCP下发“UECapabilityInformation”消息，并针对该消息启动一个相应的定时器(如，T_U)，接着，eNB本地的RRC向本地的PDCP下发“RRCConnectionReconfiguration”消息，并针对该消息启动一个相应的定时器(如T_R)，并指示PDCP上述两条控制信令消息为并发消息，eNB本地的PDCP在接收到本地的RRC下发的两条控制信息消息后，创建一个与接收到的控制信令消息相应的接收窗口(其中，接收窗口的窗长为本地的PDCP接收到的本地的RRC下发的控制信令消息的条数)，并对接收到的“UECapabilityInformation”消息和“RRCConnectionReconfiguration”消息进行合段封装处理，得到相应的服务数据单元(Service Data Unit，SDU)，eNB本地的PDCP将合段封装处理后的“UECapabilityInformation”消息和“RRCConnectionReconfiguration”消息下发至本地的RLC，RLC通过介质访问控制(Media Access Control，MAC)和物理层(PHY)向UE发送空口消息的方式将“UECapabilityInformation”消息和“RRCConnectionReconfiguration”消息下发至UE。UE在接收到eNB下发的“UECapabilityInformation”消息后，基于“UECapabilityInformation”消息携带的内容完成相应的操作指示，并生成相应的响应消息U，UE在接收到eNB下发的“RRCConnectionReconfiguration”消息后，基于“RRCConnectionReconfiguration”消息携带的内容完成相应的操作指示，并生成相应的响应消息R，UE将生成的响应消息U和响应消息R通过向eNB发送空口消息的方式返回给eNB，eNB本地的RLC在接收到UE返回的响应消息U和响应消息R时，基于eNB下发上述两个控制信令消息时的发送顺序，确定响应消息U为响应消息R前序的响应消息，并对接收到的各个PDU进行解封装处理，以确定各个PDU的PDU序号，根据已确定的各PDU的PDU序号，在确定响应消息R接收完毕后，eNB本地的RLC将所属于响应消息R的各个PDU合段成相应的SDU1，并将合段成功后的SDU1递交至本地的PDCP的接收窗口内，本地的PDCP针对接收到的与响应消息R相应的SDU1进行解密处理和进行完整性校验，并判断响应消息R是否为“RRCConnectionReconfiguration”的响应消息，若确定响应消息R为“RRCConnectionReconfiguration”的响应消息，则将响应消息R返回给eNB本地的RRC，并将接收窗口的窗长减1，eNB本地的RRC确定接收到响应消息R，停定时器T_R，此时，响应消息U未接收完成，eNB本地的RRC指示本地的RLC在定时器T_U设定时长内(即定时器T_U超时之前)继续针对接收到的各个PDU进行解封装处理，以确定各个PDU的PDU序号，并根据已确定的各个PDU的PDU序号，在确定响应消息U接收完毕后，eNB本地的RLC将所属于响应消息U的各个PDU合段成相应的SDU2，并将合段成功后的SDU2递交至本地的PDCP的接收窗口内，本地的PDCP针对接收到的与响应消息U相应的SDU2进行解密处理和进行完整性校验，并判断响应消息U是否为“UECapabilityInformation”的响应消息，若确定响应消息U为“UECapabilityInformation”的响应消息，则将响应消息U返回给eNB本地的RRC，将接收窗口的窗长减为0，eNB本地的RRC确定接收到响应消息U，停定时器T_U。进一步的，若eNB本地的RRC确定在定时器T_U设定时长内未接收到响应消息U，则eNB本地的RRC启动延时定时器T_U’，并指示本地的RLC在T_U’超时之前继续接收响应消息U。

参阅图4所示，本发明实施例中，一种多信令下发的装置，至少包括下发单元40、接收单元41和执行单元42，其中，

下发单元40，用于向接收端下发至少两条控制信令消息；

接收单元41，用于分别接收接收端返回的针对每一条控制信令消息的响应消息，并确定各条响应消息的待处理顺序；

执行单元42，用于对接收到的各条响应消息进行格式解析处理，并基于处理结果对各条响应消息进行完整性验证，其中，发送端每判定一条响应消息通过完整性验证，若基于所述待处理顺序确定所述一条响应消息存在前序的至少一条响应消息，且所述前序的至少一条响应消息中存在未通过完整性验证的响应消息，则上报所述一条响应消息，直至所有响应消息上报完成。

可选的，在确定各条响应消息的待处理顺序时，接收单元41用于：

基于所述至少两条控制信令消息的发送顺序，确定接收端返回的，针对每一条控制信令消息的响应消息的待处理顺序。

可选的，在对任意一条响应消息进行完整性验证时，执行单元42用于：

针对接收到的所述任意一条响应消息进行解封装处理，以确定所述任意一条响应消息中包含的各个数据包的序号；

基于已确定的各个数据包的序号，在确定所有数据包接收完毕时，判定所述任意一条响应消息通过完整性验证。

可选的，执行单元42进一步用于：

若确定所述任意一条响应消息在设定时长内未通过完整性验证，则启动延时定时器；

在所述延时定时器超时之前继续接收所述任意一条响应消息。

可选的，在向接收端下发至少两条控制信令消息之后，在接收响应消息之前，下发单元40进一步用于：

基于所述至少两条控制信令消息的消息数目创建相应大小的接收窗口，所述接收窗口用于接收并验证响应消息。

可选的，在判定任意一条响应消息通过完整性验证，并基于所述待处理顺序确定所述任意一条响应消息存在前序的至少一条响应消息，且所述前序的至少一条响应消息中存在未通过完整性验证的响应消息时，上报所述任意一条响应消息之后，执行单元42进一步用于：

若判定上报的所述任意一条响应消息在接收窗口内，则确定与所述任意一条响应消息对应的控制信令消息下发成功，并将接收窗口的大小减小1。

综上所述，本发明实施例中，在发送端向接收端下发至少两条控制信令消息的过程中，当发送端接收接收端返回的针对每一条控制信令消息的响应消息时，确定各条响应消息的待处理顺序，并对接收到的各条响应消息进行格式解析处理，以及基于处理结果对各条响应消息进行完整性验证，其中，发送端每判定一条响应消息通过完整性验证，若基于上述待处理顺序确定上述一条响应消息存在前序的至少一条响应消息未通过完整性验证，则上报上述一条响应消息，直至所有响应消息上报完成。

采用上述方法，在多信令下发的过程中，发送端接收到任意一个完整的响应消息后，不再需要等待其前序的响应消息上报完成后再上报上述任意一个响应消息，这样，就避免了由于前序的响应消息接收不完整而导致后序的已接收完整的响应消息无法上报，从而降低了掉线指标，在提高下发效率的同时，提高了关键业绩指标。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样，倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (8)

1.一种多信令下发的方法，其特征在于，包括：

发送端向接收端下发至少两条控制信令消息；发送端基于所述至少两条控制信令消息的消息数目创建相应大小的接收窗口，所述接收窗口用于接收并对响应消息进行解密处理和完整性校验；

发送端分别接收接收端返回的针对每一条控制信令消息的响应消息，并确定各条响应消息的待处理顺序；

发送端对接收到的各条响应消息进行格式解析处理，并基于处理结果，针对接收到的所述各条响应消息进行解封装处理，以确定各条响应消息中包含的各个数据包的序号，并基于已确定的各个数据包的序号，在确定所有数据包接收完毕时，判定所述各条响应消息通过解密处理和完整性校验，其中，发送端每判定一条响应消息通过解密和完整性校验，若基于所述待处理顺序确定所述一条响应消息存在前序的至少一条响应消息，且所述前序的至少一条响应消息中存在未通过完整性验证的响应消息，则上报所述一条响应消息，并将所述接收窗口的大小减小1，直至所有响应消息上报完成，当所有响应消息上报完成时，接收窗口的大小减为0。

2.如权利要求1所述的方法，其特征在于，发送端确定各条响应消息的待处理顺序，具体包括：

发送端基于所述至少两条控制信令消息的发送顺序，确定接收端返回的，针对每一条控制信令消息的响应消息的待处理顺序。

3.如权利要求1所述的方法，其特征在于，进一步包括：

若发送端确定任意一条响应消息在设定时长内未通过完整性验证，则启动延时定时器；

发送端在所述延时定时器超时之前继续接收所述任意一条响应消息。

4.如权利要求1-3中任一项所述的方法，其特征在于，在发送端判定任意一条响应消息通过完整性验证，并基于所述待处理顺序确定所述任意一条响应消息存在前序的至少一条响应消息，且所述前序的至少一条响应消息中存在未通过完整性验证的响应消息时，上报所述任意一条响应消息之后，进一步包括：

若发送端判定上报的所述任意一条响应消息在接收窗口内，则确定与所述任意一条响应消息对应的控制信令消息下发成功，并将接收窗口的大小减小1。

5.一种多信令下发的装置，其特征在于，包括：

下发单元，用于向接收端下发至少两条控制信令消息；基于所述至少两条控制信令消息的消息数目创建相应大小的接收窗口，所述接收窗口用于接收并对响应消息进行解密处理和完整性校验；

接收单元，用于分别接收接收端返回的针对每一条控制信令消息的响应消息，并确定各条响应消息的待处理顺序；

执行单元，用于对接收到的各条响应消息进行格式解析处理，并基于处理结果，针对接收到的所述各条响应消息进行解封装处理，以确定各条响应消息中包含的各个数据包的序号，并基于已确定的各个数据包的序号，在确定所有数据包接收完毕时，判定所述各条响应消息通过解密处理和完整性校验，其中，发送端每判定一条响应消息通过解密和完整性校验，若基于所述待处理顺序确定所述一条响应消息存在前序的至少一条响应消息，且所述前序的至少一条响应消息中存在未通过完整性验证的响应消息，则上报所述一条响应消息，并将所述接收窗口的大小减小1，直至所有响应消息上报完成，当所有响应消息上报完成时，接收窗口的大小减为0。

6.如权利要求5所述的装置，其特征在于，在确定各条响应消息的待处理顺序时，所述接收单元用于：

基于所述至少两条控制信令消息的发送顺序，确定接收端返回的，针对每一条控制信令消息的响应消息的待处理顺序。

7.如权利要求5所述的装置，其特征在于，所述执行单元进一步用于：

若确定任意一条响应消息在设定时长内未通过完整性验证，则启动延时定时器；

在所述延时定时器超时之前继续接收所述任意一条响应消息。

8.如权利要求5-7中任一项所述的装置，其特征在于，在判定任意一条响应消息通过完整性验证，并基于所述待处理顺序确定所述任意一条响应消息存在前序的至少一条响应消息，且所述前序的至少一条响应消息中存在未通过完整性验证的响应消息时，上报所述任意一条响应消息之后，所述执行单元进一步用于：

若判定上报的所述任意一条响应消息在接收窗口内，则确定与所述任意一条响应消息对应的控制信令消息下发成功，并将接收窗口的大小减小1。

Images