CN1859625A - 长消息处理方法及装置 - Google Patents

Abstract

本发明公开了一种长消息处理方法，所述方法包括：短消息中心根据信令侧支持的最大消息长度将收到的长消息中的用户数据部分分成多个子包；为每个子包增加一个用户数据头，同时将长消息消息头中的用户数据头标识和多发标志强制置位；依次调度下发所述长消息的每个子包。本发明还公开了一种长消息处理装置，包括：消息接收单元、消息发送单元、调度单元、长度检测单元和分包处理单元。利用本发明，可以使用户发送的长消息能够完整地发送给目的用户，保证超长消息信息的完整性，有利于业务提供商的业务开展。

Description

长消息处理方法及装置

技术领域

本发明涉及移动通信技术领域，具体涉及一种长消息处理方法及装置。

背景技术

短消息是目前常用的一种数据业务，它利用信令链路实现点对点的消息传送，并通过SMPP(短消息点对点协议)为SP(业务提供商)提供了一个丰富多彩的增值业务开展平台，是一种非实时的可靠的信息传递业务。随着手机的日益普及、短消息及其增值业务的蓬勃发展，运营商以及各种移动电话用户对短消息的服务要求越来越高。SP希望通过短消息系统向不同的用户提供更多的、更人性化的服务。

随着业务的不断进步，SP用户对长消息的应用越来越多。但由于短消息中心是利用信令链路实现与移动台相关的消息传送，宝贵的无线资源对不断增长的消息长度需求形成了一个严重的制约。

在现有技术中，短消息中心的结构如图1所示：

包括：调度模块、话单模块、备份模块、缓存模块、历史数据库。短消息中心对各类消息的UDL(用户数据长度)限制在无线侧支持的范围以内。

现有短消息中心对长消息的处理流程如图2所示：

对于SP提交上来的UDL超长的短消息，先将其存放到缓存模块中，然后由短消息中心按照无线侧支持的最大UDL在解码的时候将其用户数据截短，通过丢弃一部分消息的内容，将消息转换成一条普通消息。再将截短后的消息送去SCP(业务控制点)进行按条计费。如果SCP计费通过，短消息中心再将消息送到备份模块进行备份，直到消息成功下发或因为超过有效期被删除后，短消息中心会同步删除备份消息，并将截短后的消息入历史数据库，向话单模块写计费话单。整个处理过程由调度模块统一调度完成。由于消息的UDL在解码的时候就已经限制在了无线侧支持的范围以内，因此在整个处理过程中，不需要对消息的UD在长度方面作任何特殊的处理，只要消息经过解码后就统一按照普通消息进行处理。

这种处理方式会造成消息中很多重要信息的丢失，不能正确传达发起短消息的用户的真正意图，严重影响了用户的信息交流，特别是SP用户的业务开展，进而影响到短消息系统增值业务资源的开发。

发明内容

本发明的目的是提供一种长消息处理方法，以克服现有技术中对于超长的消息一律将其用户数据截短为无线侧支持的长度范围造成消息中重要信息丢失的缺点，保证超长消息信息的完整性，更好地支持SP业务的开展。

本发明的另一个目的是提供一种长消息处理装置，为业务提供商更好地开展业务提供设备支持。

为此，本发明提供如下的技术方案：

一种长消息处理方法，所述方法包括：

短消息中心根据信令侧支持的最大长度将收到的长消息中的用户数据部分分成多个子包；

为每个子包增加一个用户数据头，同时将长消息消息头中的用户数据头标识和多发标志强制置位；

依次调度下发所述长消息的每个子包。

所述方法进一步包括：

短消息中心对接收的消息中的用户数据长度进行检测，判断是否为长消息。

所述短消息中心对接收的消息中的用户数据长度进行检测时，

如果所述消息采用的是GSM 7bit的编码方式且支持转义字符，则首先统计消息中带有的转义字符个数，然后再确定消息编码后的实际用户数据长度；如果不支持转义字符，则直接根据消息中的用户数据长度信息获取用户数据长度。

所述方法进一步包括：

如果短消息中心收到的长消息已经是做过分包处理的消息，则拒绝该长消息。

所述短消息中心按以下步骤判断收到的长消息是否为做过分包处理的消息：

