CN103108295B - 一种话单包的处理方法和系统 - Google Patents

一种话单包的处理方法和系统 Download PDF

Info

Publication number
CN103108295B
CN103108295B CN201110357581.0A CN201110357581A CN103108295B CN 103108295 B CN103108295 B CN 103108295B CN 201110357581 A CN201110357581 A CN 201110357581A CN 103108295 B CN103108295 B CN 103108295B
Authority
CN
China
Prior art keywords
bag
ticket
serial number
gsn
cgf
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
CN201110357581.0A
Other languages
English (en)
Other versions
CN103108295A (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.)
Guangdong Oppo Mobile Telecommunications Corp Ltd
Original Assignee
ZTE Corp
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 ZTE Corp filed Critical ZTE Corp
Priority to CN201110357581.0A priority Critical patent/CN103108295B/zh
Priority to PCT/CN2012/084485 priority patent/WO2013067975A1/zh
Priority to US14/356,857 priority patent/US9332092B2/en
Priority to EP12847928.4A priority patent/EP2779713B1/en
Publication of CN103108295A publication Critical patent/CN103108295A/zh
Priority to HK14110860A priority patent/HK1197342A1/zh
Application granted granted Critical
Publication of CN103108295B publication Critical patent/CN103108295B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/41—Billing record details, i.e. parameters, identifiers, structure of call data record [CDR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/73—Validating charges
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/74—Backing up
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/82—Criteria or parameters used for performing billing operations
    • H04M15/8214—Data or packet based

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种话单包的处理方法和系统，方法包括：通用分组无线服务支持节点(GSN)向计费网关功能(CGF)发送话单包，该话单包为正常包或可疑重包，且用于发送话单包的消息的消息头中包含流水号、消息体中包含组包时间；CGF向GSN发送收到该话单包的回应消息，且该回应消息中的包传输响应命令(Packet Transfer Response Command)信息元用于标识该回应消息是针对正常包或针对可疑重包。通过本发明，实现了在不限制网络传输速度的情况下，解决可疑重包占用流水号资源问题。

Description

一种话单包的处理方法和系统
技术领域
本发明涉及通信领域，尤其涉及一种话单包的处理方法和系统。
背景技术
在第三代合作伙伴计划(3GPP，The 3rd Generation Partnership Project)描述的电信网络中，GTP’(GPRS protocol，used for CDR transport)协议V2版本的主要功能如下所述：
图1示出了3GPP网络中计费触发功能(CTF，Charging Trigger Function)、计费数据功能(CDF，Charging Data Function)和计费网关功能(CGF，ChargingGatewayFunction)之间的关系，其中，Ga接口是CDF向CGF传输计费话单(CDRs，Charging DataRecords)的通讯接口，Ga接口遵从的协议是GTP’协议。
图2示出了GTP’协议的承载情况，从图中可以看出，GTP’协议可以用用户数据报协议(UDP，User Datagram Protocol)或者传输控制协议(TCP，Transmission ControlProtocol)承载。
GTP’协议定义的主要内容如下：
一、GTP’消息头(GTP’Message Header)
GTP’消息头重用通用分组无线服务隧道协议(GTP，GPRS TunnellingProtocol)消息头(GTP Message Header)，如图3所示，GTP Message Header中定义了一些标志位(Version、PT...)，消息类型(Message Type)、Length和流水号(Sequence Number)。
二、GTP’消息类型(GTP’Message Type)
下面是GTP’协议使用的消息类型，前三种重用了GTP协议的消息类型，后六种是GTP’协议新增的消息类型：
1、Echo Request(向对方节点握手请求)；
2、Echo Response(向对方节点回应握手请求)；
3、Version Not Supported(回应本节点不支持对方节点发送消息的版本，并告知本节点能够支持的最新版本号，该消息无须回应)；
4、Node Alive Request(通知对方本节点已经激活)；
5、Node Alive Response(向对方节点回应Node Alive Request)；
6、Redirection Request(CGF通知GSN，指示GSN将话单发送到其他CGF)；
7、Redirection Response(GSN向CGF回应Redirection Request)；
8、Data Record Transfer Request(GSN向CGF发送话单包)；
9、Data Record Transfer Response(CGF向GSN回应Data RecordTransferRequest)。
上述消息中的Data Record Transfer Request和Data RecordTransferResponse是传输CDRs时使用的消息，是GTP’协议的核心内容。
其中，Data Record Transfer Request的消息结构如下表1所示，可以包括以下5种信息元(IE，Information Element)：
1、Packet Transfer Command(包传输命令)；
2、Data Record Packet(话单包)；
3、Sequence Numbers of Released Packets(释放包的流水号)；
4、Sequence Numbers of Cancelled Packets(删除包的流水号)；
5、Private Extension(用户或运营商自定义的扩展信息)。
Information Element Presence requirement
Packet Transfer Command Mandatory(必选)
Data Record Packet Conditional(受限)
Sequence Numbers of Released Packets Conditional
Sequence Numbers of Cancelled Packets Conditional
Private Extension Optional(可选)
表1
其中，Packet Transfer Command是必选参数，目前有以下四种值：
1、1＝′Send Data Record Packet′：
发送正常话单包，此时IE：Data Record Packet必选，该IE的结构如下表2所示：
表2
2、2＝′Send possibly duplicated Data Record Packet′：
发送可能重复话单包，此时IE：Data Record Packet必选，该IE结构如前述表2所示。
当现网存在多个CGF时，由于CGF1出现网络故障，GSN向CGF1发送的话单包没有及时收到回应，此时GPRS支持节点(GSN)会将同样的话单包以′Send possibly duplicatedData Record Packet′命令的方式发送给CGF2(备用CGF)，CGF2收到这样的数据包后只是暂时缓存在本地，直到CGF2收到GSN对应数据包的′Cancel/Release Data Record Packet′命令后，才会删除缓存在本地的可疑重复话单包(Cancel)或者将该可疑重复话单包释放(Release)到正常的话单目录。
3、3＝′Cancel Data Record Packet′：
删除可疑重复话单包，此时IE：Sequence Numbers of Cancelled Packets必选，该IE的结构如下表3所示：
表3
4、4＝′Release Data Record Packet′：
释放可疑重复话单包，此时IE：Sequence Numbers of Released Packets必选，该IE的结构如下表4所示：
表4
Data Record Transfer Response消息是CGF用来回应Data RecordTransferRequest消息的，Data Record Transfer Response的消息结构如下表5所示：
Information Element Presence requirement
Cause Mandatory
Requests Responded Mandatory
Private Extension Optional
表5
该消息必须包含Cause(原因)和Requests Responded(请求响应)两种IE，其中Cause表示响应结果(接收或者拒绝的原因)；Requests Responded表示接收成功的话单包流水号，其结构如下表6所示，该IE可以同时包含多个话单包的流水号，即一个Data RecordTransfer Response消息可以回复多个Data RecordTransfer Request。
表6
GTP’协议中话单包传输的方法包括：
一、正常情况下话单包传输，其传输过程如图4所示，主要包括以下步骤：
步骤401，GSN发送话单包到CGF，发送的相应的消息为Data RecordTransferRequest，其中Packet Transfer Command参数是Send Data Record Packet，消息头中流水号为N；
步骤402，CGF收到并处理消息，并存储包中的话单到本地；
步骤403，CGF发送响应消息到GSN，消息内容为Data Record TransferResponse，其中Requests Responded参数中包含了流水号N，Cause参数置为Request Accepted(请求接受)；
步骤404，GSN接收消息Data Record Transfer Response后，从缓存内删除流水号为N的话单包。
如果GSN接收响应时失败，会在额定时间内和达到设定次数前重新发送请求。
二、话单包未正确接收前GSN-CGF1之间的连接中断，其传输过程如图5所示，主要包括以下步骤：
步骤501，GSN向CGF1(主用CGF)发Data Record Transfer Request消息，其中Packet Transfer Command参数是Send Data Record Packet，消息头的流水号为M。
步骤502，由于GSN与CGF1之间失去联系，CGF1没有收到话单包。
步骤503，GSN无法收到响应。
步骤504，GSN检测与CGF2(备用CGF)之间的链路(用Echo Request)，如果正常，则GSN将与送往CGF1相同的话单包送往CGF2，使用Data RecordTransfer Request消息，Packet Transfer Command参数是Send possible duplicatedData Record Packet，消息头中的流水号为N。
步骤505，CGF2收到并处理话单包，由于该话单包被标识为possibleduplicated(可能重复)，因此CGF2只缓存该话单包，并不立刻送往计费系统(BS，Billing System)。
步骤506，CGF2发送正确接收确认信息给GSN，采用Data RecordTransferResponse消息，其中Requests Responded参数中包含了流水号N，Cause参数置为Request Accepted。
步骤507，GSN可以将成功发送的话单包(但可能重复)删除，但是仍然保留该话单包发向CGF1和CGF2的流水号(即M和N)。
步骤508，CGF1恢复以后，向GSN发送Node Alive Request消息，GSN获知可以与CGF1进行通信。
步骤509，GSN采用Node Alive Response消息确认。
步骤510，对于前面(步骤501中)未得到确认的Data Record Transfer Request消息，GSN向CGF1发送空的测试话单包，空话单包仅仅是Data Record Packet参数中不包含话单数据，其它都一样(消息头中的流水号还是M)。
步骤511，CGF1以Data Record Transfer Response消息响应，其中RequestsResponded参数中包含了流水号M，Cause参数置为Request Accepted。由于在这之前CGF1已经与GSN失去联系，CGF1并未收到过该话单包，所以对于测试话单包它认为是新的可以接受。
步骤512，GSN收到CGF1的回应消息后，获知CGF1并未处理测试话单包，通知CGF2可以将该话单包送给BS，采用的消息是Data Record TransferRequest，Packet TransferCommand参数是Release Data Record Packet。其中Sequence Numbers of the ReleasedPackets参数中包含了流水号N。
步骤513，CGF2可以将话单包传向BS。
步骤514，CGF2向GSN发Data Record Transfer Response消息，其中RequestsResponded参数中包含了流水号N，Cause参数置为Request Accepted。
三、话单包已经正确接收后GSN-CGF1之间链路中断，其传输过程如图6所示，主要包括以下步骤：
步骤601，GSN向CGF1(主用CGF)发Data Record Transfer Request消息，PacketTransfer Command参数是Send Data Record Packet，消息头的流水号为M。
步骤602，CGF1收到话单包后将包中话单安全保存。
步骤603，GSN与CGF1之间通信中断，GSN无法收到CGF1的回应。
步骤604，GSN检测与备用CGF(CGF2)之间的链路(用Echo Request)，如果正常，则GSN将与送往CGF1相同的CDR送往CGF2，使用Data RecordTransfer Request消息，PacketTransfer Command参数是Send possible duplicatedData Record Packet，消息头的流水号为N。
步骤605，CGF2接收并处理该话单包，由于该话单包被标识为possibleduplicated，因此CGF2只缓存该话单包，并不立刻送往BS。
步骤606，CGF2发送正确接收确认信息给GSN，采用Data RecordTransferResponse消息，其中Requests Responded参数中包含了流水号N，Cause参数置为Request Accepted。
步骤607，GSN可以将成功发送的话单包(但可能重复)删除，但是仍然保留该话单包发向CGF1和CGF2的流水号(即M和N)。
步骤608，CGF1恢复以后，向GSN送Node Alive Request消息，GSN获知可以与CGF1进行通信。
步骤609，GSN采用Node Alive Response消息确认。
步骤610，对于前面(步骤601中)未得到确认的Data Record Transfer Request消息，GSN向CGF1发送空的测试话单包，空话单包仅仅是Data Record Packet参数中不包含话单数据，其它都一样(消息头中的流水号还是M)。
步骤611，CGF1以Data Record Transfer Response消息响应，其中RequestsResponded参数中包含了流水号M，Cause参数置为Request related topossiblyduplicated packets already fulfilled。由于在CGF1与GSN失去联系之前，CGF1已经保存该话单包，因此对于测试话单包其认为是重复的。
步骤612，GSN收到CGF1的回应消息后，知道CGF1已经接收并保存该话单包，通知CGF2取消该话单包，采用的消息是Data Record Transfer Request，Packet TransferCommand参数是Cancel Data Record Packet。其中，SequenceNumbers of the ReleasedPackets参数中包含了流水号N。
步骤613，CGF2从缓存中删除该话单包。
步骤614，CGF2向GSN发Data Record Transfer Response消息，其中，RequestsResponded参数中包含了流水号N，Cause参数置为Request Accepted。
目前的传输方法存在以下问题：
CGF1中断一段时间，GSN向CGF2发送可疑重包，设可疑重包的流水号是M～N，因CGF1中断，可疑重包暂时不会处理，目前一般网速都很高，假设话务量达到10000条/s，每个数据包只存放一条话单，那么不到7秒钟流水号就会再次达到M(因为最大的流水号个数是65535)，这时若要继续发话单包，只能跳过M～N个流水号，即新的流水号到达M-1后，下一个话单包的流水号不是M，而是N+1，否则CGF回复M～N的包后，GSN无法判断回复的是可疑重复包的还是正常包的流水号。虽然跳过M～N的流水号能够解决上述问题，但是会造成可用流水号减少的情况，假设Echo Request是3秒一次，连续3次收不到Echo Response才认为链路中断，那么在9秒内，GSN尚且不知和CGF1链路中断，这样会连续发送65535个话单包给CGF1，而CGF1全部无法回应，这样可疑重包就将所有的流水号资源耗尽，从而导致GSN和CGF2无法继续正常通讯。需要说明的是，即使GSN和CGF1中断后导致GSN向CGF2发送的可疑重包个数没有达到65535个，后续若GSN和CGF3或其他CGF中断后，导致GSN和CGF2的可疑重包累加，最终还是会导致GSN和CGF2之间的流水号资源耗尽的情况。上述过程见图7，步骤说明如下：
步骤701，GSN向CGF1连续发送多个包，流水号从X到Y；
步骤702，CGF1实际已经中断；
步骤703，CGF1没有给GSN任何回应；
步骤704，GSN发现和CGF1链路中断，重定向到CGF2；
步骤705，GSN将流水号是X～Y的可疑重包发送给CGF2，对应CGF2的流水号是M～N；
步骤706，GSN不断发送新话单到CGF2，导致新话单包流水号重新回到M-1；
步骤707，若要再发送下一个话单包，流水号必须跳过M～N，也即下一个话单包的流水号是N+1。
另外现有技术中还存在一种情况，协议允许CGF手工释放/删除可疑重包，但是CGF释放/删除可疑重包后，GSN并不知道，GSN还必须维护这些已经被CGF手工释放/删除的可疑重包、包括流水号，这会造成GSN维护的可疑重包越来越多，当GSN维护的可疑重包个数接近65535后，将会导致通讯无法继续，给程序的稳定性带来极大的隐患。
可以看出，上述可疑重包大量占用流水号资源的情况在话务量较小的情况下是很难出现的，所以如果通过限制单位时间内发送话单包的数量也可以解决这个问题，但这样也会限制正常情况下数据的传输速度，浪费大量的带宽。如果仅仅是扩大流水号的范围，比如将其由WORD扩展到DWROD，首先带来的是协议兼容性问题，其次也同样解决不了可疑重包和正常包的流水号重复问题(因为如果10000条每秒的速度，CGF1中断120小时后，DWORD的流水号同样会重复)。
如今硬件发展速度飞快，运营商对话单传输的速度要求也越来越高，话单处理能力超过1万条每秒的要求已经变得很正常，因此上述问题要解决，就必须找到一种既不限制网络传输速度，又能解决可疑重包占用流水号资源问题的方法，然而现有技术还无法提供满足上述需求的解决方法。
发明内容
有鉴于此，本发明的主要目的在于提供一种话单包的处理方法和系统，以实现在不限制网络传输速度的情况下，解决可疑重包占用流水号资源问题。
为达到上述目的，本发明的技术方案是这样实现的：
本发明提供了一种话单包的处理方法，该方法包括：
通用分组无线服务支持节点GSN向计费网关功能CGF发送话单包，所述话单包为正常包或可疑重包，且用于发送话单包的消息的消息头中包含流水号、消息体中包含组包时间；
所述CGF向GSN发送收到所述话单包的回应消息，且所述回应消息中的包传输响应命令Packet Transfer Response Command信息元用于标识所述回应消息是针对正常包或针对可疑重包。
该方法进一步包括：
所述GSN中维护流水号对应的话单包的组包时间列表，所述组包时间列表中的各组包时间按照时间先后顺序排序；
所述GSN在组成话单包之前，判断即将使用的流水号对应的组包时间列表中组包时间的个数是否大于预设的阈值，如果大于，则停止组包；否则，继续组包，并将组成的话单包发送给所述CGF，且所述发送话单包的消息的消息头中包含所述即将使用的流水号、消息体中包含所述话单包的组包时间。
该方法进一步包括：
所述CGF在收到GSN发送话单包的消息后，将所述话单包的组包时间与所述CGF本地维护的与所述话单包相同的流水号所对应的组包时间列表中的组包时间进行比较，如果CGF本地维护的所述组包时间列表中存在与所述话单包相同的组包时间，则丢弃所述话单包；否则，接收所述话单包。
在接收所述话单包后，该方法进一步包括：
CGF判断本地维护的所述组包时间列表中组包时间的个数是否大于或等于预设的阈值，如果是，则删除所述组包时间列表中最早的组包时间，并将新接收的组包时间追加到所述组包时间列表中；如果否，则直接将新接收的组包时间追加到所述组包时间列表中。
该方法进一步包括：
所述CGF在网管控制下删除或释放自身缓存的可疑重包，并向所述GSN发送Deletepossibly duplicated Packet Sequence Number Request消息，消息体中包含删除的可疑重包的流水号和组包时间；
所述GSN收到所述Delete possibly duplicated Packet SequenceNumberRequest消息后，查找本地是否存在对应可疑重包的流水号和组包时间，如果存在，则删除对应可疑重包的流水号下的所述组包时间，并向所述CGF回应删除可疑重包流水号响应Delete possibly duplicated Packet Sequence NumberResponse消息。
在GSN删除对应可疑重包的流水号下的所述组包时间后，该方法进一步包括：
如果所述可疑重包发向过其他CGF，所述GSN通知所述其他CGF删除对应可疑重包的流水号下的所述组包时间；
所述其他CGF删除对应可疑重包的流水号下的所述组包时间后，回应所述GSN，且回应消息中的Packet Transfer Response Command信息元用于标识回应的是可疑重包的流水号。
本发明还提供了一种话单包的处理系统，该系统包括：通用分组无线服务支持节点GSN和计费网关功能CGF，其中，
所述GSN，用于向CGF发送话单包，所述话单包为正常包或可疑重包，且用于发送话单包的消息的消息头中包含流水号、消息体中包含组包时间；
所述CGF，用于接收GSN发送的话单包，并向GSN发送收到所述话单包的回应消息，且所述回应消息中的包传输响应命令Packet Transfer ResponseCommand信息元用于标识所述回应消息是针对正常包或针对可疑重包。
所述GSN进一步用于，维护流水号对应的话单包的组包时间列表，所述组包时间列表中的各组包时间按照时间先后顺序排序；
在组成话单包之前，判断即将使用的流水号对应的组包时间列表中组包时间的个数是否大于预设的阈值，如果大于，则停止组包；否则，继续组包，并将组成的话单包发送给所述CGF，且所述发送话单包的消息的消息头中包含所述即将使用的流水号、消息体中包含所述话单包的组包时间。
所述CGF进一步用于，在收到GSN发送话单包的消息后，将所述话单包的组包时间与所述CGF本地维护的与所述话单包相同的流水号所对应的组包时间列表中的组包时间进行比较，如果CGF本地维护的所述组包时间列表中存在与所述话单包相同的组包时间，则丢弃所述话单包；否则，接收所述话单包。
所述CGF进一步用于，在接收所述话单包后，判断本地维护的所述组包时间列表中组包时间的个数是否大于或等于预设的阈值，如果是，则删除所述组包时间列表中最早的组包时间，并将新接收的组包时间追加到所述组包时间列表中；如果否，则直接将新接收的组包时间追加到所述组包时间列表中。
所述CGF进一步用于，在网管控制下删除或释放自身缓存的可疑重包，并向所述GSN发送Delete possibly duplicated Packet Sequence Number Request消息，消息中包含删除的可疑重包的流水号和组包时间；
相应的，所述GSN收到所述Delete possibly duplicated PacketSequenceNumber Request消息后，查找本地是否存在对应可疑重包的流水号和组包时间，如果存在，则删除对应可疑重包的流水号下的所述组包时间，并向所述CGF回应删除可疑重包流水号响应Delete possibly duplicated Packet Sequence NumberResponse消息。
所述GSN进一步用于，在删除对应可疑重包的流水号下的所述组包时间后，如果所述可疑重包发向过其他CGF，所述GSN通知所述其他CGF删除对应可疑重包的流水号下的所述组包时间；
相应的，所述其他CGF删除对应可疑重包的流水号下的所述组包时间后，回应所述GSN，且回应消息中的Packet Transfer Response Command信息元用于标识回应的是可疑重包的流水号。
本发明还提供了一种话单包的处理方法，该方法包括：
计费网关功能CGF在网管控制下删除或释放自身缓存的可疑重包，所述CGF向通用分组无线服务支持节点GSN发送删除可疑重包流水号请求Deletepossibly duplicatedPacket Sequence Number Request消息，消息体中包含删除的可疑重包的流水号；
GSN收到所述Delete possibly duplicated Packet Sequence Number Request消息后，查找本地是否存在对应可疑重包的流水号，如果存在，则删除对应可疑重包的流水号，并向所述CGF回应删除可疑重包流水号响应Delete possiblyduplicated PacketSequence Number Response消息。
在GSN删除对应可疑重包的流水号后，该方法进一步包括：
如果所述可疑重包发向过其他CGF，所述GSN通知所述其他CGF删除对应可疑重包的流水号；
所述其他CGF删除对应可疑重包的流水号后，回应所述GSN。
本发明还提供了一种话单包的处理系统，该系统包括：通用分组无线服务支持节点GSN和计费网关功能CGF，其中，
所述CGF，用于在网管控制下删除或释放自身缓存的可疑重包，并向所述GSN发送删除可疑重包流水号请求Delete possibly duplicated Packet SequenceNumberRequest消息，消息体中包含删除的可疑重包的流水号；
所述GSN，用于收到所述Delete possibly duplicated Packet SequenceNumberRequest消息后，查找本地是否存在对应可疑重包的流水号，如果存在，则删除对应可疑重包的流水号，并向所述CGF回应删除可疑重包流水号响应Deletepossiblyduplicated Packet Sequence Number Response消息。
所述GSN进一步用于，在删除对应可疑重包的流水号后，如果所述可疑重包发向过其他CGF，所述GSN通知所述其他CGF删除对应可疑重包的流水号；
相应的，所述其他CGF删除对应可疑重包的流水号后，回应所述GSN。
本发明所提供的一种话单包的处理方法和系统，通过话单包回应消息中的PacketTransfer Response Command信息元来区分回应消息是针对正常包还是可疑重包，这样就能够实现正常包和可疑重包的流水号分别维护，可以使话单包传输流程更加清晰，更重要的是，由于正常包和可疑重包的流水号分别维护，因此可疑重包的流水号的长期占用不会影响正常话单包的传输。
基于流水号+组包时间的话单包传输，能够更加精确的判断哪些话单包被成功的传输，最终实现在同一秒内GSN可以向CGF发送最多65536个话单包，从而大大利用了网络传输性能。
当在CGF侧执行删除/释放可疑重包时，增加了从CGF向GSN发送的删除可疑重包流水号的消息、以及从GSN向CGF发送的删除可以重包流水号响应的消息，用于清除在GSN侧遗留的可疑重包流水号对应的组包时间；这样不仅可以在GSN侧有效的释放可疑重包流水号对应的组包时间资源，还可以防止该GSN向其他CGF发送释放可疑重包的命令，导致其他CGF将同样的可疑重包释放给计费中心。
附图说明
图1为现有3GPP网络中CTF、CDF和CGF之间的关系示意图；
图2为现有GTP’协议的承载情况示意图；
图3为现有GTP’消息头的结构示意图；
图4为现有技术中正常情况下话单包传输过程的示意图；
图5为现有技术中话单包未正确接收前GSN-CGF1之间的连接中断的传输过程的示意图；
图6为现有技术中话单包已经正确接收后GSN-CGF1之间的连接中断的传输过程的示意图；
图7为现有技术中发送正常话单包的流水号跳过可疑重包流水号的传输过程的示意图；
图8为本发明实施例的一种话单包的处理方法的流程图；
图9为本发明实施例中正常情况下带组包时间的话单包传输过程的示意图；
图10为本发明实施例中话单包未正确接收前GSN-CGF1之间的连接中断的传输过程的示意图；
图11为本发明实施例中话单包已经正确接收后GSN-CGF1之间链路中断的传输过程的示意图；
图12为本发明实施例中针对手工删除或者释放可疑重包(不含组包时间)的处理过程的示意图；
图13为本发明实施例中针对手工删除或者释放可疑重包(含组包时间)的处理过程的示意图。
具体实施方式
下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。
本发明实施例所提供的一种话单包的处理方法主要包括：GSN向CGF发送话单包，该话单包为正常包或可疑重包，且用于发送话单包的消息的消息头中包含流水号、消息体中包含组包时间；CGF向GSN发送收到该话单包的回应消息，且该回应消息中的PacketTransfer Response Command信息元用于标识该回应消息是针对正常包或针对可疑重包。
通过Packet Transfer Response Command信息元来区分回应消息是针对正常包还是可疑重包，这样就能够实现正常包和可疑重包的流水号分别维护，可以使话单包传输流程更加清晰，更重要的是，由于正常包和可疑重包的流水号分别维护，因此可疑重包的流水号的长期占用不会影响正常话单包的传输。
下面介绍实现正常话单包和可疑话单包的流水号分别独立维护的具体实现。
在CGF向GSN发送的回应话单包的消息(Data Record Transfer Response)中增加了一个IE：Packet Transfer Response Command(包传输响应命令)，该IE的结构如下表7所示，
Octets Data 备注
1 Type＝125 表示是IE-Packet Transfer Response Command
2 Value＝1...2 Packet Transfer Response Command
表7
上表中，Packet Transfer Response Command＝1表示Response for DataRecordPacket(正常话单包的响应)，Packet Transfer Response Command＝2表示Responsefor possibly duplicated Data Record Packet(可疑话单包的响应)。IE-PacketTransfer Response Command用来区分回应的话单包是可疑包还是正常包，这样就能够实现正常包和可疑包的流水号分别维护。
增加IE-Packet Transfer Response Command后的新的Data RecordTransferResponse消息结构如下表8所示：
Information Element Presence requirement
Cause Mandatory
Packet Transfer Response Command Conditional
Requests Responded Conditional
Sequence Numbers of Packets With Time Conditional
Private Extension Optional
表8
如图8所示，话单包的处理流程包括：
步骤801，GSN向CGF1(主用CGF)发送多个话单包消息，发送的消息是：Data RecordTransfer Request。
比如：Packet Transfer Command＝5表示Send Data Record Packet With Time，发送给CGF1的流水号是X～Y。
步骤802，CGF1实际已经中断。
步骤803，GSN多次尝试重发流水号是X～Y的话单包给CGF1，但CGF1没有给GSN任何回应。
步骤804，GSN检测到和CGF1链路中断，话单包发送方向重定向到CGF2(备用CGF)。
步骤805，GSN将未收到CGF1回应的可疑重包发送给CGF2，发送的消息是：DataRecord Transfer Request。
比如：Packet Transfer Command＝6表示Send possibly duplicated DataRecordPacket With Time，发送给CGF2的流水号是M～N(因为此时PacketTransferCommand＝6，所以流水号M～N可以和正常话单包流水号相互独立)。
步骤806，CGF2发送已经接收到可疑重包的回应消息，发送的消息是：Data RecordTransfer Response。
比如：Packet Transfer Response Command＝2，表示Response forpossiblyduplicated Data Record Packet，这样GSN就可以判断该回应消息是针对可疑重包的，从而实现和正常包的流水号完全独立。因为，针对正常包的回应消息中PacketTransfer Response Command＝1，针对可疑重包的回应消息中PacketTransfer ResponseCommand＝2，通过Packet Transfer Response Command即可以区分针对正常包和可疑重包的回应消息，所以正常包的流水号和可疑重包的流水号就可以完全独立的使用。
步骤807，GSN连续发送新包给CGF2，发送的消息是：Data RecordTransferRequest，如Packet Transfer Command＝5，流水号和可疑重包独立；CGF2回应消息是：Data Record Transfer Response，如Packet Transfer ResponseCommand＝1，回复流水号和可疑重包独立。
步骤808，由于GSN发送给CGF2的正常包的流水号和可疑重包的流水号相互独立(因为GSN发送给CGF2的针对正常包的Packet Transfer Command＝5，针对可疑重包的Packet Transfer Command＝6，通过Packet Transfer Command即可以区分GSN发送给CGF2的是正常包、还是可疑重包，所以正常包的流水号和可疑重包的流水号就可以完全独立的使用)，所以正常包消息的流水号完全可以占用M～N。
在上述方法实施例的基础上，为充分发挥网络传输性能，本发明的实施例还在GSN向CGF发送话单包消息(Data Record Transfer Request)时，扩充了IE：Packet TransferCommand的定义，用于指示发送的数据包中含有组包时间，扩充后的Data Record TransferRequest消息结构如下表9所示：
表9
并且在该消息中增加了IE：Data Record Packet With Time，其结构如下表10所示：
表10
组包时间是DWORD TIME，精确到秒，是将多个话单组成话单包的时间，同一个话单包最多只能组包一次，不管该包重发多少次，发向哪个CGF，这个组包时间保持不变；另外为了保证数据包的唯一性，同一秒内数据包的流水号不可以重复，也就是说一秒钟内在收到CGF的回应消息之前，最多可以连续发送65536个话单包。
相应的，在CGF向GSN发送话单包回应消息(Data Record TransferResponse)时，增加了IE：Packet Transfer Response Command，如前述表7所示；IE-Packet TransferResponse Command除了用来区分回应的话单包是可疑包还是正常包，还可以表示该回应消息中包含了组包时间。另外还增加了IE：Sequence Numbers of Packets With Time，如下表11所示：
表11
通过上述对消息的扩充，CGF可以通过“流水号+组包时间”更加精确的判断话单包是否已被成功接收；GSN也可以在同一秒内最多发送65536个话单包给CGF，大大利用了高速的网络性能。具体的流程步骤下面分别介绍：
表12示出了CGF和GSN维护数据包流水号的数据结构，在该结构中，每个流水号都对应着收到的话单包组包时间列表，列表中的组包时间应该按时间先后顺序排序，另外，列表中的组包时间个数应该有一定的限制(通过预设阈值来限制)，比如个数限制为5，这就说明GSN和CGF对同一个流水号，维护了至少5秒的组包时间。
流水号 组包时间列表
0 dwTime0a，dwTime0b......
1 dwTime1a，dwTime1b......
2 dwTime2a，dwTime2b......
...... ......
65535 dwTime65535a，dwTime65535b......
表12
在GSN组包之前，先判断即将要使用到的流水号对应的组包时间列表中组包时间的个数是否小于5，如果小于5则可以组包，否则说明该流水号对应的数据包至少超过5秒没有收到CGF的回应，网络链路必定存在异常，所以不可以再继续组包。
当CGF收到GSN发送的数据包消息Data Record Transfer Request后，将数据包的组包时间和本地相同的流水号所对应的组包时间列表中的组包时间进行比较，如果出现相等的情况，则说明该包在之前已经接收过，需要丢弃；否则说明该包是全新的包，需要接收。接收后还需要判断组包时间列表个数是否大于或等于5，如果大于或等于5，则需要删除最早的组包时间，然后将新接收的组包时间追加到组包时间列表中；否则直接将新接收的组包时间追加到组包时间列表中。
当GSN收到CGF的话单包回应消息(Data Record Transfer Response)时，需要根据回应消息中话单包的流水号和组包时间，将本地维护的组包时间释放，从而可以让后续新的组包工作插入新的组包时间。
图9示出了正常情况下带组包时间的话单包传输过程，包括以下步骤：
步骤901，GSN发送话单包到CGF，发送的相应消息为Data RecordTransferRequest，其中Packet Transfer Command＝5，表示Send Data Record PacketWithTime，消息头中的流水号为N，组包时间为Time6。
步骤902，CGF收到并处理消息，并成功存储包中的话单到本地。
步骤903，CGF在SeqNo＝N的组包时间列表中删除Time1并且追加Time6。
步骤904，CGF发送响应消息到GSN，消息内容为Data Record TransferResponse，其中Packet Transfer Response Command＝1表示回应的是正常包的流水号，SequenceNumbers of Packets With Time参数中包含了流水号N和组包时间Time6，Cause参数置为Request Accepted。
步骤905，GSN在SeqNo＝N的组包时间列表中删除Time6，释放Time List个数。如果不释放，Time List个数超过5后，流水号N将不允许再次组包。
如果GSN接收响应时失败，会在额定时间内和达到设定次数前重新发送话单包的请求。
图10示出了话单包未正确接收前GSN-CGF1之间的连接中断的传输过程，不仅实现了话单包带组包时间的高速传输，而且实现了正常话单包和可疑重包流水号相互独立。图10所示的流程主要包括以下步骤：
步骤1001，GSN向CGF1(主用CGF)发Data Record Transfer Request消息，其中Packet Transfer Command＝5表示Send Data Record Packet With Time，消息头中的流水号为M，组包时间是dwTime。
步骤1002，因为GSN与CGF1之间失去联系，CGF1没有收到话单包。
步骤1003，GSN无法收到CGF1的响应。
步骤1004，GSN检测与CGF2(备用CGF)之间的链路(用Echo Request)，如果正常则GSN将与送往CGF1相同的话单包送往CGF2，使用Data RecordTransfer Request消息，Packet Transfer Command＝6表示Send possible duplicatedData Record Packet WithTime，消息头中的流水号为N，组包时间是dwTime。
步骤1005，CGF2收到并处理话单包，因为该话单包被标识为possibleduplicated，所以CGF2只缓存该话单包，并不立刻送往BS。
步骤1006，CGF2发送正确接收确认信息给GSN，采用Data RecordTransferResponse消息，其中Packet Transfer Response Command＝2表示回应的是可疑重包的流水号，Sequence Numbers of Packets With Time参数中包含了流水号N和组包时间dwTime，Cause参数置为Request Accepted。
步骤1007，GSN可以将成功发送的话单包(但可能重复)删除，但是仍然保留该话单包发向CGF1和CGF2的流水号(即M和N)和组包时间dwTime。
步骤1008，CGF1恢复以后，向GSN送Node Alive Request消息，GSN获知可以与CGF1进行通信。
步骤1009，GSN采用Node Alive Response消息确认。
步骤1010，对于前面未得到确认的Data Record Transfer Request消息，即Packet Transfer Command＝5表示Send Data Record Packet With Time。GSN向CGF1发送空的测试话单包，空话单包仅仅是Data Record Packet With Time参数中不包含话单数据，其它都一样(消息头中的流水号还是M，组包时间还是dwTime)。
步骤1011，CGF1以Data Record Transfer Response消息响应，其中PacketTransfer Response Command＝1表示回应的是正常话单包的流水号，SequenceNumbers of Packets With Time参数中包含了流水号M和组包时间dwTime，Cause参数置为Request Accepted。因为在这之前CGF1已经与GSN失去联系，CGF1并未收到过该话单包，所以对于测试话单包它认为是新的可以接受。
步骤1012，GSN收到CGF1的回应消息后，获知CGF1并未处理测试话单包，通知CGF2可以将该话单包送给BS，采用的消息是Data Record TransferRequest，Packet TransferCommand＝8表示Release Data Record Packet With Time。其中Sequence Numbers ofPackets With Time参数中包含了流水号N和组包时间dwTime。
步骤1013，CGF2可以将话单包传向BS。
步骤1014，CGF2向GSN发Data Record Transfer Response消息，其中PacketTransfer Response Command＝2表示回应的是可疑重包包的流水号，SequenceNumbers of Packets With Time参数中包含了流水号N和组包时间dwTime，Cause参数置为Request Accepted。
图11示出了话单包已经正确接收后GSN-CGF1之间链路中断的传输过程，不仅实现了话单包带组包时间的高速传输，而且实现了正常话单包和可疑重包流水号相互独立。图11所示的流程主要包括以下步骤：
步骤1101，GSN向CGF1(主用CGF)发Data Record Transfer Request消息，其中Packet Transfer Command＝5表示Send Data Record Packet With Time，消息头中的流水号为M，组包时间是dwTime。
步骤1102，CGF1收到话单包后将包中话单安全保存。
步骤1103，GSN与CGF1之间通信中断，GSN无法收到CGF1的回应。
步骤1104，GSN检测与CGF2(备用CGF)之间的链路(用Echo Request)，如果正常则GSN将与送往CGF1相同的CDR送往CGF2，使用Data RecordTransfer Request消息，其中Packet Transfer Command＝6表示Send possibleduplicated Data Record Packet WithTime，消息头中的流水号为N，组包时间是dwTime。
步骤1105，CGF2接收并处理该话单包，因为该话单包被标识为possibleduplicated，所以CGF2只缓存该话单包，并不立刻送往BS。
步骤1106，CGF2发送正确接收确认信息给GSN，采用Data RecordTransferResponse消息，其中Packet Transfer Response Command＝2表示回应的是可疑重包的流水号，Sequence Numbers of Packets With Time参数中包含了流水号N和组包时间dwTime，Cause参数置为Request Accepted。
步骤1107，GSN可以将成功发送的话单包(但可能重复)删除，但是仍然保留该话单包发向CGF1和CGF2的流水号(即M和N)和组包时间dwTime。
步骤1108，CGF1恢复以后，向GSN送Node Alive Request消息，GSN获知可以与CGF1进行通信。
步骤1109，GSN采用Node Alive Response消息确认。
步骤1110，对于前面(即步骤1101中)未得到确认的Data RecordTransferRequest消息，即Packet Transfer Command＝5表示Send Data Record PacketWithTime。GSN向CGF1发送空的测试话单包，空话单包仅仅是Data Record PacketWithTime参数中不包含话单数据，其它都一样(消息头中的流水号还是M，组包时间还是dwTime)。
步骤1111，CGF1以Data Record Transfer Response消息响应，其中PacketTransfer Response Command＝1表示回应的是正常话单包的流水号，SequenceNumbers of Packets With Time参数中包含了流水号M和组包时间dwTime，Cause参数置为Request related to possibly duplicated packets already fulfilled。因为在CGF1与GSN失去联系之前，CGF1已经保存该话单包，所以对于测试话单包它认为是重复的。
步骤1112，GSN收到CGF1的回应消息后，获知CGF1已经接收并保存该话单包，通知CGF2取消该话单包，采用的消息是Data Record Transfer Request，Packet TransferCommand＝7表示Cancel Data Record Packet With Time。其中Sequence Numbers ofPackets With Time参数中包含了流水号N和组包时间dwTime。
步骤1113，CGF2从缓存中删除该话单包。
步骤1114，CGF2向GSN发送Data Record Transfer Response消息，其中PacketTransfer Response Command＝2表示回应的是可疑重包的流水号，Sequence Numbers ofPackets With Time参数中包含了流水号N和组包时间dwTime，Cause参数置为RequestAccepted。
另外，在CGF侧手工删除或者释放可疑重包后，需要同步删除GSN对应可疑重包的相关资源。
图12示出了手工删除或者释放可疑重包(不含组包时间)的过程，主要包括以下步骤：
步骤1201，用户手工释放/删除CGF中的可疑重包，流水号＝X。
步骤1202，CGF释放/删除本地对应的可疑重包，流水号＝X。
步骤1203，CGF向GSN发送Delete possibly duplicated Packet SequenceNumberRequest消息，消息流水号为N，消息体Sequence Numbers of Packets中含可疑重包流水号X。
其中，Delete possibly duplicated Packet Sequence Number Request消息的结构如下表13所示：
Information Element Presence requirement
Sequence Numbers of Packets Conditional
Sequence Numbers of Packets With Time Conditional
Private Extension Optional
表13
Delete possibly duplicated Packet Sequence Number Request消息体中包含IE-Sequence Numbers of Packets，IE-Sequence Numbers of Packets的结构如下表14所示：
表14
步骤1204，GSN收到消息后，查找本地是否存在对应的可疑重包流水号X，如果存在，则删除该可疑重包流水号X；如果不存在，则不作处理。
步骤1205，GSN向CGF发送Delete possibly duplicated Packet SequenceNumberResponse消息，消息中的IE-Requests Responded中的流水号为N。
其中，Delete possibly duplicated Packet Sequence Number Response消息的结构如下表15所示，IE-Requests Responded的结构如上述表6所示：
Information Element Presence requirement
Requests Responded Mandatory
Private Extension Optional
表15
步骤1206，如果该可疑重包曾经发向其他CGF，GSN还需要向其他CGF发送DataRecord Transfer Request消息，其中Packet Transfer Command＝3(不含组包时间)表示删除可疑重包；因为和其他CGF对应的流水号也需要删除，防止后续该可疑重包会在其他CGF中释放或删除。
步骤1207，其他CGF向GSN发送Data Record Transfer Response消息。
图13示出了手工删除或者释放可疑重包(含组包时间)的过程，主要包括以下步骤：
步骤1301，用户手工释放/删除CGF中的可疑重包，流水号＝X，组包时间＝TimeX。
步骤1302，CGF释放/删除本地对应的可疑重包，流水号＝X，组包时间＝TimeX。
步骤1303，CGF向GSN发送Delete possibly duplicated Packet SequenceNumberRequest消息，消息流水号为N；消息体Sequence Numbers of PacketsWith Time中含可疑重包流水号X，组包时间＝TimeX。
Delete possibly duplicated Packet Sequence Number Request消息的结构如上表13所示；Delete possibly duplicated Packet Sequence Number Request消息体中包含IE-Sequence Numbers of Packets With Time，其中，IE-Sequence NumbersofPackets With Time的结构如上表11所示。
步骤1304，GSN收到消息后，查找本地是否存在对应的可疑重包流水号X且组包时间＝TimeX，如果存在，则删除该流水号X下的组包时间TimeX。
步骤1305，GSN向CGF发送Delete possibly duplicated Packet SequenceNumberResponse消息，消息中的IE-Requests Responded中的流水号为N。
其中，Delete possibly duplicated Packet Sequence Number Response消息的结构如上表15所示。
步骤1306，如果该可疑重包曾经发向其他CGF，GSN还需要向其他CGF发送DataRecord Transfer Request消息，其中Packet Transfer Command＝7(含组包时间TimeX)表示删除可疑重包；因为和其他CGF对应的流水号的组包时间也需要删除，防止后续该可疑重包会在其他CGF中释放或删除。
步骤1307，其他CGF向GSN发送Data Record Transfer Response消息，其中PacketTransfer Response Command＝2表示回应的是可疑重包的流水号。
综上所述，实现本发明实施例的上述操作流程，需要对GTP’协议做如下扩展：
1、在Data Record Transfer Response消息体中增加必选IE-PacketTransferResponse Command(用于区分回复的流水号是针对正常包，还是可疑重包)，从而实现正常包和可疑重包的流水号分别维护；新的Data Record TransferResponse消息结构参见上述表8，其中，IE-Packet Transfer Response Command的结构参见上述表7；IE-Sequence Numbers of Packets With Time的结构参见上述表11；
2、增加消息Delete possibly duplicated Packet Sequence Number Request和Delete possibly duplicated Packet Sequence Number Response，消息内容包含IE-Sequence Numbers of Packets或IE-Sequence Numbers of Packets With Time。用于CGF手工删除/释放可疑重包后，通知GSN删除发向这个CGF的可疑重包流水号对应的组包时间；Delete possibly duplicated Packet Sequence NumberRequest消息的结构参见上述表13，Delete possibly duplicated Packet SequenceNumber Response消息的结构参见上述表15，其中IE-Sequence Numbers ofPackets的结构参见上述表14，IE-SequenceNumbers of Packets With Time的结构参见上述表11，IE-Requests Responded的结构参见上述表6；
需要说明的是，增加不带组包时间的IE-Sequence Numbers of Packets是为了兼容不支持组包时间的GTP’协议；
3、在Data Record Transfer Request消息体的IE-Packet Transfer Command中增加如下四个命令：
Send Data Record Packet With Time(如对应Packet Transfer Command取值为5)；
Send possibly duplicated Data Record Packet With Time(如对应PacketTransfer Command取值为6)；
Cancel Data Record Packet With Time(如对应Packet Transfer Command取值为7)；
Release Data Record Packet With Time(如对应Packet Transfer Command取值为8)。
新的Data Record Transfer Request消息的结构参见上述表9。
4、增加IE-Data Record Packet With Time，其结构与现有的IE-DataRecordPacket的结构相同，且在IE-Data Record Packet的结构基础上增加了DWORDTIME，表示组包时间。IE-Data Record Packet With Time的结构参见上述表10。
对应上述话单包的处理方法，本发明的实施例还提供了一种话单包的处理系统，包括：GSN和CGF。其中，GSN用于向CGF发送话单包，所述话单包为正常包或可疑重包，且用于发送话单包的消息的消息头中包含流水号、消息体中包含组包时间；CGF用于接收GSN发送的话单包，并向GSN发送收到所述话单包的回应消息，且所述回应消息中的PacketTransfer Response Command信息元用于标识所述回应消息是针对正常包或针对可疑重包。
较佳的，GSN可进一步用于，维护流水号对应的话单包的组包时间列表，所述组包时间列表中的各组包时间按照时间先后顺序排序；
在组成话单包之前，判断即将使用的流水号对应的组包时间列表中组包时间的个数是否大于预设的阈值，如果大于，则停止组包；否则，继续组包，并将组成的话单包发送给所述CGF，且所述发送话单包的消息的消息头中包含所述即将使用的流水号、消息体中包含所述话单包的组包时间。
较佳的，CGF可进一步用于，在收到GSN发送话单包的消息后，将所述话单包的组包时间与所述CGF本地维护的与所述话单包相同的流水号所对应的组包时间列表中的组包时间进行比较，如果CGF本地维护的所述组包时间列表中存在与所述话单包相同的组包时间，则丢弃所述话单包；否则，接收所述话单包。
较佳的，CGF还可进一步用于，在接收所述话单包后，判断本地维护的所述组包时间列表中组包时间的个数是否大于或等于预设的阈值，如果是，则删除所述组包时间列表中最早的组包时间，并将新接收的组包时间追加到所述组包时间列表中；如果否，则直接将新接收的组包时间追加到所述组包时间列表中。
较佳的，CGF还可进一步用于，在网管控制下删除或释放自身缓存的可疑重包，并向GSN发送Delete possibly duplicated Packet Sequence Number Request消息，消息中包含删除的可疑重包的流水号和组包时间；
相应的，GSN收到Delete possibly duplicated Packet SequenceNumberRequest消息后，查找本地是否存在对应可疑重包的流水号和组包时间，如果存在，则删除对应可疑重包的流水号下的所述组包时间，并向CGF回应Deletepossiblyduplicated Packet Sequence Number Response消息；如果不存在，则不作处理。
较佳的，GSN进一步用于，在删除对应可疑重包的流水号下的所述组包时间后，如果所述可疑重包发向过其他CGF，GSN通知所述其他CGF删除对应可疑重包的流水号下的所述组包时间；
相应的，所述其他CGF删除对应可疑重包的流水号下的所述组包时间后，回应所述GSN，且回应消息中的Packet Transfer Response Command信息元用于标识回应的是可疑重包的流水号。
另外，对应图12所示话单包的处理方法，本发明的实施例还提供了一种话单包的处理系统，包括：GSN和CGF，其中，
CGF，用于在网管控制下删除或释放自身缓存的可疑重包，并向GSN发送Deletepossibly duplicated Packet Sequence Number Request消息，消息体中包含删除的可疑重包的流水号；
GSN，用于收到Delete possibly duplicated Packet Sequence Number Request消息后，查找本地是否存在对应可疑重包的流水号，如果存在，则删除对应可疑重包的流水号，并向CGF回应Delete possibly duplicated Packet SequenceNumber Response消息；如果不存在，则不作处理。
较佳的，GSN进一步用于，在删除对应可疑重包的流水号后，如果所述可疑重包发向过其他CGF，所述GSN通知所述其他CGF删除对应可疑重包的流水号；
相应的，所述其他CGF删除对应可疑重包的流水号后，回应所述GSN。
以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (16)

1.一种话单包的处理方法，其特征在于，该方法包括：
通用分组无线服务支持节点GSN分别维护正常包的流水号和可疑重包的流水号，向计费网关功能CGF发送话单包，所述话单包为正常包或可疑重包，且用于发送话单包的消息的消息头中包含流水号、消息体中包含组包时间；
所述CGF向GSN发送收到所述话单包的回应消息，且所述回应消息中的包传输响应命令Packet Transfer Response Command信息元用于标识所述回应消息是针对正常包或针对可疑重包。
2.根据权利要求1所述话单包的处理方法，其特征在于，该方法进一步包括：
所述GSN中维护流水号对应的话单包的组包时间列表，所述组包时间列表中的各组包时间按照时间先后顺序排序；
所述GSN在组成话单包之前，判断即将使用的流水号对应的组包时间列表中组包时间的个数是否大于预设的阈值，如果大于，则停止组包；否则，继续组包，并将组成的话单包发送给所述CGF，且所述发送话单包的消息的消息头中包含所述即将使用的流水号、消息体中包含所述话单包的组包时间。
3.根据权利要求2所述话单包的处理方法，其特征在于，该方法进一步包括：
所述CGF在收到GSN发送话单包的消息后，将所述话单包的组包时间与所述CGF本地维护的与所述话单包相同的流水号所对应的组包时间列表中的组包时间进行比较，如果CGF本地维护的所述组包时间列表中存在与所述话单包相同的组包时间，则丢弃所述话单包；否则，接收所述话单包。
4.根据权利要求3所述话单包的处理方法，其特征在于，在接收所述话单包后，该方法进一步包括：
CGF判断本地维护的所述组包时间列表中组包时间的个数是否大于或等于预设的阈值，如果是，则删除所述组包时间列表中最早的组包时间，并将新接收的组包时间追加到所述组包时间列表中；如果否，则直接将新接收的组包时间追加到所述组包时间列表中。
5.根据权利要求1至4任一项所述话单包的处理方法，其特征在于，该方法进一步包括：
所述CGF在网管控制下删除或释放自身缓存的可疑重包，并向所述GSN发送Deletepossibly duplicated Packet Sequence Number Request消息，消息体中包含删除的可疑重包的流水号和组包时间；
所述GSN收到所述Delete possibly duplicated Packet Sequence Number Request消息后，查找本地是否存在对应可疑重包的流水号和组包时间，如果存在，则删除对应可疑重包的流水号下的所述组包时间，并向所述CGF回应删除可疑重包流水号响应Deletepossibly duplicated Packet Sequence Number Response消息。
6.根据权利要求5所述话单包的处理方法，其特征在于，在GSN删除对应可疑重包的流水号下的所述组包时间后，该方法进一步包括：
如果所述可疑重包发向过其他CGF，所述GSN通知所述其他CGF删除对应可疑重包的流水号下的所述组包时间；
所述其他CGF删除对应可疑重包的流水号下的所述组包时间后，回应所述GSN，且回应消息中的Packet Transfer Response Command信息元用于标识回应的是可疑重包的流水号。
7.一种话单包的处理系统，其特征在于，该系统包括：通用分组无线服务支持节点GSN和计费网关功能CGF，其中，
所述GSN，用于分别维护正常包的流水号和可疑重包的流水号，向CGF发送话单包，所述话单包为正常包或可疑重包，且用于发送话单包的消息的消息头中包含流水号、消息体中包含组包时间；
所述CGF，用于接收GSN发送的话单包，并向GSN发送收到所述话单包的回应消息，且所述回应消息中的包传输响应命令Packet Transfer Response Command信息元用于标识所述回应消息是针对正常包或针对可疑重包。
8.根据权利要求7所述话单包的处理系统，其特征在于，所述GSN进一步用于，维护流水号对应的话单包的组包时间列表，所述组包时间列表中的各组包时间按照时间先后顺序排序；
在组成话单包之前，判断即将使用的流水号对应的组包时间列表中组包时间的个数是否大于预设的阈值，如果大于，则停止组包；否则，继续组包，并将组成的话单包发送给所述CGF，且所述发送话单包的消息的消息头中包含所述即将使用的流水号、消息体中包含所述话单包的组包时间。
9.根据权利要求8所述话单包的处理系统，其特征在于，所述CGF进一步用于，在收到GSN发送话单包的消息后，将所述话单包的组包时间与所述CGF本地维护的与所述话单包相同的流水号所对应的组包时间列表中的组包时间进行比较，如果CGF本地维护的所述组包时间列表中存在与所述话单包相同的组包时间，则丢弃所述话单包；否则，接收所述话单包。
10.根据权利要求9所述话单包的处理系统，其特征在于，所述CGF进一步用于，在接收所述话单包后，判断本地维护的所述组包时间列表中组包时间的个数是否大于或等于预设的阈值，如果是，则删除所述组包时间列表中最早的组包时间，并将新接收的组包时间追加到所述组包时间列表中；如果否，则直接将新接收的组包时间追加到所述组包时间列表中。
11.根据权利要求7至10任一项所述话单包的处理系统，其特征在于，所述CGF进一步用于，在网管控制下删除或释放自身缓存的可疑重包，并向所述GSN发送Delete possiblyduplicated Packet Sequence Number Request消息，消息中包含删除的可疑重包的流水号和组包时间；
相应的，所述GSN收到所述Delete possibly duplicated Packet Sequence NumberRequest消息后，查找本地是否存在对应可疑重包的流水号和组包时间，如果存在，则删除对应可疑重包的流水号下的所述组包时间，并向所述CGF回应删除可疑重包流水号响应Delete possibly duplicated Packet Sequence Number Response消息。
12.根据权利要求11所述话单包的处理系统，其特征在于，所述GSN进一步用于，在删除对应可疑重包的流水号下的所述组包时间后，如果所述可疑重包发向过其他CGF，所述GSN通知所述其他CGF删除对应可疑重包的流水号下的所述组包时间；
相应的，所述其他CGF删除对应可疑重包的流水号下的所述组包时间后，回应所述GSN，且回应消息中的Packet Transfer Response Command信息元用于标识回应的是可疑重包的流水号。
13.一种话单包的处理方法，其特征在于，该方法包括：
计费网关功能CGF在网管控制下删除或释放自身缓存的可疑重包，所述CGF向通用分组无线服务支持节点GSN发送删除可疑重包流水号请求Delete possibly duplicatedPacket Sequence Number Request消息，消息体中包含删除的可疑重包的流水号；
GSN收到所述Delete possibly duplicated Packet Sequence Number Request消息后，查找本地是否存在对应可疑重包的流水号，如果存在，则删除对应可疑重包的流水号，并向所述CGF回应删除可疑重包流水号响应Delete possibly duplicated PacketSequence Number Response消息。
14.根据权利要求13所述话单包的处理方法，其特征在于，在GSN删除对应可疑重包的流水号后，该方法进一步包括：
如果所述可疑重包发向过其他CGF，所述GSN通知所述其他CGF删除对应可疑重包的流水号；
所述其他CGF删除对应可疑重包的流水号后，回应所述GSN。
15.一种话单包的处理系统，其特征在于，该系统包括：通用分组无线服务支持节点GSN和计费网关功能CGF，其中，
所述CGF，用于在网管控制下删除或释放自身缓存的可疑重包，并向所述GSN发送删除可疑重包流水号请求Delete possibly duplicated Packet Sequence Number Request消息，消息体中包含删除的可疑重包的流水号；
所述GSN，用于收到所述Delete possibly duplicated Packet Sequence NumberRequest消息后，查找本地是否存在对应可疑重包的流水号，如果存在，则删除对应可疑重包的流水号，并向所述CGF回应删除可疑重包流水号响应Delete possibly duplicatedPacket Sequence Number Response消息。
16.根据权利要求15所述话单包的处理系统，其特征在于，所述GSN进一步用于，在删除对应可疑重包的流水号后，如果所述可疑重包发向过其他CGF，所述GSN通知所述其他CGF删除对应可疑重包的流水号；
相应的，所述其他CGF删除对应可疑重包的流水号后，回应所述GSN。
CN201110357581.0A 2011-11-11 2011-11-11 一种话单包的处理方法和系统 Active CN103108295B (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN201110357581.0A CN103108295B (zh) 2011-11-11 2011-11-11 一种话单包的处理方法和系统
PCT/CN2012/084485 WO2013067975A1 (zh) 2011-11-11 2012-11-12 一种话单包的处理方法和系统
US14/356,857 US9332092B2 (en) 2011-11-11 2012-11-12 Method and system for processing data record packet
EP12847928.4A EP2779713B1 (en) 2011-11-11 2012-11-12 Method and system for data record packet processing
HK14110860A HK1197342A1 (zh) 2011-11-11 2014-10-29 種話單包的處理方法和系統

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201110357581.0A CN103108295B (zh) 2011-11-11 2011-11-11 一种话单包的处理方法和系统

Publications (2)

Publication Number Publication Date
CN103108295A CN103108295A (zh) 2013-05-15
CN103108295B true CN103108295B (zh) 2017-10-27

Family

ID=48288545

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201110357581.0A Active CN103108295B (zh) 2011-11-11 2011-11-11 一种话单包的处理方法和系统

Country Status (5)

Country Link
US (1) US9332092B2 (zh)
EP (1) EP2779713B1 (zh)
CN (1) CN103108295B (zh)
HK (1) HK1197342A1 (zh)
WO (1) WO2013067975A1 (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9560211B2 (en) * 2014-06-04 2017-01-31 Alcatel-Lucent Usa Inc. Error handling for CDR transport within an offline charging system
US9787852B2 (en) * 2014-06-04 2017-10-10 Alcatel-Lucent Usa Inc. Sequence number reuse for CDR transport using GTP'
CN109219006A (zh) * 2017-06-30 2019-01-15 中兴通讯股份有限公司 话单传输方法、相关设备和计算机可读存储介质
CN108289296A (zh) * 2017-06-30 2018-07-17 中兴通讯股份有限公司 话单输出方法、装置及存储介质
CN115714742A (zh) * 2018-05-11 2023-02-24 华为技术有限公司 一种报文发送的方法、网络节点和系统
EP3900299A4 (en) * 2019-02-05 2022-07-27 Casa Systems, Inc. METHOD AND DEVICE FOR RECOVERING NETWORK ASSOCIATION INFORMATION
CN110430024A (zh) * 2019-07-23 2019-11-08 视联动力信息技术股份有限公司 一种数据传输方法、装置、电子设备及存储介质
US20210337411A1 (en) * 2020-04-24 2021-10-28 Qualcomm Incorporated Techniques for cli measurement based on enhanced srs in a wireless communication system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000044123A1 (en) * 1999-01-19 2000-07-27 Nokia Networks Oy Controlled data network error recovery
CN101145893A (zh) * 2007-10-08 2008-03-19 华为技术有限公司 话单数据的数据帧接收方法、装置及计费网关
CN101778367A (zh) * 2009-12-29 2010-07-14 北京首信科技股份有限公司 一种计费网关重启恢复工作的方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE0004178D0 (sv) * 2000-11-14 2000-11-14 Ericsson Telefon Ab L M Network requested packet data protocol context activation
CN1885780B (zh) * 2005-06-24 2012-03-28 朗迅科技公司 集中式离线收费和在线收费的方法及系统
FI20061035A0 (fi) * 2006-11-23 2006-11-23 Nokia Corp Datatietueiden kaksinkertaisen laskutuksen sarjamuotoinen ehkäisy
US8270943B2 (en) * 2010-07-12 2012-09-18 Alcatel Lucent Method and apparatus for reliable transmission of charging detail records

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000044123A1 (en) * 1999-01-19 2000-07-27 Nokia Networks Oy Controlled data network error recovery
CN101145893A (zh) * 2007-10-08 2008-03-19 华为技术有限公司 话单数据的数据帧接收方法、装置及计费网关
CN101778367A (zh) * 2009-12-29 2010-07-14 北京首信科技股份有限公司 一种计费网关重启恢复工作的方法

Also Published As

Publication number Publication date
WO2013067975A1 (zh) 2013-05-16
EP2779713A4 (en) 2015-09-09
CN103108295A (zh) 2013-05-15
US9332092B2 (en) 2016-05-03
EP2779713B1 (en) 2018-02-14
US20140293879A1 (en) 2014-10-02
EP2779713A1 (en) 2014-09-17
HK1197342A1 (zh) 2015-01-09

Similar Documents

Publication Publication Date Title
CN103108295B (zh) 一种话单包的处理方法和系统
CN100370791C (zh) 数据传输的方法、装置及系统
US6954797B1 (en) Data Communication method, terminal equipment, interconnecting installation, data communication system and recording medium
CN104023006B (zh) 一种基于应用层中继的多径传输系统及方法
CN102035692B (zh) 一种链路质量检测方法及装置
EP2735189B1 (en) System and method for flow termination of a tcp session
US6765889B1 (en) Communication method and system
US20090245252A1 (en) Communication terminal and retransmission request method
CN106716951A (zh) 用于优化隧道流量的方法和装置
EP3720033B1 (en) Method for delivering data in order and network device
CN101141225B (zh) 一种移动通讯系统中数据丢失处理方法
CN105939297A (zh) 一种tcp报文重组方法和装置
CN102308531A (zh) 多接入系统
CN110213167A (zh) 一种传输控制协议在网络拥塞时的处理方法和装置
CN107172662A (zh) 一种通信方法及装置
CN101730062A (zh) 一种非相邻节点间异常处理方法
CN102104552A (zh) 基于明确拥塞通知机制的报文控制方法及设备
CN108924825A (zh) 一种面向SDWSNs的高能效信任管理与可信路由方法
CN111478865A (zh) 一种基于区间管理算法的tcp流重组技术
CN107770020A (zh) 一种基于星载FlexRay双通道总线的通信方法及装置
CN104885523B (zh) 故障处理方法、分组数据网络、移动管理实体及网络系统
CN101854735A (zh) 一种lte制式下rrc连接释放时rlc层以及pdcp层的数据处理方法
CN103118083B (zh) 一种业务报文转发的方法和装置
CN109428684A (zh) 一种数据传输方法、rlc实体及pdcp实体
CN104580171B (zh) Tcp协议的传输方法、装置和系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20210512

Address after: Changan town in Guangdong province Dongguan 523860 usha Beach Road No. 18

Patentee after: GUANGDONG OPPO MOBILE TELECOMMUNICATIONS Corp.,Ltd.

Address before: 518057 Ministry of justice, Zhongxing building, South Science and technology road, Nanshan District hi tech Industrial Park, Shenzhen, Guangdong

Patentee before: ZTE Corp.

TR01 Transfer of patent right