WLAN与2G／3G网络融合计费规范

QB-╳╳-╳╳╳-╳╳╳╳中国移动通信企业标准中国移动通信企业标准QB-QB-╳╳-╳╳╳-╳╳╳╳中国移动中国移动WLAN与2G/3G网络融合计费规范CCMCC2G/3GsystemandWLANinterworkingChargingSpecification版本号：版本号：0.3.0╳╳╳╳-╳╳╳╳-╳╳-╳╳实施╳╳╳╳-╳╳-╳╳发布中国移动通信集团公司发布中国移动通信集团公司发布PAGEII目 录前言 III1. 范围 12. 规范性引用文件 13. 术语、定义和缩略语 14. I-WLAN系统架构概述 15. WLAN计费总体架构 36. PDG节点计费要求 56.1. 总体要求 56.2. 计费数据收集原则 66.3. 内容计费 66.3.1. 基于APN的内容计费 66.3.2. 基于应用的内容计费 66.4. 实时计费（可选） 137. 计费话单产生机制 137.1. 概述 137.2. PDG话单（WLAN-CDR）产生机制 137.2.1. 计费信息追加触发条件 147.2.2. 话单关闭触发条件 148. 计费网关对话单的处理 148.1. 对PDG话单的处理 158.1.1. 话单合并 168.1.2. PDG与主CGF间的通信发生故障的情况 179. 计费采集接口和协议 189.1. PDG-CGF的协议栈 189.2. 承载协议 189.3. 计费节点的原则 189.4. GTP’计费通信协议 189.5. GTP’消息 199.5.1. GTP’消息 199.5.2. GTP’中直接使用GTP消息 219.5.3. GTP’中修改使用GTP消息 219.5.4. GTP’消息类型 229.5.5. 重复话单传送的防止 299.5.6. 备份方式对话单合并的影响 339.6. GTP的记录格式 339.6.1. 标准记录格式 349.6.2. 私有记录格式 349.7. 记录格式版本 349.8. FTP协议（Bw接口） 3510. 话单类型 3510.1. 类型列表 3510.1.1. PDG话单 3510.2. 话单参数描述 3710.2.1. AccessPointName(APN)Network/OperatorIdentifier 3710.2.2. CauseforRecordClosing 3810.2.3. ChargingCharacteristics 3810.2.4. ChargingCharacteristicsSelectionMode 3810.2.5. ChargingID 3810.2.6. Diagnostics 3910.2.7. Duration 3910.2.8. GGSNAddress/GGSNAddressUsed(PDGAddressused) 3910.2.9. SGSNAddress(ServingAAAServer/proxyAddress) 3910.2.10. ListofTrafficDataVolumes 3910.2.11. LocalRecordSequenceNumber 4010.2.12. NodeID 4110.2.13. PDPType 4110.2.14. RecordExtensions 4110.2.15. RecordOpeningTime 4210.2.16. RecordSequenceNumber 4210.2.17. RecordType 4210.2.18. ServedIMSI 4210.2.19. ServedMSISDN 4210.2.20. ServedPDPAddress(WLANUEremoteIPaddress) 4210.2.21. ServedIMEISV 4210.2.22. WLANSessionID 4311. 话单的ASN.1描述 4311.1. PDG输出WLAN-CDR的ASN.1定义 4312. 编制历史 54