获取所述长消息的用户数据头；

如果该用户数据头中带有分包信息，则表明所述长消息为做过分包处理的消息。

所述短消息中心对收到的长消息中的用户数据部分进行分包时，将采用GSM 7bit编码方式的转义字符与同该转义字符一起表示一个完整意义的字符放在同一个子包中，将UCS2编码方式的表示一个完整意义的相邻两个字节放在一个子包中。

所述长消息的所有子包共享所述长消息中的其他信息。

在对所述长消息的用户数据部分进行分包时，如果该消息原来已经拥有用户数据头，则在原来的用户数据头中加上分包信息，然后再将该带有分包信息的用户数据头加到每个子包上。

每个子包的用户数据头中至少包括：连续短消息的信息参考号、连续短消息的消息总数、连续短消息的序列号。

所述方法进一步包括：

当短消息中心收到用户按照SMPP34协议提交的替换消息时，将被替换长消息的所有用户数据子包备份，并将被替换消息的所有用户数据子包删除；

将替换消息的用户数据子包添加到被替换消息的用户数据字段中；

如果添加成功，则删除备份的用户数据子包；

如果添加失败，则将备份的用户数据子包恢复。

所述方法进一步包括：

如果所述用户提交的替换消息是长消息，则在替换成功后，将替换后的消息中所有子包共享的消息头内的用户数据头标识以及多发标志强制置位。

所述方法进一步包括：

如果需要对所述长消息进行预付费用户鉴权，则在分包完成后短消息中心将该长消息的第一个子包和长消息的实际用户数据长度发送给业务控制点；

业务控制点根据收到的子包和用户数据长度对所述长消息进行计费。

所述业务控制点对所述长消息进行按条计费或者按子包计费。

所述方法进一步包括：

在依次调度下发所述长消息的第一个子包前，根据所述长消息的长度透传，对该长消息进行备份。

所述方法进一步包括：

当所述长消息的一个子包下发失败被删除时，则该子包后的所有子包均被删除；

如果发送所述长消息的用户要求状态报告，则同时向该用户返回发送失败消息。

所述方法进一步包括：

当所述长消息的所有子包下发成功后，将每个子包当作一条独立的消息存入历史数据库。

所述方法进一步包括：

当需要查询用户发送的消息记录时，从所述历史数据库中回读各子包；

根据各子包的用户数据头中的分包信息对读出的子包进行组包操作，将属于同一长消息的各子包合成一条完整的长消息显示。

一种长消息处理装置，包括：消息接收单元、消息发送单元、用于协议所述装置中各单元工作的调度单元、用于检测所述消息接收单元中接收的消息长度的长度检测单元，还包括：

分包处理单元，分别与长度检测单元及所述调度单元相连，用于根据信令侧支持的最大长度对所述长度检测单元检测出的长消息进行分包处理，并将分包后的各子包交由调度单元，由调度单元调度消息发送单元依次下发长消息的每个子包。

所述装置进一步包括：

分包信息检测单元，分别与所述长度检测单元及分包处理单元相连，用于检测所述长度检测单元检测出的长消息是否已做过分包处理，并向所述调度单元返回检测结果。

所述装置进一步包括：

消息备份单元，用于在所述消息发送单元下发所述长消息的第一个子包前，存储所述调度单元根据所述消息长度透传的长消息。

所述装置进一步包括：

历史数据库，用于在所述消息发送单元将长消息的所有子包下发成功后，以子包为单位存储所述长消息。

当需要查询用户发送的消息记录时，由所述调度单元从所述历史数据库中回读各子包，并根据各子包的用户数据头中的分包信息对读出的子包进行组包操作，将属于同一长消息的各子包合成一条完整的长消息。

由以上本发明提供的技术方案可以看出，本发明由短消息中心将现有技术中对普通短消息的处理和对长消息的处理整合在一起，将长消息作为一个多包消息的办法，根据信令侧支持的最大长度将收到的长消息中的用户数据部分分成多个子包，这些子包共享长消息的消息头信息，不仅便于对消息进行整体性的处理，而且减小了现有短消息中心支持长消息带来的内存压力；在消息下发时，将长消息作为一条带有多个用户数据子包的多发消息对每个子包进行依次调度下发，每次下发一个子包，最大限度地保证了消息有序不丢失地下发到终端；在短消息中心与SCP进行消息交互时，使用一个子包加上消息长度的方式，便于传输，同时方便了对运营商长、短消息各种计费方案的支持。利用本发明，不仅可以满足用户对长消息的需求，而且可以合理地避开无线资源对消息长度的制约，能够使业务提供商更好地开展业务，为用户提供更好的服务。

附图说明

图1是现有技术中短消息中心及其外围功能实体结构示意图；

图2是现有技术中长消息处理的业务流程；

图3是本发明方法的实现流程图；

图4是用户提交的长消息及分包后的消息结构示意图；

图5是本发明一个应用实例的实现流程图；

图6是本发明装置第一实施例的原理框图；

图7是本发明装置第二实施例的原理框图。

具体实施方式

本发明的核心在于由短消息中心对收到的长消息进行分包处理，根据信令侧支持的最大长度将收到的长消息中的用户数据部分分成多个子包，为每个子包增加一个用户数据头，在该用户数据头中包含了必要的分包信息，以表明哪些子包属于同一个长消息，这些子包共享长消息中的其他信息。在消息下发时，短消息中心将长消息作为一条带有多个用户数据子包的多发消息对每个子包进行依次调度下发，每次下发一个子包，以保证长消息有序不丢失的下发到终端。

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和实施方式对本发明作进一步的详细说明。

参照图3，图3示出了本发明方法的实现流程，包括以下步骤：

步骤301：短消息中心接收用户提交的消息。这些消息可以是以下消息中的任何一种消息：

用户数据长度大于信令侧支持的最大用户数据长度的普通消息submit_sm、替换先前提交的一条普通消息的控制消息replace_sm、submit_sm或SMPP34协议支持的DataSM的payload数据(相当于用户数据的一个字段，通常用来保存长度较大的用户数据)长度大于信令侧支持的最大用户数据长度的消息。

步骤302：判断接收的消息是否为长消息。

短消息中心通过对接收的消息中的用户数据长度的检测来判断是否为长消息。

本技术领域人员知道，消息的编码可以采用多种方式，比如：GSM 7bit编码方式，8bit编码方式以及UCS2编码方式等。如果短消息中心接收的消息采用的是GSM 7bit的编码方式且支持转义字符，则首先统计消息中带有的转义字符个数，然后再确定消息编码后的实际用户数据长度；如果不支持转义字符，则可直接根据消息中的用户数据长度信息得到实际的用户数据长度。

如果得到的实际用户数据长度超过了无线网络的最大长度，则收到的消息为长消息，否则为普通的消息。

如果短消息中心判断收到的消息为长消息，则进到步骤303；否则，直接进到步骤306。

步骤303：判断该长消息是否已做过分包处理。如果该长消息已做过分包处理，则进到步骤304；否则，进到步骤305。

本技术领域人员知道，有些终端对其发送的消息是支持分包功能的(比如，通过SMPP3.4协议连接到短消息中心的终端)。预先设定发送消息的最大长度，当用户需要发送的数据超过该最大长度时，终端自动对用户输入的消息进行分包处理。因此，如果短消息中心支持这种终端，则短消息中心就有可能收到已经由发起消息的终端进行分包处理后的消息，而终端允许输入的消息最大长度不一定与无线网络信令支持的消息的最大长度相同。如果终端允许输入的消息最大长度小于无线网络信令支持的消息的最大长度，则短消息中心收到该消息后，可以认为其为普通短消息，按照现有流程进行处理并下发；如果终端允许输入的消息最大长度大于无线网络信令支持的消息的最大长度，就需要短消息对这种情况进行判断，决定对其处理方式。当然，如果网络不支持这种终端，则步骤303也可省略。

在检查该长消息是否已做过分包处理时，可以检查消息的用户数据头中是否已经带有分包信息，比如检查消息的用户数据头中是否包含连续短消息的信息参考号sar_msg_ref_num、连续短消息的消息总数sar_total_segments和连续短消息的特殊序列号sar_segment_seqnum三个TLVs(标签Tag、长度Length和值Value结构)。