前言本标准的目的是为中国移动通信集团公司设备引进、网络规划、设备制造、工程设计、网络运行、管理和维护等方面提供技术依据。本标准包括的主要内容包括了设备在功能、性能、接口、操作维护、等方面的要求。本标准是WLAN与2G/3G网络融合系列标准之一，该系列标准的结构、名称或预计的名称如下：序号标准编号标准名称[1]WLAN与2G/3G网络融合总体技术要求[2]WLAN与2G/3G网络融合PDG设备规范[3]WLAN与2G/3G网络融合TTG设备规范[4]WLAN与2G/3G网络融合安全隧道规范[5]WLAN与2G/3G网络融合计费规范[6]WLAN与2G/3G网络融合设备接口规范[7]WLAN与2G/3G网络融合统一认证流程规范（EAP-SIM/AKA）[8]WLAN与2G/3G网络融合3GPPAAAServer规范本标准的附录FORMTEXT为标准性附录，附录FORMTEXT为资料性附录。本标准由中移FORMTEXT号文件印发。本标准由中国移动通信集团计划部提出，集团公司技术部归口。本技术规范解释权属于中国移动通信集团公司。本标准起草单位：FORMTEXT中国移动通信研究院。本标准主要起草人：FORMTEXTPAGE1范围本标准规定了中国移动I-WLAN系统采用独立PDG架构时计费功能实现的范围，话单产生的方法，适用于中国移动I-WLAN系统核心网技术试验，为设备引进、网络规划与设备制造、工程设计、网络运行、管理和维护等提供技术依据。规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。术语、定义和缩略语下列术语、定义和缩略语适用于本标准：词语解释缩略语I-WLAN系统架构概述I-WLAN系统定义了WLAN和中国移动2G/TD互操作的网络结构、业务流程和接口，从而将WLAN网络与2G/TD网络建立互通，使得终端能够通过WLAN可以访问中国移动的分组域业务。网络部署时可以采用独立PDG方式或采用TTG+GGSN方式，本规范对这两种方式分别说明。I-WLAN系统结构示意图-非漫游场景（PDG模式）I-WLAN系统结构示意图-非漫游场景（TTG模式）I-WLAN系统结构示意图-漫游场景（PDG模式）I-WLAN系统结构示意图-漫游场景（TTG模式）WLAN系统在不改变现有的2G/TD网络和WLAN网络构架的前提下引入3GPPAAAServer和PDG/TTG设备，实现了基于2G/TD网络的接入控制和认证，并且UE可以通过WLAN网络接入PDG/TTG，从而访问中国移动分组域业务。WLAN计费总体架构I-WLAN系统离线计费架构如下图所示：I-WLAN系统离线计费参考模型-PDG组网非漫游场景I-WLAN系统离线计费参考模型-TTG组网非漫游场景I-WLAN系统离线计费参考模型-PDG组网漫游场景I-WLAN系统离线计费参考模型-TTG组网漫游场景3GPPAAAServer计费功能参见《WLAN与2G/3G网络融合3GPPAAAServer规范》；TTG组网场景下，离线计费数据采集点在GGSN上，TTG不计费，其中GGSN计费请参考《中国移动TD-SCDMA系统核心网分组域设备规范-计费分册》。PDG组网场景下，离线计费数据采集点在PDG上，本规范详细介绍PDG计费功能。PDG节点计费要求总体要求1）PDG可以为用户的每个承载（本规范定义的承载为隧道连接）赋予唯一的标识（即PDGChargingId），PDG上使用IMSI和MSISDN标识用户。2）由于数据传输所具备的上下行具备不对称性，对于上行、下行所对应的终端用户发送和接受的数据流量须分别统计。3）每个承载的计费信息应反映时间信息，如起始时间和持续时长。4）运营商对计费信息的产生具备一定的主控权，即可以通过在PDG上作配置，让PDG仅产生运营商需要的计费信息。5）作为可选项，PDG可根据HLR用户数据或缺省属性处理特定的计费，以便在运营商控制下基于PDG中话单触发参数配置提高计费话单产生的效率。7）PDG具备一定的CDR保存能力，以抵御因传输中断等原因造成CDR丢失的风险。8）要求PDG具备内容计费能力。9）要求PDG设备的业务提供模块与话单产生模块满足松耦合构架要求，保证当调整出单参数时不会对PDG设备性能产生影响。计费数据收集原则呼叫数据记录的生成及内容应当灵活并避免不必要的重复。每个CDR记录反映的应当是相对信息，即其前一记录关闭以后本身记录时间段内的流量信息。话单生成取决于实时需要、信息安全（备份）及特定事件，如部分话单时限到达，传送数据流量限制，系统内/系统间切换。费率改变时刻的到来不应该引发大量CDR的传送，以免发生阻塞。内容计费内容计费是指完成按照接入方式、业务种类、流量、时长、事件（点击等）、QoS，及其组合的计费。完整内容计费应该包含下列信息的组合：不同业务（内容）的流量信息；不同业务（内容）的时间信息；不同业务（内容）的事件信息；不同业务（内容）的信息费。内容计费信息应由流量计费平台和业务平台共同采集完成，由业务支撑系统完成最终的计费信息整合。在内容计费体系中，PDG做为基于业务的流量统计点，完成精细的，区分到业务的数据流量统计，不同的业务流量统计应区分上下行流量。基于APN的内容计费CMWAP和CMNET类业务基于CMWAP和CMNET的业务,因为分配了不同的APN,故可使用WLAN-CDR中的APN字段加以业务区分,从而实现基于APN的内容计费。VPNVPN业务采用不同APN时，使用WLAN-CDR中的APN字段可加以业务区分从而实现不同VPN的计费。基于应用的内容计费普通的WAP浏览业务、MMS业务，Kjava业务以及其他业务可能都基于同一个APN开展，即经过WAP网关实现的。对这些同一APN下的不同业务，根据市场要求需考虑采取不同的计费方式。作为与外部数据网络相连的节点,PDG应该能够区分出不同业务的数据流量，并通过话单表述出来。PDG设备应支持通过配置对某个APN关闭和开启内容计费功能，当关闭内容计费功能时WLAN-CDR格式应不包含内容计费字段信息（RecordExtensions）；业务解析PDG为分组数据网关节点，要求能够解决目前移动通讯网络承载的数据业务的接入和转发，同时要求能够根据预先配置在PDG的业务过滤计费规则，对流经PDG的业务数据流能够进行不同协议层次（从三层到七层）的业务分析，业务解析层次可配置从而区分不同数据业务，实现内容计费。承载层（基于承载或APN，指对业务过滤计费规则有效的APN）IP协议的第三层（基于源IP地址,源IP地址掩码,目的IP地址和目的IP地址掩码）IP协议的第四层（基于协议类型（如TCP/UDP等）、源,目的端口号），在第四层协议中，应能支持控制面与承载面分离（承载平面由控制平面动态分配）的协议类型（如FTP（passivemode）等）IP协议的应用层（第七层，基于应用的URL、特殊字段信息（如x-online-host字段）等），以上URL以及x-online-host字段的支持需要同时考虑WAP1.x和WAP2.0协议。现阶段要求PDG应支持的数据业务包括：HTTP业务、WAP浏览类业务、MMS业务、流媒体业务、邮件类业务（可选）、FTP业务（可选）等。因此PDG应具备对HTTP、WAP1.x、WAP2.0、RTSP、RTP和RTCP、FTP（可选）、POP3/SMTP（可选）的协议分析能力。流量统计要求PDG支持对于数据业务的IP层流量进行统计。要求PDG支持对于数据业务的应用层流量进行统计（可选）。内容计费规则配置在业务解析区分的基础上,PDG根据配置的内容计费规则，对业务数据包进行匹配达到流量区分的目的,并针对不同业务将区分出的相应流量信息记录在话单中。为满足今后移动数据业务灵活的计费要求，要求PDG可以同时支持7.3.21. 内容计费规则描述当数据包到达PDG后，PDG进行数据拆包分析并匹配内容计费规则，若匹配到计费规则，则进行内容计费，针对业务统计上下行流量。内容计费规则可配置的属性如下：APN业务ID源IP地址（可选）源IP地址掩码（可选）目的IP地址目的IP地址掩码源端口号范围（起始端口号~结束端口号）（可选）目的端口号范围（起始端口号~结束端口号）协议类型（TCP/UDP）七层应用的URL七层应用协议中的特殊字段值（现阶段要求支持x-online-host字段值）优先级（可选）1）APN：内容计费规则对应的接入点名称。2）业务ID：按照业务区分需要人工配置，与计费规则一一对应。业务ID记录在话单中表示业务的种类。同一类业务的上下行流量可以配置不同业务ID。（可选）业务ID为固定长度是10位的数字，顺序包含四部分内容： 全网/本地业务标识：1位数，1表示全网业务，2表示本地业务。 业务大类：2位数，区分业务属于WAP、彩信、流媒体还是KJAVA等。 接入省：3位数，省会长途区号首位去零，不足三位右补零。 业务编码：4位数，标识大类下需要进一步区分流量的业务。3）三/四层属性：包含目的IP地址和掩码、目的端口范围，协议类型（TCP/UDP）。源IP地址和掩码、源端口范围。（可选）4）七层属性：根据内容计费规则PDG要能够分析与某个URL连接有关的所有数据流量，且计费规则中URL应支持前置、中置、后置通配符和同时指定多个通配符，如/*,*.，*.mp3,www.*.com，www.isp.*，*.isp.*等。并且应能将七层应用协议中的特殊字段值（现阶段要求支持x-online-host字段的IP地址）作为过滤规则的属性对数据流进行区分。在进行七层URL的匹配时对于通配符按以下规定处理： “*”如用于URL的起始部分（“/”以前），只代表字符串且不包含“.”，如“*.”可以用于匹配“”； “*”如用于URL的路径部分（“/”以后），可代表任何字符，包括“/”，如“/*”可以用于匹配任何以/开头的URL； “*”如用于代表文件名或文件格式，如“*.mp3或news.*”，一般会加URL作为限定，如/*.mp3可以用于匹配任何以开头的URL下的mp3格式的文件；5）优先级：对内容计费规则按人工指定的顺序进行匹配。（可选）PDG需要支持缺省（default）规则的设置，该计费规则统计所有内容计费规则匹配不成功的数据包流量。内容计费规则设置中，不同计费规则若存在互包含关系，则必须是真包含关系。被包含的计费规则相对于另一条计费规则称为子集计费规则。PDG应具备规则冲突检测机制，若规则配置中出现违背以上原则的情况需要提示。2. 内容计费规则配置要求PDG支持计费规则的静态配置，即所配置的内容计费规则在数据处理流程中规则的属性不发生变化。计费规则配置的更新不需要重启PDG设备。PDG需要考虑未来基于IMS数据业务等的流量统计需要，计费规则需要结合策略机制动态协商配置。配置管理的功能可以在PDG本地维护终端实现或者集成到现有的网管系统中。所有的内容计费配置项可以统一进行维护，PDG本地维护终端应该提供稳定可靠，简单易用的图形操作界面。界面中各元素应清晰可读，不具备二义性。在配置界面上，应该能提供详细的在线帮助，可以方便地进行搜索、查询操作。操作人员可以通过图形界面，进行内容计费规则的创建,添加、修改、编辑等操作。内容计费数据配置要求：（1）PDG可以配置的三层至七层的计费规则数应当不少于1000个，其中七层计费规则数不少于400个；（2）PDG可以配置用于内容计费的APN个数应当不少于200个。为了确保内容计费规则配置的正确性，提供带有内容计费能力PDG的公司必须同时提供独立于设备的内容计费规则配置局数据核查软件，简称“局数据核查软件”，局数据核查软件的规范另外提供。内容计费规则的匹配PDG对计费规则的匹配和业务数据包的拆包分析结合进行，处理流程如下：1、PDG分析数据包三/四层属性，获得数据包的目的IP地址和端口号等信息；2、在包含三/四层属性的计费规则中进行顺序匹配，若匹配到某条规则，且该规则不包含七层属性，则跳转到第6步；3、PDG分析数据包七层属性，获得数据包的七层URL属性；4、在包含七层属性的计费规则中进行顺序匹配，若匹配到某条规则，则跳转到第6步；若没有匹配规则，而且规则包含三/四层属性，则在仅包含三/四层属性的计费规则中进行顺序匹配，若匹配到某条规则，则跳转到第6步；5、将数据流量统计入缺省规则对应的流量；6、将数据流量统计入匹配规则对应的业务流量。计费规则的匹配顺序上应遵循以下原则：若两个计费规则之间存在互包含关系，则子集计费规则匹配优先级应高于另一条计费规则。PDG对于计费规则应具备优先级处理机制，根据计费规则的属性配置，基于上述原则自动确定规则的匹配顺序。PDG可以对计费规则的优先级项进行人工配置调整匹配的先后顺序。（可选）内容计费的业务支撑要求经过PDG的上下行分组数据包按照运营商制定的内容计费规则过滤，依据过滤结果,在WLAN-CDR的RecordExtension域记录其业务类型标识，以方便计费中心识别。在一个承载的会话过程中，移动用户接收／发出属于多个应用的数据包，即使它们都使用同一APN，不同应用的识别号以及相应的上下行数据流量也会在WLAN-CDR的RecordExtension参数相应的域中体现。做为未来内容计费的要求,不同应用的服务质量(QoS)也应加以记录。同一承载中不同应用的计费信息在RecordExtension中采取列表方式记录。对RecordExtension字段的具体要求参见本规范的相关章节。涉及内容计费的承载的计费话单的部分输出,遵循WLAN-CDR的部分输出原则.CG对包含有内容计费的WLAN-CDR的合并,可根据运营商的要求,按照内容类型的不同,加以合并处理。若同一应用的计费信息合并中存在部分项的数据不同（例如QoS），则计费信息列表方式记录。要求PDG支持后付费的内容计费，话单产生条件和普通话单产生条件相同。要求PDG支持热付费的内容计费，话单产生条件和普通话单产生条件相同。热计费话单要求3-10秒内传送到BOSS，时间长度可设置，话单传送接口支持FTP方式。在产生的话单中应当有热计费标志。（可选）数据业务的内容计费流程PDG内容计费所支持的业务按业务特点可以分成三类：第一类业务，端口不动态变化，业务需基于URL识别，如HTTP，WAP，MMS，下载类（流媒体下载、KJAVA下载）。内容计费流程如下：1-4、UE发起用户激活上线，PDG、WAPGW记录用户信息；5、用户同业务服务器建立连接；6、用户发起业务访问，PDG根据计费规则匹配业务，开始计费，统计业务流量信息；7、用户和业务服务器之间发送业务数据；8、PDG采集流量，如果满足产生部分话单条件，PDG产生中间话单，话单发送到CG，CG进行预处理后把话单发送到BOSS处理；9、业务结束，PDG停止该业务流量统计，承载释放后，产生最终话单。第二类业务，如在线流媒体，从协议上能够区分控制面与数据面，控制面的端口固定，数据面的会话（IP或端口）由控制面协商确定。业务流程如下：1-4、UE发起用户激活上线，PDG、WAPGW记录用户信息；5、用户同业务服务器建立连接；6、用户发起业务访问，同业务服务器发送控制面的交互消息，PDG根据计费规则匹配务，开始计费，统计业务流量；7、PDG根据控制面消息交换结果，生成新计费规则用来匹配业务数据；8、用户和业务服务器之间通过数据面发送业务数据。PDG根据新计费规则，采集用户流量；9、PDG采集流量，如果满足产生部分话单条件，PDG产生中间话单，话单发送到CG，CG进行预处理后把话单发送到BOSS处理；10、业务结束，PDG停止该业务流量统计，承载释放后，产生最终话单。第三类业务，属于Server端端口固定的业务，可通过3/4层解析进行内容计费，如POP3/SMTP、在线KJAVA应用等，流程如下：1-4、UE发起用户激活上线，PDG、WAPGW记录用户信息；5、用户同业务服务器建立连接，PDG根据3/4层计费规则匹配业务，开始计费；6、用户和业务服务器之间发送业务数据；7、PDG采集流量，如果满足产生部分话单条件，PDG产生中间话单，话单发送到CG，CG进行预处理后把话单发送到BOSS处理；8、业务结束，PDG停止该业务流量统计，承载释放后，产生最终话单。对于第一类和第二类业务，要求对业务请求之前产生的信令连接包（如TCP握手消息等）能够归并到业务数据对应的计费流量中，如果由于特殊原因仅有信令连接包而无业务请求消息出现，则将这部分信令连接包的流量统一归入一个专门的业务代码表示的流量中；不同数据业务的内容计费流程参见《中国移动TD-SCDMA系统核心网分组域设备规范_计费分册V1.1内容计费对PDG的性能影响PDG增加内容计费功能后对数据处理性能要求：1. PDG开启内容计费功能后支持的承载个数应当不少于未开启内容计费功能支持的承载个数的50%；2. PDG开启内容计费功能后的数据吞吐量应当不少于未开启内容计费功能的数据吞吐量的60％；3. 开启内容计费功能对PDG数据转发时延的增加小于1ms。4.PDG经过改造支持内容计费后在未开启内容计费功能的情况下性能应不受影响；实时计费（可选）PDG设备近期应能针对目标用户进行欠费风险控制，从而有效降低欠费，远期应该能够平滑支持实时计费。详细要求请参见《中国移动分组域欠费风险控制技术规范》。计费话单产生机制概述PDG产生WLAN-CDR，并将收集的计费信息通过CGF传送给计费系统。PDG与CGF应支持及时产生话单（秒级），要求PDG与CGF产生话单的出单参数可灵活配置。PDG应有内部存储介质用于话单的存储，存储介质的容量建议PDG可保证本计费点所产生的话单至少可保存7天以上。这些存储介质应有充分的热备份设置。在PDG中可以针对每个计费特性允许或禁止生成话单。如果允许生成话单，可以对每个计费特性定义以下不同的触发条件参数：数据流量门限；时间（时长门限）；计费条件改变的最大数（QoS改变，费率时间改变）。PDG话单（WLAN-CDR）产生机制承载建立时，PDG为每个承载创建一个WLAN-CDR话单。如果是基于业务流的话单，则在业务流开始时，为这个业务流创建一个容器，如果是基于RatingGroup的话单，如果这个业务流是该RatingGroup的第一个业务流，则为这个业务流创建一个容器。如果是基于业务流的话单，则业务流终止时，要关闭容器；如果是基于RatingGroup的话单，如果这个业务流是该RatingGroup的最后一个业务流，则关闭该业务流的容器。承载结束时，PDG关闭WLAN-CDR话单。运营商配置的时间门限超时，这个事件可以触发WLAN-CDR关闭，如果此承载仍然处于激活态，则重新创建一个WLAN-CDR话单。运营商配置的流量门限超时，这个事件可以触发WLAN-CDR关闭，如果此承载仍然处于激活态，则重新创建一个WLAN-CDR话单。计费条件变化，例如费率切换，触发容器关闭，如果业务流仍然处于激活态，则创建一个新容器。运营商配置的容器限制超过限制，则关闭WLAN-CDR，如果此承载仍然处于激活态，则重新创建一个WLAN-CDR话单。计费信息追加触发条件WLAN-CDR的业务流量列表（ListofServiceDataVolumes）属性由一系列容器组成，在满足表5的特定触发条件时被加入列表中，以记录满足该触发条件的上行和下行流量。表:业务流量列表追加计费信息的触发条件触发条件描述费率时段变更费率时段变更时，应添加一个容器到CDR的业务流量列表。业务流变化如果业务流量列表是基于每个业务流的，则业务流结束时需要关闭该容器，如果业务流量列表是基于每个RatingGroup的，则当此RatingGroup对应的最后一个业务流结束时关闭该容器。话单关闭话单关闭时所有激活的业务流量列表容器都应该添加到WLAN-CDR话单中。话单关闭触发条件满足特定触发条件时，WLAN-CDR应被关闭。下表说明应支持哪些条件以允许关闭WLAN-CDR。表:关闭WLAN-CDR的触发条件关闭条件描述PDG上的承载结束承载结束将导致CDR的关闭。触发条件包括：- 承载终止- 其他异常释放。计费网关对话单的处理CGF（ChargingGatewayFunctionality，计费网关功能）提供从PDG节点向运营商的BS传送计费信息的机制。要求从PDG设备产生话单，到CGF生成BOSS可采集的话单文件的时延小于15分钟。CG设备应有内部存储介质用于话单的存储，存储介质的容量建议CG应能存储30天以上的话单。这些存储介质应有充分的热备份设置。要求CG设备可以存储6个月以上的离线话单。CGF必须提供的功能如下：1)负责收集PDG的计费数据；2)对计费数据进行较长时间的保存并进行合并分拣等预处理工作；3)负责将收集到的PDG的计费数据分别送往计费中心；另外为了减少CGF与计费中心间的传输量，CGF应该提供一定的部分话单合并功能，以减少送往计费中心的CDR数量。从而减少对计费中心的传输线路的带宽要求以及减轻计费中心的处理负担。另外，CGF应支持通过开关开启或关闭话单透传功能。对PDG话单的处理CGF通过Wz口接收PDG话单，对PDG话单的处理分为话单采集、原始话单保存、话单预处理、最终话单保存、话单传送到计费中心几个主要过程。话单采集采用GTP’协议从PDG采集话单，CGF接收到GTP’帧后，根据序列号判断是否是重复的话单帧号。从而保证话单不重复接收和保存。原始话单保存CGF将采集到的正确的话单帧保存到磁盘中，形成原始话单文件记录，可以长期保存该原始话单记录，防止系统重启或者掉电下的话单记录丢失。话单预处理CGF将采集到的原始的话单记录进行预处理，包括话单合并、话单分拣等处理。话单合并是根据话单中的关键字将同一个承载的话单合并为一张话单，这些关键字能唯一标志属于同一个承载的话单；话单分拣是将话单中某些特定字段作为条件，根据字段的值将话单分拣到不同的目录存储。CGF预处理能对各种原因触发关闭的承载话单进行处理。最终话单保存CGF将预处理后的话单从内存中转存到磁盘文件中，形成最终话单文件，可以长期保存，防止系统重启或者掉电下的话单记录丢失。话单传送到计费中心CGF将形成的最终话单文件按照要求定时的传送到计费中心供计费使用。话单合并在PDG组网用户激活时，PDG针对每个承载产生话单，并用唯一的C-ID标识。对于同一个承载，可能对应多个部分话单，需要进行话单合并。部分话单的合并分两级进行：第一级合并由CGF进行，可以减少CGF与计费中心间的带宽要求以及减轻计费中心的处理负担，由于各种原因，这一级的话单合并可能是不完全的；第二级合并由计费中心进行，主要合并在CGF中未完全合并的话单，从而产生最终的话单。对于每个承载由PDG负责产生一个唯一的C-ID，根据C-ID+PDG地址，可以确定两张部分话单是否属于同一个承载。合并依据记录中的PDG地址+C-ID及记录类型是合并的依据。合并触发方式PDG定期（在数十秒到数百秒）向CGF发送CDR，合并可以采用事件触发方式和定期合并方式相结合的方法，具体实现方法由厂商确定。合并过程中各字段的处理无需额外处理的字段在一个承载中，RecordType、ServedIMSI、ServedIMEISV、ServedMSISDN、ChargingID、PDGAddressUsed、ServingAAAServer/proxyAddress、APNNetworkIdentifier、PDPType、WLANUERemoteIPAddress、ChargingCharacteristics、Diagnostics、ChargingCharacteristicsselectionmode、NodeId、WLANSessionID、RecordExtensions中的ExtensionType和ServiceCode，以上字段保持不变，合并时只需要保留一个。需要过滤的字段如果没有发生差错，几个连续的WLAN-CDR具备合并性。对RecordOpeningTime字段仅保留第一个部分记录的该字段，后续记录的该字段被过滤，对于一批连续部分话单，Duration字段=最后的部分记录的RecordOpeningTime-最先的部分记录的RecordOpeningTime+最后的部分记录的Duration字段；对于不连续话单Duration字段累加。需要拼接的字段ListofTrafficData字段为一列表，该字段合并实际就是将各列表链接形成一个列表。对于LocalRecordSequenceNumber字段，合并前是整数类型，合并过程中将这些整数拼成一张列表，在列表首加上本PDG的地址。对于RecordSequenceNumber字段，合并前是整数类型，合并过程中将这些整数拼成一张列表，在列表首加上本PDG的地址。RecordExtensions记录的各业务流量需要按照业务类别进行合并。业务编码相同的，上下行流量和UsageDuration各自累加，对于可选的URL字段需要拼接，或是只是记录第一个URL，不管采用哪种方式，都不能超过URL字段的长度限制；业务编码不同的，合并成列表。需要添加的字段添加合并结果（ConsolidationResult）标志，如果对一个承载完成合并，置正常（Normal）标志；如果合并过程中发现错误，置不正常（Abnormal）标志。如果合并后的话单中字段列表域的长度超过最长范围，那么置超出门限（ReachLimit）标记。合并流程第一步：根据PDG地址+C-ID将原始话单分类。第二步：话单合并，CDR合并过程中首先看记录的RecordSequenceNumber是否在RecordSequenceNumber列表中存在，如果存在则说明是重复话单，予以剔除，回到第二步；否则将该字段加入列表，进入第三步。第三步：比较RecordOpeningTime字段，保留小的（先打开的），剔除大的；Duration字段累加；RecordExtension字段中的UpVolume、DownVolume、和UsageDuration字段累加；ListofTrafficData拼接；CauseforRecordClosing字段按优先级顺序保留，优先级由高到低是：承载释放（normalRelease），部分话单（Partialrecord）。第四步：每次合并操作后检查CauseforRecordClosing字段，如果CauseforRecordClosing字段=normalRelease，说明本次会话过程结束，则完成合并过程，转第五步。如果CauseforRecordClosing＝maxChangeCond，说明部分话单由于计费条件改变次数达到最大值（Qos改变或者费率时段变更引起），则停止继续合并，转第五步。如果CauseforRecordClosing字段原因是Partialrecord（如timelimit或volumelimit），说明还有后续记录，需要继续合并，转第二步。第五步：如果合并完成（即CauseforRecordClosing字段=normalRelease或者记录量达到门限），检查相同PDG地址+C-ID下所有话单的RecordSequenceNumber列表，检查累加记录数=最大序号是否满足，如满足置所有话单的ConsolidationResult=Normal，如不满足置ConsolidationResult=Abnormal；如果是因为达到记录量的原因无法再合并，则置ConsolidationResult=ReachLimit。第六步：如ConsolidationResult=Normal，CGF可以将该记录发往BS；如ConsolidationResult=Abnormal，则说明中间有部分话单丢失，转第二步继续合并，如在规定时间内仍然未能达到ConsolidationResult=Normal，则CGF保留该字段为Abnormal，可以将该CDR送往BS，如果以后再有该次会话的部分记录到来CGF将之送到BS并由BS的预处理部分试图合并。PDG与主CGF间的通信发生故障的情况当PDG与主CGF间的通信发生故障，CDR将被传送给备CGF，这种情况下，主CGF与备CGF都无法完成完成的合并，需要BOSS做后续的合并。计费采集接口和协议PDG-CGF的协议栈承载协议可以用UDP或TCP协议来承载GTP’协议，当采用UDP协议时，UDP的目的端口号定为3386，即GTP’协议的端口号，也可以配置定义其它端口号。UDP的源端口号由发端分配。一旦端口号确定下来，收端的源端口号采用发端的目的端口号，收端的目的端口号采用发端的源端口号。如果采用TCP协议，端口分配情况与UDP一样。计费节点的原则对支持GTP’的PDG节点，若该节点不能识别另一节点，应能相互发送信息：”Service/Versionnotsupported”。每个PDG都可以配置一个CGF列表，列表中定义各CGF的优先等级，如果主CGF退出服务（出现故障或负荷太重），那么PDG将把CDR送下一级的CGF，以此类推。PDG原则上只能将CDR送到位于同一PLMN中的CGF，而不能送到不同PLMN的CGF中。GTP’计费通信协议GTP’采用GTP的协议框架，但仅采用GTP协议的信令平面。消息内容部分详见3GPP

TS

29.060.1）GTP消息头下图表示了GTP’协议头的格式：BitsOctets876543211VersionPTSpare“111““0“2MessageType3-4Length5-6SequenceNumber图8-4GTP’协议头的格式以下为各个单元的说明：PT为”0”，表示是GTP’Version指GTP’的版本，建议为GTP’V1；第一位”0”在GTP’MessageType表示消息类型；Length表示消息的长度，但不包括信头本身的长度；SequenceNumber对于信令消息来说是会话的标识。2）GTP消息体

图8-5GTP消息体消息体说明：信令消息可包含多个参数。参数种类有TLV（Type，Length，Value）和TV（Type，Value）两种。TLV参数由类型、长度、参数值三部分构成，其中类型占一个字节，长度占二个字节，长度值指示参数值的字节数。TV参数由类型、参数值二部分构成，其中类型占一个字节，参数值根据类型而定。TV的Type最高比特置为0，TLV的Type最高比特置为1。GTP’消息GTP’消息GTP’在GTP协议的基础上增加了两类信令消息：通路管理消息：NodeAliveRequest（MTV=4），NodeAliveResponse（MTV=5），RedirectionRequest（MTV=6），RedirectionResponse（MTV=7）记录传输消息：DataRecordTransferRequest（MTV=240），DataRecordTransferResponse（MTV=241）GTP’在GTP协议的基础上增加了消息单元，其编号情况如下：（保留字段填任意值，今后扩展用）参数定义分为：117-127(TV信息)and239-254(forTLVtypefields)TLV参数的说明: 254 AddressofRecommendedNode 253 RequestsResponded 252 DataRecordPacket 251 ChargingGatewayAddress(thisIEisalsousedin3GPP

TS

29.060) 250 SequenceNumbersofCancelledPackets 249 SequenceNumbersofReleasedPacketsTV参数的说明: 127 ChargingID 126 PacketTransferCommand增加的原因码（CauseCodes）：request类消息的原因码范围是49–-63，acceptance类响应消息的原因码范围是177—191，rejection类响应消息的原因码范围是241—255。GTP’在GTP协议的基础上增加的原因码如下：Request类消息：63 Thisnodeisabouttogodown62 Anothernodeisabouttogodown61 Thereceivebuffersarebecomingfull60 Thetransmitbuffersarebecomingfull59 Systemfailureacceptance类消息：177 CDRdecodingerrorrejection类响应消息：255 Requestnotfulfilled254 Sequencenumbersofreleased/cancelledpacketsIEincorrect253 Requestalreadyfulfilled252 Requestrelatedtopossiblyduplicatedpacketsalreadyfulfilled表8-1计费相关的GTP’消息MessageTypevalue(Decimal)GTP'message1EchoRequest2EchoResponse3VersionNotSupported4NodeAliveRequest5NodeAliveResponse6RedirectionRequest7RedirectionResponse240DataRecordTransferRequest241DataRecordTransferResponseothersreservedforfutureuseGTP’中直接使用GTP消息以下为GTP协议中规定的GTP’中仍然使用的消息：1、EchoRequest和EchoResponse用于检测节点是否处于工作状态。如果采用TCP承载协议，则EchoRequest和EchoResponse消息可以不采用。2、VersionNotSupported消息的用法没有变化，在该消息中应携带最新能够支持的GTP’协议。注VersionNotSupported消息的值：在1998年10月制定的GSM12.15v.7.0.0其GTP’版本号为0（用二进制000来表示），在1999年12月制定的GSM12.15v.7.3.0其GTP’版本号为1（用二进制001来表示），在2000年6月制定的GSM12.15v.7.5.0其GTP’版本号为2（用二进制010来表示）。GTP’中修改使用GTP消息GTP’中在以下情况时修改使用的GTP的消息如下所述：建立承载时：ChargingID，ChargingGatewayAddress更新承载时：ChargingID，ChargingGatewayAddress建立AA承载时：ChargingID，ChargingGatewayAddress（详见3GPP

TS

29.060）GTP’消息类型NodeAliveRequest当节点从不可用状态转到可用状态时，可以用NodeAliveRequest消息通知对端。如果采用TCP作通路协议，该消息可以不用。NodeAliveRequest较EchoRequest快速，当NodeAliveRequest消息和EchoRequest同时使用时，可以加大EchoRequest的发送间隔，这样减轻网络负荷。表8-2NodeAliveRequest消息参数参数（IE）必备（M）/任选（O）NodeAddressMPrivateExtensionONodeAliveResponseNodeAliveResponse用于对NodeAliveRequest的响应。表8-3NodeAliveResponse消息参数参数（IE）必备（M）/任选（O）PrivateExtensionORedirectionRequest当CGF不能继续正常工作或者CGF与后面的系统（如BS）失去联系时，CGF发RedirectionRequest消息给PDG，指示PDG将CDR发送到其它CGF。注：指示的CGF必须是位于同一个PLMN之内的，而不能是位于其它PLMN的CGF。表8-4RedirectionRequest消息参数

参数（IE）必备（M）/任选（O）CauseMAddressofRecommendedNodeOPrivateExtensionO原因码定义：1 Thisnodeisabouttogodown2 Anothernodeisabouttogodown3 Systemfailure4 Receivebuffersbecomingfull5 SendbuffersbecomingfullCGF的地址消息有两种格式：IPv4、IPv6（见下图）图8-6CGF的IPV4地址格式

图8-7CGF的IPV6地址格式RedirectionResponseRedirectionResponse作为对RedirectionRequest的响应。表8-5RedirectionResponse消息参数参数（IE）必备（M）/任选（O）CauseMPrivateExtensionO原因码定义：1 RequestAccepted2 Noresourcesavailable3 Servicenotsupported4 Systemfailure5 MandatoryIEincorrect6 MandatoryIEmissing7 OptionalIEincorrect8 Invalidmessageformat9 VersionnotsupportedDataRecordTransferRequest1、背景介绍正常情况的GTP’通信过程为：PDG向CGF发送数据包，CGF返回响应”RequestAccepted”。冗余CGF防止重单进入计费系统的机制介绍：（流程见下图所示，数字表示处理顺序，带”a”或“b”的数字，表示可选顺序）发送CDR给CGF1，没有返回成功响应的消息重试后，仍无响应发送该CDR给CGF2（标记为可能为重单）CGF2返回接收响应的消息（PDG等待CGF1的响应，CGF2将等待进一步处理的消息）CGF1向PDG发送节点活动请求的消息PDG向CGF1发送节点活动接收的消息用相同的序列号发送空包CGF1返回：a)返回接收该包的消息；b)返回该包为重包的消息PDG根据CGF1的返回消息，向CGF2发送消息a)提交处理该包；b)停止处理该包CGF2返回请求接收的消息注：2b)和11a)为可能向计费系统发送CDR的处理异常处理:缺省情况下，超时将重发CDR。若发送CDR给CGF1和CGF2都失败，PDG将尝试CGF3。若未收到(10)，PDG将不断重发(9a)或(9b)若PDG-CGF通讯联接断，PDG将向管理平台发告警，管理平台进行后续处理图8-8冗余CGF防止重单的机制CGF冗余机制详述：如果是网络原因，CGF可能无法在额定时间内对PDG的请求消息响应。根据3GPP

TS

29.060，PDG将再试一次。若PDG联接CGF失败，它将尝试下一个CGF。 序列号缓冲：若联接失败，PDG将无法和主CGF通信。在重试失败后，PDG将CDR重发到次CGF。PDG在内部缓冲中维护了主CGF未响应的请求的序列号，以等待该CGF恢复后再行处理。同时，PDG在内部缓冲中也维护了发送到次CGF的数据包的序列号（若到次CGF的通信也失败，PDG将与下一个CGF进行通信）。另外CGF在内部缓冲中也维护了每个PDG联接的序列号，以用于可能的PDG重单处理：若主CGF未成功处理，次CGF可将CDR提交到计费系统；若主CGF处理成功，次CGF取消该CDR的处理。当接收到主CGF的响应后，PDG可以取消次CGF对CDR的处理。为确认CDR的处理情况，PDG向主CGF发送测试包（带有消息：”SendpossiblyduplicatedDataRecordPacket”，并和先前的包有相同的序列号），若主CGF返回响应”RequestAccepted”，PDG将通知次CGF提交CDR并发送到计费系统；若主CGF返回响应”Requestrelatedtopossiblyduplicatedpacketsalreadyfulfilled“，PDG将通知次CGF取消CDR处理。 为避免PDG异常时（序列号缓冲坏或重包）CDR一直驻留在CGF中，须通过清理CGF缓冲的方法。 为了避免以下情况：直到CDR的最后一个序列号产生，PDG的备份缓冲一直都不能正常使用。必须有可配置的参数去控制CGF决定是否将CDR发送到计费系统。使操作员可进行以下操作：通过配置可以使PDG和CGF进行排除重单，计费系统不必排除CGF冗余引起的重单。通过配置可以使计费系统进行排除重单。为更有效地排除重单，CGF可以在可能的重单后加标记（该标记不应出现在PDG为计费系统提供的内容中）（也可以用特殊的文件名进行标识）。尽管重单有标记，计费系统也会多一些额外的工作。同时，CGF可以不管是否可能有重单，直接将CDR发送到计费系统，CGF也可以有配置参数决定以下消息是否有效：DataRecordPacketCancel/Release2、DataRecordTransferRequest消息本消息用于传送CDR信息，CDR放在DataRecord参数中。表8-6DataRecordTransferRequest消息参数参数（IE）必备（M）/任选（O）/特定条件必须（C）PacketTransferCommandMDataRecordPacketCSequenceNumberofReleasedPacketsCSequenceNumberofCancelledPacketsCPrivateExtensionO3、PacketTransferCommand参数PacketTransferCommand参数意义如下：1）SendDataRecordPacket2）SendpossiblyduplicatedDataRecordPacket3）CancelDataRecordPacket4）ReleaseDataRecordPacket详细说明如下：SendDataRecordPacket消息用于正常CDR的传送，这种情况下带DataRecordPacket参数。SendpossiblyduplicatedDataRecordPacket消息用于将CDR传向备用CGF，这种情况下带DataRecordPacket参数。CancelDataRecordPacket消息带SequenceNumberofCancelledPackets参数。ReleaseDataRecordPacket消息带SequenceNumberofReleasedPackets参数。DataRecordTransferCommand参数结构如图所示：比特字节876543211Type=126（十进制）2PacketTransferCommand图8-9PacketTransferCommand消息参数4、DataRecordPacket参数当PacketTransferCommand为”SendDataRecordPacket”或”SendpossiblyduplicatedDataRecordPacket”时，DataRecordPacket出现在消息体中。DataRecordPacket的内容如下图所示：图8-10DataRecordPacket消息参数说明：若无数据，该单元应只包含Type（”252”）和Length（”0有2个CDR标识单元：DataRecordFormat和DataRecordFormatVersion。DataRecordFormat标识CDR的格式是ASN.1或其它格式DataRecordFormatVersion标识CDR的版本（release和version）5、ReleasedPackets参数的序列号比特字节876543211Type=249（十进制）2…3Length4…5SequenceNumber1n…n+1SequenceNumberN图8-11ReleasedPackets消息参数6、CancelledPackets参数的序列号比特字节876543211Type=250（十进制）2…3Length4…5SequenceNumber1n…n+1SequenceNumberN图8-12CanceledPackets消息参数7、PrivateExtension参数PrivateExtension包含了用户或运营商的特殊信息。DataRecordTransfer该消息用于对DataRecordTransferRequest的响应。一个DataRecordTransferResponse可以完成对多个DataRecordTransferRequest的响应。表8-7DataRecordTransferResponse消息参数参数（IE）必备（M）/任选（O）/特定条件必须（C）CauseMRequestsRespondedMPrivateExtensionO原因码定义：1 RequestAccepted2 Noresourcesavailable3 Servicenotsupported4 Systemfailure5 MandatoryIEincorrect6 MandatoryIEmissing7 OptionalIEincorrect8 Invalidmessageformat9 Versionnotsupported10 Requestnotfulfilled11 CDRdecodingerror12 Requestalreadyfulfilled13 Requestrelatedtopossiblyduplicatedpacketalreadyfulfilled原因码”CDRdecodingerror”为可选，用来通知PDG不能解析它的CDR。DataRecordTransferResponse涉及的参数如图所示：

比特字节876543211Type=253（十进制）2…3Length4…5SequenceNumber1n…n+1SequenceNumberN图8-12RequestsResponded消息参数PrivateExtension包含了用户或运营商的特殊信息。若产生的原因码级别高或出现频率高，PDG可以选择另一个CGF。重复话单传送的防止以下例子说明了3种DataRecordTransferRequest/Response情况：正常情况CDR的传送PDG发送CDR到CGF成功并接收到正确响应，不需作重发处理。CDR未正确接收前PDG-CGF1之间的连接中断发送CDR已失败，且未接收到CGF响应。CDR已经正确接收后PDG-CGF1之间链路中断。CGF已接收CDR成功，但发送接收成功响应时和PDG通信中断。以下为这3种情况的处理流程：正常情况CDR的传送以下为处理顺序图：图8-13正常情况CDR的传送处理顺序图以下为对各个处理的说明：1) PDG发送CDR到CGF，发送的相应的消息为”SendDataRecordPacket”。2) CGF处理消息，并存储CDR到本地。3) CGF发送响应消息到PDG，消息内容为”RequestAccepted”4) PDG接收消息”RequestAccepted”后，从缓冲内删除该CDRGTP’接收响应时失败，会在额定时间内和达到设定次数前重新发送请求。CDR未正确接收前PDG-CGF1之间的连接中断以下为处理顺序图：图8-14CDR未正确接收前PDG-CGF1之间的连接中断时的处理顺序图以下为对各个处理的说明：1）PDG向CGF1（主用CGF）发DataRecordTransferRequest消息，其中PacketTransferCommand参数是SendDataRecordPacket。2）因为PDG与CGF1之间失去联系，CGF1没有将CDR安全保存。3）PDG无法收到响应或者收到”Noresourcesavailable”之类的拒绝响应。4）PDG检测与备用CGF2之间的链路（用EchoRequest），如果正常则PDG将与送往CGF1相同的CDR送往CGF2，使用DataRecordTransferRequest消息，PacketTransferCommand参数是SendpossibleduplicatedDataRecordPacket。5）CGF2处理接收到的CDR，因为该分组被标识为possibleduplicated，虽然CGF2保存该分组，但是不立刻送往BS。6）CGF2送正确接收确认信息给PDG，采用DataRecordTransferResponse消息，Cause参数置为RequestAccepted。7）PDG可以将成功发送的CDR（但可能重复）删除，但是仍然保留该分组的序列号（SequenceNumber）。8）CGF1恢复以后，向PDG送NodeAliveRequest消息，PDG知道又可以与CGF进行通信。9）PDG采用NodeAliveResponse消息确认。10）对于前面未得到确认的DataRecordTransferRequest消息，PDG向CGF1发送空的测试分组，空分组仅仅是DataRecordPacket参数中不包含CDR负载，