如果消息已经被终端分包，则由于该消息的包头中已经包含了以上的分包信息，短消息中心不能对新的分包信息进行处理，因此，短消息中心不能再对该消息进行分包，直接认为消息不合法，拒绝消息。

步骤304：拒绝该消息。此时，可以向发送该消息的终端返回消息发送失败应答消息。

步骤305：短消息中心对该长消息进行分包处理。

短消息中心根据信令侧支持的最大长度将收到的长消息中的用户数据部分分成多个子包。

用户提交的长消息及分包后的消息结构可由图4表示：

为每个子包加上一个用户数据头(UDH)，该用户数据头中至少包含sar_msg_ref_num、sar_total_segments和sar_segment_seqnum这三个TLVs以及消息原有的UDH信息。

可以将所有用户数据子包存放在一个动态数组中，动态数组中所有的用户数据子包共享该消息的其他全部信息，比如，将消息的UD(用户数据)按照子包存放在一个vector(向量)中，然后再将整个存放UD的vector作为一个整体，存放在消息结构内，让所有的UD子包共享消息的其他信息。以使各子包不重复占用消息的资源，节省短消息中心的内存资源。

现有SMPP3.4协议规定，短消息中心可以接收带有用户数据头的消息。因此，在对长消息的用户数据部分进行分包时，为了简化分包的处理，如果该消息原来已经拥有用户数据头，可以在原来的用户数据头中加上分包信息，然后再将该带有分包信息的用户数据头加到每个子包上。

前面已经提到，短消息中心支持的消息数据的编码方式可以有多种。因此，需要注意的是，在分包时，如果消息采用的是GSM 7bit的编码方式，不能将转义字符分开在两个包中；如果消息采用的是UCS2编码(即采用unicode编码方案的字符)方式，则必须保证不会将一个双字节的USC2编码分开存放在不同的子包中。也就是说，需要将采用GSM 7bit编码方式的转义字符与同该转义字符一起表示一个完整意义的字符放在同一个子包中，将UCS2编码方式的表示一个完整意义的相邻两个字节放在一个子包中。

步骤306：判断是否需要对预付费用户(PPS用户)鉴权。

当然，如果该用户是后付费用户或者运营商对所有用户提供免费短消息服务，则该步骤也可以省略。

如果需要，则进到步骤307；否则，进到步骤308。

步骤307：将消息的第一个子包与消息的用户数据长度传送给SCP，进行计费。

短消息中心在和SCP通过消息进行交互时，短消息中心将短消息的子包内容，以及解码前的UDL(用户数据长度)发送到SCP，这样处理避免了不必要的信息处理，也便于工作于长消息的计费处理。运营商可以根据实际情况进行按条计费或按子包计费，可以支持长消息和短消息的各种计费方式，比如，对第一个包计费、按包数计费、对所有包整体计费等，也可以支持在不同计费策略Charge-by-sent(按照消息提交进行计费，即消息提交到短信中心就收费，不管成功与否)和Charge-by-deliver(根据消息下发计费，只有消息发送成功了才收费)下，实施以上计费方案。

步骤308：根据长消息的长度透传对长消息进行备份。

本发明中在进行长消息的备份处理时，直接根据长消息的长度进行备份和回读，中间不进行编解码操作，将消息直接透传。

步骤309：依次调度下发长消息的每个子包。

在进行消息下发时，短消息中心将长消息作为一条带有多个用户数据子包的多发消息对每个子包进行依次调度下发，每次下发一个子包，以便最大限度地保证消息有序不丢失地下发到终端。如果其中有一个子包下发失败，后面的消息子包就不进行下发，直到下发失败的那个子包能成功下发或者失败被删除时，才对剩下的子包进行相应的操作。如果有一个子包被删除，则后面的子包都被删除，认为消息下发失败。如果发送所述长消息的用户要求状态报告，则同时向该用户返回发送失败消息。

步骤310：当长消息的所有子包下发成功后，将每个子包当作一条独立的消息存入历史数据库。

将长消息入数据库时，作为多发消息将每个子包当作一条独立的消息入库。这样，当需要查询用户发送的消息记录时，从该历史数据库中回读各子包，然后根据各子包的用户数据头中的分包信息对读出的子包进行组包操作，将属于同一长消息的各子包合成一条完整的长消息显示。

SMPP34协议规定，用户可以通过replace消息提交一条替换消息，以替换先前提交的长消息。对于这种情况，短消息中心需要将被替换长消息的所有用户数据子包备份，并将被替换消息的所有用户数据子包删除。然后将替换消息的用户数据子包添加到被替换消息的用户数据字段中。如果添加成功，则删除备份的用户数据子包，向用户返回替换成功消息；如果添加失败，则将备份的用户数据子包恢复，向用户返回替换失败消息。这样，保证了在消息替换失败时进行回滚，恢复原消息。

如果替换消息是长消息，则处理方式与上述相同，只是替换成功后，要将替换后消息的消息头中的用户数据头标识(UDHI)和多发标志(more_messages_to_send)强制置位，以表示替换后的消息是一条带有用户数据头的多发消息。

由上述流程可见，本发明不仅可以实现长消息不丢失信息的下发，而且对长消息的处理简单，不需要占用短消息中心过多的资源，并为运营商各种不同计费方式提供了有效的信息。

下面结合图5所示举例对本发明作进一步描述。

假定12593为支持SMPP34协议的SP用户，该用户发送一条长消息到13602，长消息处理流程为：

1、12593用户提交一条GSM 7bit编码的长消息给13602，消息长度为230，带有5个转义字符；

2、短消息中心收到该消息后，和现有的短消息中心处理不同，先统计消息的用户数据中含有转义字符的个数为5，并计算出消息下发时的实际UDL(用户数据长度)为235；

3、短消息中心判断出该消息是一条长消息(UDL＞160)，不再按照现有的处理方式将消息截断成信令支持的最大长度，而是将消息的用户数据进行分包并将分包信息以sar_msg_ref_num、sar_total_segments和sar_segment_seqnum三个TLVs的形式存放到UDH(用户数据头)中。所有的子包都存放在消息的一个动态数组中，短消息中心只维护一份该条消息的共享资源；

4、由于需要进行PPS鉴权，短消息中心将消息的第一个分包以及消息的总长度发送给SCP，便于SCP根据实际需要进行按条计费或者按下发的包进行计费，比起现在的按条计费，提供了更多的选择；

5、SCP向短消息中心返回鉴权计费结果，回ACK(确认)消息；

6、短消息中心对分包后的长消息作为一条多发消息进行调度，如果第一个子包下发成功，马上下发后面的子包；如果第一个子包下发失败，后面的子包等待第一个子包下发成功后再进行下发；

7、该消息的第一个子包下发失败，消息堵在内存中，12593用户提交一条GSM 7bit编码的replace消息，消息长度为230，无转义字符；

8、短消息中心先将原消息动态数组中的全部子包备份，然后删除消息下的所有子包；

9、再将替换消息的UD子包添加到被替换消息的动态数组中；

10、如果添加成功，由于replace消息是一条长消息，需要将UDHI(用户数据头标识)和多发标志强制置位；

11、返回替换成功消息；

12、如果添加失败，恢复消息原来的子包；

13、返回替换失败消息。

参照图6，图6示出了本发明装置第一实施例的原理框图：

该装置包括：消息接收单元S1、消息发送单元S2、调度单元S3、长度检测单元S4、分包处理单元S5，如果需要，还可包括：消息备份单元S6、历史数据库S7。

其中，消息接收单元S1和消息发送单元S2分别用于接收用户发送的消息；调度单元S3用于协议该装置中其他各单元的工作；分包处理单元S5用于根据信令侧支持的最大长度对所述长度检测单元检测出的长消息进行分包处理，并将分包后的各子包交由调度单元，由调度单元S3调度消息发送单元S2依次下发长消息的每个子包。

消息备份单元S6用于在消息发送单元S2下发长消息的第一个子包前，存储调度单元S3根据消息长度透传的长消息；历史数据库S7用于在消息发送单元S2将长消息的所有子包下发成功后，以子包为单位存储该长消息。

当消息接收单元收到用户提交的消息后，首先由调度单元通知长度检测单元检查消息用户数据的长度，如果是一条普通的消息就作为一个只有单一数据包的消息，直接送去SCP(业务控制点)进行计费(如果是后付费用户则此步可以省略)。如果SCP计费通过，短消息中心再将消息按照消息长度透传到备份模块进行备份。直到消息成功下发或因为超过有效期被删除后，短消息中心会同步删除备份消息，并将该消息入历史数据库，写计费话单(处理流程与现有技术相同)；如果是长消息，则由调度单元调度分包处理单元对该长消息进行分包处理：根据信令侧支持的最大长度将消息UD分成多个子包，为每个子包加上一个用户数据头，用户数据头中至少包含sar_msg_ref_num、sar_total_segments和sar_segment_seqnum这三个TLVs以及消息原有的用户数据头信息。可以将所有子包存放在一个动态数组中，动态数组中所有的UD子包共享消息的其他全部信息，不重复占用消息的资源。

分包完成后，由消息备份单元对该长消息进行备份存储。在进行长消息的备份处理时，直接根据长消息的长度进行备份和回读，中间不进行编解码操作，由调度单元直接将长消息透传给消息备份单元进行存储。

然后，调度消息发送单元对该长消息进行下发。下发时，调度单元将长消息作为一条带有多个用户数据子包的多发消息对每个子包进行依次调度下发，每次下发一个子包，最大限度的保证消息有序不丢失的下发到终端。如果其中有一个子包下发失败，后面的消息子包就不进行下发，直到下发失败的那个子包能成功下发或者失败被删除时，才对剩下的子包进行对应的操作。如果有一个子包被删除，则后面的子包都被删除，认为消息下发失败。

一条长消息发送完成后，为了保存历史记录，可以将发送成功的长消息放入历史数据库中，长消息入数据库时，以子包为单位存储在历史数据库中，也就是说，每个子包被当作一条独立的消息存入该历史数据库。

当需要查询用户发送的消息记录时，由调度单元从该历史数据库中回读各子包，并根据各子包的用户数据头中的分包信息对读出的子包进行组包操作，将属于同一长消息的各子包合成一条完整的长消息。

如果用户通过replace消息提交一条替换消息替换先前提交的长消息，调度单元将被替换长消息的所有用户数据子包备份，并将被替换消息的所有用户数据子包删除，然后将替换消息的用户数据子包添加到被替换消息的用户数据字段中。如果添加成功，则删除备份的用户数据子包，向用户返回替换成功消息；如果添加失败，则将备份的用户数据子包恢复，向用户返回替换失败消息。这样，保证了在消息替换失败时进行回滚，恢复原消息。

如果替换消息是长消息，则在提交替换消息的过程中，同前面处理长消息的方式一样，先将替换消息作为一条长消息对其UD进行分包处理，然后按照上述方法对替换消息进行替换，只是替换成功后，调度单元将替换后的长消息消息头中的用户数据头标识和多发标志强制置位，以表示替换后的消息是一条带有用户数据头的多发消息。

虽然通过实施例描绘了本发明，本领域普通技术人员知道，本发明有许多变形和变化而不脱离本发明的精神，希望所附的权利要求包括这些变形和变化而不脱离本发明的精神。

Claims (22)

1、一种长消息处理方法，其特征在于，所述方法包括：

短消息中心根据信令侧支持的最大长度将收到的长消息中的用户数据部分分成多个子包；

为每个子包增加一个用户数据头，同时将长消息消息头中的用户数据头标识和多发标志强制置位；

依次调度下发所述长消息的每个子包。

2、根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

短消息中心对接收的消息中的用户数据长度进行检测，判断是否为长消息。

3、根据权利要求2所述的方法，其特征在于，

所述短消息中心对接收的消息中的用户数据长度进行检测时，如果所述消息采用的是GSM 7bit的编码方式且支持转义字符，则首先统计消息中带有的转义字符个数，然后再确定消息编码后的实际用户数据长度；如果不支持转义字符，则直接根据消息中的用户数据长度信息获取用户数据长度。

4、根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

如果短消息中心收到的长消息已经是做过分包处理的消息，则拒绝该长消息。

5、根据权利要求4所述的方法，其特征在于，所述短消息中心按以下步骤判断收到的长消息是否为做过分包处理的消息：

获取所述长消息的用户数据头；

如果该用户数据头中带有分包信息，则表明所述长消息为做过分包处理的消息。

6、根据权利要求1所述的方法，其特征在于，所述短消息中心对收到的长消息中的用户数据部分进行分包时，将采用GSM 7bit编码方式的转义字符与同该转义字符一起表示一个完整意义的字符放在同一个子包中，将UCS2编码方式的表示一个完整意义的相邻两个字节放在一个子包中。

7、根据权利要求1所述的方法，其特征在于，所述长消息的所有子包共享所述长消息中的其他信息。

8、根据权利要求1或6或7所述的方法，其特征在于，

在对所述长消息的用户数据部分进行分包时，如果该消息原来已经拥有用户数据头，则在原来的用户数据头中加上分包信息，然后再将该带有分包信息的用户数据头加到每个子包上。

9、根据权利要求1所述的方法，其特征在于，每个子包的用户数据头中至少包括：连续短消息的信息参考号、连续短消息的消息总数、连续短消息的序列号。

10、根据权利要求9所述的方法，其特征在于，所述方法进一步包括：

当短消息中心收到用户按照SMPP34协议提交的替换消息时，将被替换长消息的所有用户数据子包备份，并将被替换消息的所有用户数据子包删除；

将替换消息的用户数据子包添加到被替换消息的用户数据字段中；

如果添加成功，则删除备份的用户数据子包；

如果添加失败，则将备份的用户数据子包恢复。

11、根据权利要求10所述的方法，其特征在于，所述方法进一步包括：

如果所述用户提交的替换消息是长消息，则在替换成功后，将替换后的消息中所有子包共享的消息头内的用户数据头标识以及多发标志强制置位。

12、根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

如果需要对所述长消息进行预付费用户鉴权，则在分包完成后短消息中心将该长消息的第一个子包和长消息的实际用户数据长度发送给业务控制点；

业务控制点根据收到的子包和用户数据长度对所述长消息进行计费。

13、根据权利要求12所述的方法，其特征在于，所述业务控制点对所述长消息进行按条计费或者按子包计费。

14、根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

在依次调度下发所述长消息的第一个子包前，根据所述长消息的长度透传，对该长消息进行备份。

15、根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

当所述长消息的一个子包下发失败被删除时，则该子包后的所有子包均被删除；

如果发送所述长消息的用户要求状态报告，则同时向该用户返回发送失败消息。

16、根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

当所述长消息的所有子包下发成功后，将每个子包当作一条独立的消息存入历史数据库。

17、根据权利要求16所述的方法，其特征在于，所述方法进一步包括：

当需要查询用户发送的消息记录时，从所述历史数据库中回读各子包；

根据各子包的用户数据头中的分包信息对读出的子包进行组包操作，将属于同一长消息的各子包合成一条完整的长消息显示。

18、一种长消息处理装置，包括：消息接收单元、消息发送单元、用于协议所述装置中各单元工作的调度单元、用于检测所述消息接收单元中接收的消息长度的长度检测单元，其特征在于，还包括：

分包处理单元，分别与长度检测单元及所述调度单元相连，用于根据信令侧支持的最大长度对所述长度检测单元检测出的长消息进行分包处理，并将分包后的各子包交由调度单元，由调度单元调度消息发送单元依次下发长消息的每个子包。

19、根据权利要求18所述的装置，其特征在于，所述装置进一步包括：

分包信息检测单元，分别与所述长度检测单元及分包处理单元相连，用于检测所述长度检测单元检测出的长消息是否已做过分包处理，并向所述调度单元返回检测结果。

20、根据权利要求18或19所述的装置，其特征在于，所述装置进一步包括：

消息备份单元，用于在所述消息发送单元下发所述长消息的第一个子包前，存储所述调度单元根据所述消息长度透传的长消息。

21、根据权利要求18或19所述的装置，其特征在于，所述装置进一步包括：

历史数据库，用于在所述消息发送单元将长消息的所有子包下发成功后，以子包为单位存储所述长消息。

22、根据权利要求18或19所述的装置，其特征在于，

当需要查询用户发送的消息记录时，由所述调度单元从所述历史数据库中回读各子包，并根据各子包的用户数据头中的分包信息对读出的子包进行组包操作，将属于同一长消息的各子包合成一条完整的长消息。

Images