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

QB-╳╳-╳╳╳-╳╳╳╳

CMCC 2G/3G system and WLAN interworking Charging Specification 版本号：0.3.0

╳╳╳ ╳-╳╳-╳╳发布 ╳╳╳╳-╳╳-╳╳实施

中国移动通信企业标准

中国移动WLAN与2G/3G网络融合

计费规范

中国移动通信集团公司 发布

QB-╳╳-╳╳╳-╳╳╳╳

目 录

前 言 ............................................................................................................................................ III 1. 范围........................................................................................................................................... 1 2. 规范性引用文件 ....................................................................................................................... 1 3. 术语、定义和缩略语 ............................................................................................................... 1 4. I-WLAN系统架构概述 ........................................................................................................... 1 5. WLAN计费总体架构 .............................................................................................................. 3 6. PDG节点计费要求 .................................................................................................................. 5

6.1. 总体要求 ................................................................................................................... 5 6.2. 计费数据收集原则 ................................................................................................... 6 6.3. 内容计费 ................................................................................................................... 6

6.3.1. 基于APN的内容计费........................................................................ 6

6.3.2. 基于应用的内容计费........................................................................ 6

6.4. 实时计费（可选） ................................................................................................. 13 7. 计费话单产生机制 ................................................................................................................. 13

7.1. 概述 ......................................................................................................................... 13 7.2. PDG话单（WLAN-CDR）产生机制 .................................................................. 13

7.2.1. 计费信息追加触发条件.................................................................. 14

7.2.2. 话单关闭触发条件.......................................................................... 14

8. 计费网关对话单的处理 ......................................................................................................... 14

8.1. 对PDG话单的处理 ............................................................................................... 15

8.1.1. 话单合并.......................................................................................... 16

8.1.2. PDG与主CGF间的通信发生故障的情况 ...................................... 17

9. 计费采集接口和协议 ............................................................................................................. 18

9.1. PDG-CGF的协议栈 ............................................................................................... 18 9.2. 承载协议 ................................................................................................................. 18 9.3. 计费节点的原则 ..................................................................................................... 18 9.4. GTP’计费通信协议 ................................................................................................ 18 9.5. GTP’消息 ................................................................................................................ 19

9.5.1.

9.5.2. 9.5.3. 9.5.4. 9.5.5. 9.5.6.

9.6.

GTP’消息 ......................................................................................... 19 GTP’中直接使用GTP消息 ............................................................. 21 GTP’中修改使用GTP消息 ............................................................. 21 GTP’消息类型 ................................................................................. 22 重复话单传送的防止...................................................................... 29 备份方式对话单合并的影响.......................................................... 33

GTP的记录格式 .................................................................................................... 33

9.6.1. 标准记录格式.................................................................................. 34 9.6.2. 私有记录格式.................................................................................. 34

9.7. 记录格式版本 ......................................................................................................... 34 9.8. FTP协议（Bw接口） .......................................................................................... 35 10. 话单类型 ......................................................................................................................... 35

10.1. 类型列表 ................................................................................................................. 35

10.1.1. PDG话单................................................................................... 35

I

QB-╳╳-╳╳╳-╳╳╳╳

10.2.

话单参数描述 ......................................................................................................... 37

10.2.1. Access Point Name (APN) Network/Operator Identifier ......... 37 10.2.2. Cause for Record Closing ......................................................... 38 10.2.3. Charging Characteristics ........................................................... 38 10.2.4. Charging Characteristics Selection Mode ................................. 38 10.2.5. Charging ID .............................................................................. 38 10.2.6. Diagnostics ................................................................................ 39 10.2.7. Duration .................................................................................... 39 10.2.8. GGSN Address/GGSN Address Used(PDG Address used) ..... 39 10.2.9. SGSN Address(Serving AAA Server/proxy Address) ............. 39 10.2.10. List of Traffic Data Volumes .................................................... 39 10.2.11. Local Record Sequence Number .............................................. 40 10.2.12. Node ID ..................................................................................... 41 10.2.13. PDP Type .................................................................................. 41 10.2.14. Record Extensions .................................................................... 41 10.2.15. Record Opening Time ............................................................... 42 10.2.16. Record Sequence Number ......................................................... 42 10.2.17. Record Type .............................................................................. 42 10.2.18. Served IMSI .............................................................................. 42 10.2.19. Served MSISDN ....................................................................... 42 10.2.20. Served PDP Address(WLAN UE remote IP address) .............. 42 10.2.21. Served IMEISV ......................................................................... 42 10.2.22. WLAN Session ID ................................................................... 42

11.

话单的ASN.1描述 ........................................................................................................ 43 11.1. PDG输出WLAN-CDR的ASN.1 定义 .............................................................. 43 12. 编制历史 ......................................................................................................................... 54

II

QB-╳╳-╳╳╳-╳╳╳╳

前 言

本标准的目的是为中国移动通信集团公司设备引进、网络规划、设备制造、工程设计、网络运行、管理和维护等方面提供技术依据。

本标准包括的主要内容包括了设备在功能、性能、接口、操作维护、等方面的要求。

本标准是WLAN与2G/3G网络融合系列标准之一，该系列标准的结构、名称或预计的名称如下：

序号 [1] [2] [3] [4] [5] [6] [7] [8]

标准编号

标准名称

WLAN与2G/3G网络融合总体技术要求 WLAN与2G/3G网络融合PDG设备规范 WLAN与2G/3G网络融合TTG设备规范 WLAN与2G/3G网络融合安全隧道规范 WLAN与2G/3G网络融合计费规范 WLAN与2G/3G网络融合设备接口规范

WLAN与2G/3G网络融合统一认证流程规范（EAP-SIM/AKA）

WLAN与2G/3G网络融合3GPP AAA Server规范

本标准的附录 为标准性附录，附录 为资料性附录。 本标准由中移 号文件印发。

本标准由中国移动通信集团计划部提出，集团公司技术部归口。 本技术规范解释权属于中国移动通信集团公司。 本标准起草单位：中国移动通信研究院。 本标准主要起草人：

III

QB-╳╳-╳╳╳-╳╳╳╳

1. 范围

本标准规定了中国移动I-WLAN系统采用独立PDG架构时计费功能实现的范围，话单产生的方法，适用于中国移动I-WLAN系统核心网技术试验，为设备引进、网络规划与设备制造、工程设计、网络运行、管理和维护等提供技术依据。

2. 规范性引用文件

下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。

3. 术语、定义和缩略语

下列术语、定义和缩略语适用于本标准：

词语

缩略语

解释

4. I-WLAN系统架构概述

I-WLAN系统定义了WLAN和中国移动2G/TD互操作的网络结构、业务流程和接口，从而将WLAN网络与2G/TD网络建立互通，使得终端能够通过WLAN可以访问中国移动的分组域业务。

网络部署时可以采用独立PDG方式或采用TTG+GGSN方式，本规范对这两种方式分别说明。

1

QB-╳╳-╳╳╳-╳╳╳╳

6.3.2.1.

业务解析

PDG为分组数据网关节点，要求能够解决目前移动通讯网络承载的数据业务的接入和转发，同时要求能够根据预先配置在PDG的业务过滤计费规则，对流经PDG的业务数据流能够进行不同协议层次（从三层到七层）的业务分析，业务解析层次可配置从而区分不同数据业务，实现内容计费。

承载层（基于承载或APN，指对业务过滤计费规则有效的APN）

IP协议的第三层（基于源IP地址, 源IP地址掩码, 目的IP地址和目的IP地址掩码） IP协议的第四层（基于协议类型（如TCP/UDP等）、源, 目的端口号），在第四层协议中，应能支持控制面与承载面分离（承载平面由控制平面动态分配）的协议类型（如FTP（passive mode）等）

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（可选）的协议分析能力。 6.3.2.2.

流量统计

要求PDG支持对于数据业务的IP层流量进行统计。

要求PDG支持对于数据业务的应用层流量进行统计（可选）。 6.3.2.3.

内容计费规则配置

在业务解析区分的基础上, PDG根据配置的内容计费规则，对业务数据包进行匹配达到流量区分的目的, 并针对不同业务将区分出的相应流量信息记录在话单中。

为满足今后移动数据业务灵活的计费要求，要求PDG可以同时支持7.3.2.1节中各层次计费要求的任意组合，这些计费要求都可以通过定义计费规则来实现。

1. 内容计费规则描述

当数据包到达PDG后，PDG进行数据拆包分析并匹配内容计费规则，若匹配到计费规则，则进行内容计费，针对业务统计上下行流量。内容计费规则可配置的属性如下：

? APN ? 业务ID

? 源IP地址（可选） ? 源IP地址掩码（可选） ? 目的IP地址 ? 目的IP地址掩码

? 源端口号范围（起始端口号~结束端口号）（可选） ? 目的端口号范围（起始端口号~结束端口号） ? 协议类型（TCP/UDP） ? 七层应用的URL

? 七层应用协议中的特殊字段值（现阶段要求支持x-online-host字段值） ? 优先级（可选）

7

QB-╳╳-╳╳╳-╳╳╳╳

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应支持前置、中置、后置通配符和同时指定多个通配符，如www.isp.com/*, *.isp.com，*.mp3, www.*.com，www.isp.*，*.isp.*等。并且应能将七层应用协议中的特殊字段值（现阶段要求支持x-online-host字段的IP地址）作为过滤规则的属性对数据流进行区分。

在进行七层URL的匹配时对于通配符按以下规定处理：

? ―*‖如用于URL的起始部分（“/‖以前），只代表字符串且不包含“.‖，如“*.monternet.com‖可以用于匹配“news.monternet.com‖；

? ―*‖如用于URL的路径部分（“/‖以后），可代表任何字符，包括“/‖，如“www.monternet.com/*‖可以用于匹配任何以www.monternet.com/开头的URL；

? ―*‖如用于代表文件名或文件格式，如“*.mp3或news.*‖，一般会加URL作为限定，如www.monternet.com/*.mp3可以用于匹配任何以www.monternet.com开头的URL下的mp3格式的文件；

5）优先级：对内容计费规则按人工指定的顺序进行匹配。（可选）

PDG需要支持缺省（default）规则的设置，该计费规则统计所有内容计费规则匹配不成功的数据包流量。

内容计费规则设置中，不同计费规则若存在互包含关系，则必须是真包含关系。被包含的计费规则相对于另一条计费规则称为子集计费规则。PDG应具备规则冲突检测机制，若规则配置中出现违背以上原则的情况需要提示。

2. 内容计费规则配置

要求PDG支持计费规则的静态配置，即所配置的内容计费规则在数据处理流程中规则的属性不发生变化。计费规则配置的更新不需要重启PDG设备。PDG需要考虑未来基于IMS数据业务等的流量统计需要，计费规则需要结合策略机制动态协商配置。

配置管理的功能可以在PDG本地维护终端实现或者集成到现有的网管系统中。

所有的内容计费配置项可以统一进行维护，PDG本地维护终端应该提供稳定可靠，简单易用的图形操作界面。界面中各元素应清晰可读，不具备二义性。在配置界面上，应该能提供详细的在线帮助，可以方便地进行搜索、查询操作。操作人员可以通过图形界面，进行内容计费规则的创建, 添加、修改、编辑等操作。

内容计费数据配置要求： （1）PDG可以配置的三层至七层的计费规则数应当不少于1000个，其中七层计费规则数不少于400个；

（2）PDG可以配置用于内容计费的APN个数应当不少于200个。

8

QB-╳╳-╳╳╳-╳╳╳╳

为了确保内容计费规则配置的正确性，提供带有内容计费能力PDG的公司必须同时提供独立于设备的内容计费规则配置局数据核查软件，简称“局数据核查软件”，局数据核查软件的规范另外提供。 6.3.2.4.

内容计费规则的匹配

PDG对计费规则的匹配和业务数据包的拆包分析结合进行，处理流程如下： 1、PDG分析数据包三/四层属性，获得数据包的目的IP地址和端口号等信息；

2、在包含三/四层属性的计费规则中进行顺序匹配，若匹配到某条规则，且该规则不包含七层属性，则跳转到第6步；

3、PDG分析数据包七层属性，获得数据包的七层URL属性；

4、在包含七层属性的计费规则中进行顺序匹配，若匹配到某条规则，则跳转到第6步；若没有匹配规则，而且规则包含三/四层属性，则在仅包含三/四层属性的计费规则中进行顺序匹配，若匹配到某条规则，则跳转到第6步；

5、将数据流量统计入缺省规则对应的流量； 6、将数据流量统计入匹配规则对应的业务流量。 计费规则的匹配顺序上应遵循以下原则：若两个计费规则之间存在互包含关系，则子集计费规则匹配优先级应高于另一条计费规则。

PDG对于计费规则应具备优先级处理机制，根据计费规则的属性配置，基于上述原则自动确定规则的匹配顺序。

PDG可以对计费规则的优先级项进行人工配置调整匹配的先后顺序。（可选） 6.3.2.5.

内容计费的业务支撑要求

经过PDG的上下行分组数据包按照运营商制定的内容计费规则过滤，依据过滤结果, 在WLAN-CDR的Record Extension域记录其业务类型标识，以方便计费中心识别。在一个承载的会话过程中，移动用户接收／发出属于多个应用的数据包，即使它们都使用同一APN，不同应用的识别号以及相应的上下行数据流量也会在WLAN-CDR的Record Extension参数相应的域中体现。做为未来内容计费的要求, 不同应用的服务质量(QoS)也应加以记录。同一承载中不同应用的计费信息在Record Extension中采取列表方式记录。

对Record Extension字段的具体要求参见本规范的相关章节。

涉及内容计费的承载的计费话单的部分输出, 遵循WLAN-CDR的部分输出原则.

CG对包含有内容计费的WLAN-CDR的合并,可根据运营商的要求, 按照内容类型的不同, 加以合并处理。若同一应用的计费信息合并中存在部分项的数据不同（例如QoS），则计费信息列表方式记录。

要求PDG支持后付费的内容计费，话单产生条件和普通话单产生条件相同。

要求PDG支持热付费的内容计费，话单产生条件和普通话单产生条件相同。热计费话单要求3-10秒内传送到BOSS，时间长度可设置，话单传送接口支持FTP方式。在产生的话单中应当有热计费标志。（可选） 6.3.2.6.

数据业务的内容计费流程

PDG内容计费所支持的业务按业务特点可以分成三类：

9

QB-╳╳-╳╳╳-╳╳╳╳

第一类业务，端口不动态变化，业务需基于URL识别，如HTTP，WAP，MMS，下载类（流媒体下载、KJAVA下载）。内容计费流程如下：

MSPDG1.用户激活请求WAPGW2.用户上线请求3.用户上线请求响应5.握手消息6.Get/Post消息规则匹配，计费开始点CG/BOSSServer4.用户激活请求响应7.业务数据流量采集8.发送话单9.业务结束消息计费结束点

1-4、 UE发起用户激活上线，PDG、WAP GW记录用户信息； 5、用户同业务服务器建立连接；

6、用户发起业务访问，PDG根据计费规则匹配业务，开始计费，统计业务流量信息； 7、用户和业务服务器之间发送业务数据；

8、PDG采集流量，如果满足产生部分话单条件，PDG产生中间话单，话单发送到CG，CG进行预处理后把话单发送到BOSS处理；

9、业务结束，PDG停止该业务流量统计，承载释放后，产生最终话单。

第二类业务，如在线流媒体，从协议上能够区分控制面与数据面，控制面的端口固定，数据面的会话（IP或端口）由控制面协商确定。业务流程如下：

10

QB-╳╳-╳╳╳-╳╳╳╳

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应用等，流程如下：

11

QB-╳╳-╳╳╳-╳╳╳╳

1-4、 UE发起用户激活上线，PDG、WAPGW记录用户信息；

5、用户同业务服务器建立连接，PDG根据3/4层计费规则匹配业务，开始计费； 6、用户和业务服务器之间发送业务数据；

7、PDG采集流量，如果满足产生部分话单条件，PDG产生中间话单，话单发送到CG，CG进行预处理后把话单发送到BOSS处理；

8、业务结束，PDG停止该业务流量统计，承载释放后，产生最终话单。

对于第一类和第二类业务，要求对业务请求之前产生的信令连接包（如TCP握手消息等）能够归并到业务数据对应的计费流量中，如果由于特殊原因仅有信令连接包而无业务请求消息出现，则将这部分信令连接包的流量统一归入一个专门的业务代码表示的流量中；

不同数据业务的内容计费流程参见《中国移动TD-SCDMA系统核心网分组域设备规范_计费分册V1.1.1》。 6.3.2.7.

内容计费对PDG的性能影响

PDG增加内容计费功能后对数据处理性能要求：

1. PDG开启内容计费功能后支持的承载个数应当不少于未开启内容计费功能支持的承载个数的50%；

2. PDG开启内容计费功能后的数据吞吐量应当不少于未开启内容计费功能的数据吞吐量的60％；

3. 开启内容计费功能对PDG数据转发时延的增加小于1ms。

4. PDG经过改造支持内容计费后在未开启内容计费功能的情况下性能应不受影响；

12

QB-╳╳-╳╳╳-╳╳╳╳

6.4. 实时计费（可选）

PDG设备近期应能针对目标用户进行欠费风险控制，从而有效降低欠费，远期应该能够平滑支持实时计费。

详细要求请参见《中国移动分组域欠费风险控制技术规范》。

7. 计费话单产生机制

7.1. 概述

PDG产生WLAN-CDR，并将收集的计费信息通过CGF传送给计费系统。 PDG与CGF应支持及时产生话单（秒级），要求PDG与CGF产生话单的出单参数可灵活配置。 PDG应有内部存储介质用于话单的存储，存储介质的容量建议PDG可保证本计费点所产生的话单至少可保存7天以上。这些存储介质应有充分的热备份设置。

在PDG中可以针对每个计费特性允许或禁止生成话单。如果允许生成话单，可以对每个计费特性定义以下不同的触发条件参数：

? 数据流量门限； ? 时间（时长门限）；

? 计费条件改变的最大数（QoS改变，费率时间改变）。 7.2. PDG话单（WLAN-CDR）产生机制

? 承载建立时，PDG为每个承载创建一个WLAN-CDR话单。

? 如果是基于业务流的话单，则在业务流开始时，为这个业务流创建一个容器，如果

是基于Rating Group的话单，如果这个业务流是该Rating Group的第一个业务流，则为这个业务流创建一个容器。 ? 如果是基于业务流的话单，则业务流终止时，要关闭容器；如果是基于Rating Group

的话单，如果这个业务流是该Rating Group的最后一个业务流，则关闭该业务流的容器。

? 承载结束时，PDG关闭WLAN-CDR话单。 ? 运营商配置的时间门限超时，这个事件可以触发WLAN-CDR关闭，如果此承载仍然处

于激活态，则重新创建一个WLAN-CDR话单。 ? 运营商配置的流量门限超时，这个事件可以触发WLAN-CDR关闭，如果此承载仍然处

于激活态，则重新创建一个WLAN-CDR话单。

? 计费条件变化，例如费率切换，触发容器关闭，如果业务流仍然处于激活态，则创

建一个新容器。

? 运营商配置的容器限制超过限制，则关闭WLAN-CDR，如果此承载仍然处于激活态，

则重新创建一个WLAN-CDR话单。

13

QB-╳╳-╳╳╳-╳╳╳╳

7.2.1. 计费信息追加触发条件

WLAN-CDR的业务流量列表（List of Service Data Volumes）属性由一系列容器组成，在满足表5的特定触发条件时被加入列表中，以记录满足该触发条件的上行和下行流量。

表: 业务流量列表追加计费信息的触发条件

触发条件 费率时段变更 业务流变化 描述 费率时段变更时，应添加一个容器到CDR的业务流量列表。 如果业务流量列表是基于每个业务流的，则业务流结束时需要关闭该容器，如果业务流量列表是基于每个Rating Group的，则当此Rating Group对应的最后一个业务流结束时关闭该容器。 话单关闭 话单关闭时所有激活的业务流量列表容器都应该添加到WLAN-CDR话单中。

7.2.2. 话单关闭触发条件

满足特定触发条件时，WLAN-CDR应被关闭。下表说明应支持哪些条件以允许关闭WLAN-CDR。

表: 关闭WLAN-CDR的触发条件

关闭条件 PDG上的承载结束 描述 承载结束将导致CDR的关闭。触发条件包括： - - 承载终止 其他异常释放。 8. 计费网关对话单的处理

CGF（Charging Gateway Functionality，计费网关功能）提供从PDG节点向运营商的BS传送计费信息的机制。

要求从PDG设备产生话单，到CGF生成BOSS可采集的话单文件的时延小于15分钟。 CG设备应有内部存储介质用于话单的存储，存储介质的容量建议CG应能存储30天以上的话单。这些存储介质应有充分的热备份设置。

要求CG设备可以存储6个月以上的离线话单。 CGF必须提供的功能如下： 1)负责收集PDG的计费数据；

2)对计费数据进行较长时间的保存并进行合并分拣等预处理工作； 3)负责将收集到的PDG的计费数据分别送往计费中心； 另外为了减少CGF与计费中心间的传输量，CGF应该提供一定的部分话单合并功能，以减少送往计费中心的CDR数量。从而减少对计费中心的传输线路的带宽要求以及减轻计费中心的处理负担。

另外，CGF应支持通过开关开启或关闭话单透传功能。

14

QB-╳╳-╳╳╳-╳╳╳╳

8.1. 对PDG话单的处理

CGF通过Wz口接收PDG话单，对PDG话单的处理分为话单采集、原始话单保存、话单预处理、最终话单保存、话单传送到计费中心几个主要过程。

1) 话单采集

采用GTP’协议从PDG采集话单，CGF接收到GTP’帧后，根据序列号判断是否是重复的话单帧号。从而保证话单不重复接收和保存。

2) 原始话单保存

CGF将采集到的正确的话单帧保存到磁盘中，形成原始话单文件记录，可以长期保存该原始话单记录，防止系统重启或者掉电下的话单记录丢失。

3) 话单预处理

CGF将采集到的原始的话单记录进行预处理，包括话单合并、话单分拣等处理。话单合并是根据话单中的关键字将同一个承载的话单合并为一张话单，这些关键字能唯一标志属于同一个承载的话单；话单分拣是将话单中某些特定字段作为条件，根据字段的值将话单分拣到不同的目录存储。

CGF预处理能对各种原因触发关闭的承载话单进行处理。 4) 最终话单保存

CGF将预处理后的话单从内存中转存到磁盘文件中，形成最终话单文件，可以长期保存，防止系统重启或者掉电下的话单记录丢失。

5) 话单传送到计费中心

CGF将形成的最终话单文件按照要求定时的传送到计费中心供计费使用。

CG话单处理流程PDG传输话单话单接收通过Ga口接收来自PDG的话单，CG根据话单帧号对重复帧话单剔重，GTP'协议保证话单无重复，无丢失地被正确接收。原始话单保存将接收后的话单保存到磁盘文件中，形成原始话单文件话单预处理根据需要，将话单进行分拣、合并处理，处理超时和异常终止等各原因终止的PDP话单。最终话单保存将经过预处理后的话单保存到磁盘文件中，形成最终话单文件，并将该文件传输到计费中心。接口计费中心

15

QB-╳╳-╳╳╳-╳╳╳╳

8.1.1. 话单合并

在PDG组网用户激活时，PDG针对每个承载产生话单，并用唯一的C-ID标识。 对于同一个承载，可能对应多个部分话单，需要进行话单合并。 部分话单的合并分两级进行：第一级合并由CGF进行，可以减少CGF与计费中心间的带宽要求以及减轻计费中心的处理负担，由于各种原因，这一级的话单合并可能是不完全的；第二级合并由计费中心进行，主要合并在CGF中未完全合并的话单，从而产生最终的话单。

对于每个承载由PDG负责产生一个唯一的C-ID，根据C-ID+PDG地址，可以确定两张部分话单是否属于同一个承载。

? 合并依据

记录中的PDG地址+C-ID及记录类型是合并的依据。 ? 合并触发方式

PDG定期（在数十秒到数百秒）向CGF发送CDR，合并可以采用事件触发方式和定期合并方式相结合的方法，具体实现方法由厂商确定。

? 合并过程中各字段的处理 1) 无需额外处理的字段 在一个承载中，Record Type、Served IMSI、Served IMEISV、Served MSISDN、Charging ID、PDG Address Used、Serving AAA Server/proxy Address、APN Network Identifier、PDP Type、WLAN UE Remote IP Address、Charging Characteristics、Diagnostics、Charging Characteristics selection mode、Node Id、WLAN Session ID、Record Extensions中的Extension Type和ServiceCode，以上字段保持不变，合并时只需要保留一个。

2) 需要过滤的字段

如果没有发生差错，几个连续的WLAN-CDR具备合并性。对Record Opening Time字段仅保留第一个部分记录的该字段，后续记录的该字段被过滤，对于一批连续部分话单，Duration字段=最后的部分记录的Record Opening Time-最先的部分记录的Record Opening Time+最后的部分记录的Duration字段；对于不连续话单Duration字段累加。

3) 需要拼接的字段 List of Traffic Data字段为一列表，该字段合并实际就是将各列表链接形成一个列表。 对于Local Record Sequence Number字段，合并前是整数类型，合并过程中将这些整数拼成一张列表，在列表首加上本PDG的地址。

对于Record Sequence Number字段，合并前是整数类型，合并过程中将这些整数拼成一张列表，在列表首加上本PDG的地址。

Record Extensions记录的各业务流量需要按照业务类别进行合并。业务编码相同的，上下行流量和Usage Duration各自累加，对于可选的URL字段需要拼接，或是只是记录第一个URL，不管采用哪种方式，都不能超过URL字段的长度限制；业务编码不同的，合并成列表。

4) 需要添加的字段 添加合并结果（ConsolidationResult）标志，如果对一个承载完成合并，置正常（Normal）标志；如果合并过程中发现错误，置不正常（Abnormal）标志。如果合并后的话单中字段列表域的长度超过最长范围，那么置超出门限（ReachLimit）标记。

5) 合并流程

第一步：根据 PDG地址+C-ID将原始话单分类。

16

QB-╳╳-╳╳╳-╳╳╳╳

第二步：话单合并，CDR合并过程中首先看记录的Record Sequence Number是否在Record Sequence Number列表中存在，如果存在则说明是重复话单，予以剔除，回到第二步；否则将该字段加入列表，进入第三步。

第三步：比较Record Opening Time字段，保留小的（先打开的），剔除大的；Duration字段累加；Record Extension字段中的UpVolume 、DownVolume 、和Usage Duration字段累加；List of Traffic Data拼接；Cause for Record Closing字段按优先级顺序保留，优先级由高到低是：承载释放（normalRelease），部分话单（Partial record）。

第四步：每次合并操作后检查Cause for Record Closing字段，如果Cause for Record Closing字段=normalRelease，说明本次会话过程结束，则完成合并过程，转第五步。如果Cause for Record Closing＝maxChangeCond，说明部分话单由于计费条件改变次数达到最大值（Qos改变或者费率时段变更引起），则停止继续合并，转第五步。如果Cause for Record Closing字段原因是Partial record（如timelimit或volumelimit），说明还有后续记录，需要继续合并，转第二步。

第五步：如果合并完成（即Cause for Record Closing字段=normalRelease或者记录量达到门限），检查相同PDG地址+C-ID 下所有话单的Record Sequence Number列表，检查累加记录数=最大序号是否满足，如满足置所有话单的ConsolidationResult =Normal，如不满足置ConsolidationResult =Abnormal；如果是因为达到记录量的原因无法再合并，则置ConsolidationResult =ReachLimit。

第六步：如ConsolidationResult =Normal，CGF可以将该记录发往BS；如ConsolidationResult =Abnormal，则说明中间有部分话单丢失，转第二步继续合并，如在规定时间内仍然未能达到ConsolidationResult =Normal，则CGF保留该字段为Abnormal，可以将该CDR送往BS，如果以后再有该次会话的部分记录到来CGF将之送到BS并由BS的预处理部分试图合并。

8.1.2. PDG与主CGF间的通信发生故障的情况

当PDG与主CGF间的通信发生故障，CDR将被传送给备CGF，这种情况下，主CGF与备CGF都无法完成完成的合并，需要BOSS做后续的合并。

17

QB-╳╳-╳╳╳-╳╳╳╳

9. 计费采集接口和协议

9.1. PDG-CGF的协议栈

9.2. 承载协议

可以用UDP或TCP协议来承载GTP’协议，当采用UDP协议时，UDP的目的端口号定为3386，即GTP’协议的端口号，也可以配置定义其它端口号。UDP的源端口号由发端分配。一旦端口号确定下来，收端的源端口号采用发端的目的端口号，收端的目的端口号采用发端的源端口号。

如果采用TCP协议，端口分配情况与UDP一样。 9.3. 计费节点的原则

对支持GTP’的PDG节点，若该节点不能识别另一节点，应能相互发送信息：‖Service/Version not supported‖。

每个PDG都可以配置一个CGF列表，列表中定义各CGF的优先等级，如果主CGF退出服务（出现故障或负荷太重），那么PDG将把CDR送下一级的CGF，以此类推。

PDG原则上只能将CDR送到位于同一PLMN中的CGF，而不能送到不同PLMN的CGF中。 9.4. GTP’计费通信协议

GTP’采用GTP的协议框架，但仅采用GTP协议的信令平面。消息内容部分详见3GPP TS 29.060. 1）GTP消息头

下图表示了GTP’协议头的格式： Bits Octets 8 7

6 5 4 3 2 1

18

QB-╳╳-╳╳╳-╳╳╳╳

1 2 3 - 4 5 - 6

Version Message Type Length Sequence Number 图8-4 GTP’协议头的格式

以下为各个单元的说明： PT为‖0‖，表示是GTP’消息；

Version指GTP’的版本，建议为GTP’ V1； 第一位‖0‖在GTP’中未用； Message Type表示消息类型；

Length表示消息的长度，但不包括信头本身的长度； Sequence Number对于信令消息来说是会话的标识。

2）GTP消息体

Bits Octets1087654321PT Spare ― 1 1 1 ― ― 0 ― Type -> TV format Bits Octets1187654321Type -> TLV format

图8-5 GTP消息体

消息体说明：

信令消息可包含多个参数。

参数种类有TLV（Type，Length，Value）和TV（Type，Value）两种。

TLV参数由类型、长度、参数值三部分构成，其中类型占一个字节，长度占二个字节，长度值指示参数值的字节数。

TV参数由类型、参数值二部分构成，其中类型占一个字节，参数值根据类型而定。 TV的Type最高比特置为0，TLV的Type最高比特置为1。 9.5. GTP’消息

9.5.1. GTP’消息

GTP’在GTP协议的基础上增加了两类信令消息： 通路管理消息：

Node Alive Request（MTV=4）， Node Alive Response（MTV=5），

19

QB-╳╳-╳╳╳-╳╳╳╳

Redirection Request（MTV=6）， Redirection Response（MTV=7） 记录传输消息：

Data Record Transfer Request（MTV=240）， Data Record Transfer Response（MTV=241）

GTP’在GTP协议的基础上增加了消息单元，其编号情况如下： （保留字段填任意值，今后扩展用）

参数定义分为：117-127 (TV 信息) and 239-254 (for TLV type fields)

TLV 参数的说明:

254 Address of Recommended Node 253 Requests Responded 252 Data Record Packet

251 Charging Gateway Address (this IE is also used in 3GPP TS 29.060) 250 Sequence Numbers of Cancelled Packets 249 Sequence Numbers of Released Packets TV 参数的说明:

127 Charging ID

126 Packet Transfer Command 增加的原因码（Cause Codes）： request 类消息的原因码范围是 49–-63，acceptance 类响应消息的原因码范围是177—191，rejection 类响应消息的原因码范围是241—255。

GTP’在GTP协议的基础上增加的原因码如下：

Request 类消息：

63 This node is about to go down 62 Another node is about to go down

61 The receive buffers are becoming full 60 The transmit buffers are becoming full 59 System failure acceptance 类消息： 177 CDR decoding error rejection 类响应消息： 255 Request not fulfilled

254 Sequence numbers of released/cancelled packets IE incorrect 253 Request already fulfilled

252 Request related to possibly duplicated packets already fulfilled

表8-1计费相关的GTP’消息

Message Type value (Decimal) GTP' message 20

QB-╳╳-╳╳╳-╳╳╳╳

1 2 3 4 5 6 7 240 241 others

9.5.2. GTP’中直接使用GTP消息

以下为GTP协议中规定的GTP’中仍然使用的消息：

1、Echo Request和Echo Response用于检测节点是否处于工作状态。

如果采用TCP承载协议，则Echo Request和Echo Response消息可以不采用。 2、Version Not Supported消息的用法没有变化，在该消息中应携带最新能够支持的GTP’协议。

注Version Not Supported消息的值：

在1998年10月制定的GSM 12.15 v.7.0.0其GTP’版本号为0（用二进制000来表示）， 在1999年12月制定的GSM 12.15 v.7.3.0其GTP’版本号为1（用二进制001来表示）， 在2000年6月制定的GSM 12.15 v.7.5.0其GTP’版本号为2（用二进制010来表示）。 9.5.3. GTP’中修改使用GTP消息

GTP’中在以下情况时修改使用的GTP的消息如下所述： 建立承载时：Charging ID，Charging Gateway Address 更新承载时：Charging ID，Charging Gateway Address 建立AA 承载时：Charging ID，Charging Gateway Address （详见3GPP TS 29.060）

Echo Request Echo Response Version Not Supported Node Alive Request Node Alive Response Redirection Request Redirection Response Data Record Transfer Request Data Record Transfer Response reserved for future use 21

QB-╳╳-╳╳╳-╳╳╳╳

9.5.4. GTP’消息类型

9.5.4.1. Node Alive Request

当节点从不可用状态转到可用状态时，可以用Node Alive Request消息通知对端。如果采用TCP作通路协议，该消息可以不用。

Node Alive Request较Echo Request快速，当Node Alive Request消息和Echo Request同时使用时，可以加大Echo Request的发送间隔，这样减轻网络负荷。

表8-2 Node Alive Request消息参数

参数（IE） Node Address Private Extension

9.5.4.2.

Node Alive Response

必备（M）/ 任选（O） M O Node Alive Response用于对Node Alive Request的响应。

表8-3 Node Alive Response消息参数 参数（IE） Private Extension 9.5.4.3.

Redirection Request

必备（M）/ 任选（O） O 当CGF不能继续正常工作或者CGF与后面的系统（如BS）失去联系时，CGF发Redirection Request消息给PDG，指示PDG将CDR发送到其它CGF。

注：指示的CGF必须是位于同一个PLMN之内的，而不能是位于其它PLMN的CGF。

表8-4Redirection Request消息参数 参数（IE） Cause Address of Recommended Node Private Extension 必备（M）/ 任选（O） M O O

原因码定义：

1 This node is about to go down 2 Another node is about to go down 3 System failure

4 Receive buffers becoming full 5 Send buffers becoming full

22

QB-╳╳-╳╳╳-╳╳╳╳

CGF的地址消息有两种格式：IPv4 、 IPv6（见下图）

Bits Octets12-387654321Type = 254 (Decimal)Length = 4 (Decimal)IPv4 Address

4-7

图8-6 CGF的IPV4地址格式

Bits Octets12-34-1987654321Type = 254 (Decimal)Length = 16 (Decimal)IPv6 Address

图8-7 CGF的IPV6地址格式

9.5.4.4.

Redirection Response

Redirection Response作为对Redirection Request的响应。

表8-5 RedirectionResponse消息参数 参数（IE） Cause Private Extension 原因码定义：

1 Request Accepted

2 No resources available 3 Service not supported 4 System failure

5 Mandatory IE incorrect 6 Mandatory IE missing 7 Optional IE incorrect 8 Invalid message format 9 Version not supported

必备（M）/ 任选（O） M O 23

QB-╳╳-╳╳╳-╳╳╳╳

9.5.4.5.

Data Record Transfer Request

1、背景介绍

正常情况的GTP’通信过程为：PDG向CGF发送数据包，CGF返回响应‖Request Accepted‖。 冗余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将向管理平台发告警，管理平台进行后续处理

24

QB-╳╳-╳╳╳-╳╳╳╳

图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发送测试包（带有消息：‖Send possibly duplicated Data Record Packet‖，并和先前的包有相同的序列号），若主CGF返回响应‖Request Accepted‖，PDG将通知次CGF提交CDR并发送到计费系统；若主CGF返回响应‖ Request related to possibly duplicated packets already fulfilled ―，PDG将通知次CGF取消CDR处理。

为避免PDG异常时（序列号缓冲坏或重包）CDR一直驻留在CGF中，须通过清理CGF缓冲的方法。

25

QB-╳╳-╳╳╳-╳╳╳╳

为了避免以下情况：直到CDR的最后一个序列号产生，PDG的备份缓冲一直都不能正常使用。必须有可配置的参数去控制CGF决定是否将CDR发送到计费系统。使操作员可进行以下操作：

通过配置可以使PDG和CGF进行排除重单，计费系统不必排除CGF冗余引起的重单。 通过配置可以使计费系统进行排除重单。为更有效地排除重单，CGF可以在可能的重单后加标记（该标记不应出现在PDG为计费系统提供的内容中）（也可以用特殊的文件名进行标识）。尽管重单有标记，计费系统也会多一些额外的工作。同时，CGF可以不管是否可能有重单，直接将CDR发送到计费系统，CGF也可以有配置参数决定以下消息是否有效：Data Record Packet Cancel/Release

2、Data Record Transfer Request消息

本消息用于传送CDR信息，CDR放在Data Record参数中。

表8-6 Data Record Transfer Request消息参数 参数（IE） Packet Transfer Command Data Record Packet Sequence Number of Released Packets Sequence Number of Cancelled Packets Private Extension

3、Packet Transfer Command参数

Packet Transfer Command参数意义如下： 1）Send Data Record Packet

2）Send possibly duplicated Data Record Packet 3）Cancel Data Record Packet 4）Release Data Record Packet

详细说明如下：

Send Data Record Packet消息用于正常CDR的传送，这种情况下带Data Record Packet参数。

Send possibly duplicated Data Record Packet消息用于将CDR传向备用CGF，这种情况下带Data Record Packet参数。

Cancel Data Record Packet消息带Sequence Number of Cancelled Packets参数。 Release Data Record Packet消息带Sequence Number of Released Packets参数。

Data Record Transfer Command参数结构如图所示：

字节 1 2

比 特

8 7 6 5 4 3 2 1 Type=126（十进制） Packet Transfer Command 图8-9 Packet Transfer Command消息参数

26

必备（M）/ 任选（O）/ 特定条件必须（C） M C C C O

QB-╳╳-╳╳╳-╳╳╳╳

4、Data Record Packet 参数

当Packet Transfer Command为‖Send Data Record Packet‖或‖Send possibly duplicated Data Record Packet‖时，Data Record Packet出现在消息体中。

Data Record Packet的内容如下图所示：

Bits Octets876543211Type = 252 (Decimal)2...3Length4Number of Data Records 5Data Record Format6...7Data Record Format Version8...9Length of Data Record 110...nData Record 1x...x+1Length of Data Record NData Record N

x+2...y 图8-10 Data Record Packet消息参数

说明：

若无数据，该单元应只包含Type（‖252‖）和Length（‖0‖）。

有2个CDR标识单元：Data Record Format 和Data Record Format Version。Data Record Format标识CDR的格式是ASN.1或其它格式

Data Record Format Version标识CDR的版本（release 和 version） 5、Released Packets 参数的序列号

比 特

字节 8 7 6 5 4 3 2 1 1 Type=249（十进制） 2…3 Length 4…5 Sequence Number 1

n…n+1 Sequence Number N 图8-11 Released Packets消息参数

6、Cancelled Packets 参数的序列号

27

QB-╳╳-╳╳╳-╳╳╳╳

字节 1 2…3 4…5

比 特

8 7 6 5 4 3 2 1 Type=250（十进制） Length Sequence Number 1 n…n+1 Sequence Number N 图8-12 Canceled Packets消息参数 7、Private Extension 参数

Private Extension 包含了用户或运营商的特殊信息。 11.6.4.6 Data Record Transfer Response

该消息用于对Data Record Transfer Request的响应。一个Data Record Transfer Response可以完成对多个Data Record Transfer Request的响应。

表8-7 Data Record TransferResponse消息参数 参数（IE） Cause Requests Responded Private Extension

原因码定义：

1 Request Accepted

2 No resources available 3 Service not supported 4 System failure

5 Mandatory IE incorrect 6 Mandatory IE missing 7 Optional IE incorrect 8 Invalid message format 9 Version not supported 10 Request not fulfilled 11 CDR decoding error

12 Request already fulfilled

13 Request related to possibly duplicated packet already fulfilled 原因码‖CDR decoding error‖为可选，用来通知PDG不能解析它的CDR。 Data Record Transfer Response涉及的参数如图所示：

比 特

字节 1 2…3 4…5

8 7 6 5 4 3 2 1 Type=253（十进制） Length Sequence Number 1 必备（M）/ 任选（O）/ 特定条件必须（C） M M O 28

QB-╳╳-╳╳╳-╳╳╳╳

n…n+1 Sequence Number N 图8-12 Requests Responded消息参数

Private Extension 包含了用户或运营商的特殊信息。

若产生的原因码级别高或出现频率高，PDG可以选择另一个CGF。 9.5.5. 重复话单传送的防止

以下例子说明了3种Data Record Transfer Request/Response情况： 正常情况CDR的传送

PDG发送CDR到CGF成功并接收到正确响应，不需作重发处理。 CDR未正确接收前PDG-CGF1之间的连接中断 发送CDR已失败，且未接收到CGF响应。

CDR已经正确接收后PDG-CGF1之间链路中断。

CGF已接收CDR成功，但发送接收成功响应时和PDG通信中断。 以下为这3种情况的处理流程： 9.5.5.1.

正常情况CDR的传送

以下为处理顺序图：

PDG 1. Data Record Transfer Request: Send Data Record Packet 3. Data Record Transfer Response: Request Accepted 2. CDRs are stored in a secure way CGF’s volatile memory Non-volatile CGF memory 4. < Succesfully sent CDRs are deleted from the GSN buffers > . . . . . .

图8-13正常情况CDR的传送处理顺序图

以下为对各个处理的说明：

1) PDG发送CDR到CGF，发送的相应的消息为‖Send Data Record Packet‖。 2) CGF处理消息，并存储CDR到本地。

29

QB-╳╳-╳╳╳-╳╳╳╳

3) CGF发送响应消息到PDG ，消息内容为‖Request Accepted‖ 4) PDG接收消息‖Request Accepted‖后，从缓冲内删除该CDR

GTP’接收响应时失败，会在额定时间内和达到设定次数前重新发送请求。 9.5.5.2.

CDR未正确接收前PDG-CGF1之间的连接中断

以下为处理顺序图：

PDG CGF1 CGF2 CDR postprocessing 1. Data Record Transfer Request: Send Data Record Packet 2. < CDRs not stored to non-volatile memory nor sent to postprocessing > 3. < No positive response to GSN even to resent requests > 4. Data Record Transfer Request: Send possibly duplicated Data Record Packet 5. < CGF2 stores the CDR packet contents to its buffer for pot. dupl. packets > 7. < CDRs are deleted from GSN buffers > 6. Data Record Transfer Response: Request Accepted . . . 8. Node Alive Request 9. Node Alive Response: Request Accepted 10. Data Record Transfer Request: Send possibly duplicated Data Record Packet (empty) 11. Data Record Transfer Response: Request Accepted 12. Data Record Transfer Request: Release Data Record Packet 13. CDRs 14. Data Record Transfer Response: Request Accepted . . . . . .

图8-14 CDR未正确接收前PDG-CGF1之间的连接中断时的处理顺序图 以下为对各个处理的说明： 1） PDG向CGF1（主用CGF）发Data Record Transfer Request消息，其中Packet Transfer Command参数是Send Data Record Packet。

2） 因为PDG与CGF1之间失去联系，CGF1没有将CDR安全保存。

3） PDG无法收到响应或者收到‖No resources available‖之类的拒绝响应。

30

QB-╳╳-╳╳╳-╳╳╳╳

4） PDG检测与备用CGF2之间的链路（用Echo Request），如果正常则PDG将与送往CGF1相同的CDR送往CGF2，使用Data Record Transfer Request消息，Packet Transfer Command参数是Send possible duplicated Data Record Packet。

5） CGF2处理接收到的CDR，因为该分组被标识为possible duplicated，虽然CGF2保存该分组，但是不立刻送往BS。

6） CGF2送正确接收确认信息给PDG，采用Data Record Transfer Response消息，Cause参数置为Request Accepted。

7） PDG可以将成功发送的CDR（但可能重复）删除，但是仍然保留该分组的序列号（Sequence Number）。

8） CGF1恢复以后，向PDG送Node Alive Request消息，PDG知道又可以与CGF进行通信。 9） PDG采用Node Alive Response消息确认。

10） 对于前面未得到确认的Data Record Transfer Request消息，PDG向CGF1发送空的测试分组，空分组仅仅是Data Record Packet参数中不包含CDR负载，其它都一样。

11） CGF1以Data Record Transfer Response消息响应，Cause参数置为Request Accepted。因为在CGF1保存CDR之前，CGF1已经与PDG失去联系，所以对于测试分组它认为是新的分组予以接受。

12） PDG知道CGF1并未处理测试分组对应的原分组，通知CGF2可以将该CDR送给BS，采用的消息是Data Record Transfer Request，Packet Transfer Command参数是Release Data Record Packet。该分组的序列号在Sequence Numbers of the Released Packets参数中指示。

13） CGF2可以将CDR传向BS。

14） CGF2向PDG发Data Record Transfer Response消息，Cause参数置为Request Accepted。

处理完毕, PDG可以处理后来的CDR。 9.5.5.3.

CDR已经正确接收后PDG-CGF1之间链路中断

以下为处理顺序图：

31

QB-╳╳-╳╳╳-╳╳╳╳

PDG CGF1 CGF2 CDR postprocessing 1. Data Record Transfer Request: Send Data Record Packet < 2. CDR packet contents is stored to non-volatile CGF1 memory or sent for postprocessing > 3. < No positive response to GSN, even to resent requests > 4. Data Record Transfer Request: Send possibly duplicated Data Record Packet 5. < CGF2 stores the CDR packet contents to its buffer for pot. dupl. packets > 6. Data Record Transfer Response: Request Accepted 7. < CDRs are deleted from GSN buffers > . . . 8. Node Alive Request 9. Node Alive Response 10. Data Record Transfer Request: Send possibly duplicated Data Record Packet (empty) 11. Data Record Transfer Response: Request related to possibly duplicated packets already fulfilled 12. Data Record Transfer Request: Cancel Data Record Packet 13. 14. Data Record Transfer Response: Request Accepted . . . . . .

图8-15 CDR已经正确接收后PDG-CGF1之间链路中断的处理顺序图

以下为对各个处理的说明：

1）PDG向CGF1（主用CGF）发Data Record Transfer Request消息，Packet Transfer Command参数是Send Data Record Packet。

2）CGF1将CDR安全保存。

3）PDG与CGF1之间通信中断，PDG无法收到Cause参数置为Request Accepted的Data Record Transfer Response消息响应，

4） PDG检测与备用CGF2之间的链路（用Echo Request），如果正常则PDG将与送往CGF1相同的CDR送往CGF2，使用Data Record Transfer Request消息，Packet Transfer Command参数是Send possible duplicated Data Record Packet。

5） CGF2处理接收到的CDR，因为该分组被标识为possible duplicated，虽然CGF2保存该分组，但是不立刻送往BS。

32

QB-╳╳-╳╳╳-╳╳╳╳

6）CGF2送正确接收确认信息给PDG，采用Data Record Transfer Response消息，Cause参数置为Request Accepted。

7） PDG可以将成功发送的CDR（但可能重复）删除，但是仍然保留该分组的序列号（Sequence Number）。

8） CGF1恢复以后，向PDG送Node Alive Request消息，PDG知道又可以与CGF进行通信。 9）PDG采用Node Alive Response消息确认

10）对于前面未得到确认的Data Record Transfer Request消息，PDG向CGF1发送空的测试分组，空分组仅仅是Data Record Packet参数中不包含CDR负载，其它都一样。

11）CGF1以Data Record Transfer Response消息响应，Cause参数置为Request related to possibly duplicated packets already fulfilled。因为在CGF1与PDG失去联系之前，CGF1已经保存CDR，所以对于测试它告知PDG该可能重复分组已经正确传送。

12）PDG知道CGF1已经处理完测试分组对应的原分组，通知CGF2取消该CDR，采用的消息是Data Record Transfer Request，Packet Transfer Command参数是Cancel Data Record Packet。该分组的序列号在Sequence Numbers of the Cancelled Packets参数中指示。

13）CGF2删除该CDR。

14）CGF2向PDG发Data Record Transfer Response消息，Cause参数置为Request Accepted。

处理完毕, PDG可以处理后来的CDR。

9.5.6. 备份方式对话单合并的影响

CGF采用备份工作方式是非常必要的，此处论述了如何解决备份工作方式可能带来的重单，备份工作方式也会造成CDR分布在不同的CGF中，这会对话单合并带来一定的影响，如果一次承载涉及两个CGF，其情况阐述如下：

PDG向CGF1（主用CGF）发送话单，如果CGF1不能继续接收话单，则CGF1向PDG发送Redirection Request消息，消息中携带Address of Recommended Node参数，该参数指示了下面PDG可以传送的CGF地址。

CGF1发出Redirection Request消息的原因有多种，有可能CGF1不能继续工作，但是对于CGF1已经接收的话单是不能丢失的。当CGF1恢复后，仍然执行话单合并的工作。

PDG继续向CGF2发送话单，CGF2完成剩余话单的合并。 因为重定向的CGF2必须与CGF1位于同一BS中，因此由BS的预处理部分完成剩余的合并工作。

9.6. GTP的记录格式

从PDG发送到CGF的CDR格式：

（参见‖Data Record Packet参数‖图中的第5个8位位组） ? 由8字节组成

? 值域为1-255的十进制数 ? 标准中只使用1-10和51-255 ? 11-50为运营商使用

? 值‖1‖说明使用ASN.1格式，其它情况见下节

33

QB-╳╳-╳╳╳-╳╳╳╳

9.6.1. 标准记录格式

对由TS决定的PS域的CDR只能是ASN.1格式，‖Data Record Format‖的值为‖1‖。参见话单结构和ASN.1语言描述部分。 9.6.2. 私有记录格式

私有记录格式取值范围使用11...50（Data Record Format）。 9.7. 记录格式版本

―Data Record Format Version‖（位于Data Record Packet的第6-7个8位位组）描述了CDR的版本（其结构见如图所示）。

说明：

若为计费作用，话单的Application为‖1‖（十进制）；其它作用，Application为其它值。

Release定义如下： ? R98 ：‖2‖ ? R99 ：‖3‖ ? R4 ：‖4‖ Version的定义： ? R98 ：‖1‖

? R99、R4：如下表所示

表8-8 R99、R4的版本号 Value 1 2 R99 TS 32.015 v3.0.0 TS 32.015 v3.1.0 R4 TS 32.215 v4.0.0 TS 32.215 v4.1.0 Data Record Packet BitsIE 87654321Octet Application Identifier Release Identifier Octets67Version Identifier 图1： Data Record Format Version格式

34

QB-╳╳-╳╳╳-╳╳╳╳

3 4 5 6 7 8 9 TS 32.015 v3.1.1 TS 32.015 v3.2.0 TS 32.015 v3.3.0 TS 32.015 v3.4.0 TS 32.015 v3.5.0 TS 32.015 v3.6.0 TS 32.015 v3.7.0 9.8. FTP协议（Bw接口）

CGF与BS之间采用文件传输协议FTP将话单文件传输到BS，CGF可以支持PUSH和PULL两种传输模式。使用PUSH模式时，CGF作为FTP的客户端主动将话单文件定时传送到FTP的服务器端BS；使用PULL模式时，CGF作为FTP的服务器端，BS作为FTP客户端定时到CGF上取话单文件。

10. 话单类型

10.1. 类型列表

10.1.1. PDG话单

PDG支持产生WLAN-CDR话单，因3GPP TS 32.252协议仅定义了WLAN-CDR的内容，但并未明确定义话单中各参数具体编码，因此在WLAN-CDR中，复用G-CDR中的参数定义，以完成I-WLAN系统的计费功能，复用关系详见下表说明部分。

35

QB-╳╳-╳╳╳-╳╳╳╳

Table 7 : Wz 接口话单内容 (WLAN-CDR)

Field Record Type Category M Description WLAN PDG record. 说明 G-CDR 中有此参数定义，但标准未定义WLAN Record Type取值，暂定为201 Served IMSI Served MSISDN Served IMEISV Oc M OM IMSI of the served party. The primary MSISDN of the subscriber. The IMEISV of the ME, if available. PDG Address used Node ID Serving WAG Address WAG PLMN Identifier Serving AAA Server/proxy Address WLAN UE remote IP address WLAN UE Local IP address Charging ID M PDG identifier used to correlate WLAN AN generated information to PDG generated information WLAN session id M WLAN session identifier used to correlate WLAN AN generated information to PDG generated information Access Point Name Network Identifier Charging Characteristics Charging Characteristics Selection Mode OM M OM The logical name of the connected access point to the external packet data network (network identifier part of APN). The Charging Characteristics applied G-CDR 中有此参数定义 to the PDP context. Holds information about how Charging Characteristics were selected. G-CDR 中有此参数定义 G-CDR 中有此参数定义 G-CDR 中没有该参数，重新定义一个，标识暂定51 G-CDR 中有此参数定义 OC WLAN UE Local IP address 未看到实际意义，建议暂不支持 OC WLAN UE remote IP address 复用G-CDR 中的servedPDPAddress定义 M OM OM M Name of the recording entity. Serving WAG address used during this record. WAG PLMN Identifier (MCC and MNC) used during this record. Serving AAA Server/Proxy address. G-CDR 中有此参数定义 网络中不部署独立WAG，不使用此字段 网络中不部署独立WAG，不使用此字段 复用G-CDR 中的sgsnAddress定义 M IP address of the PDG used. 复用G-CDR 中的ggsnAddress定义 G-CDR 中有此参数定义 G-CDR 中有此参数定义 G-CDR 中有此参数定义 36

QB-╳╳-╳╳╳-╳╳╳╳

Field Record Opening Time Category M Description is activated in this PDG? or record opening time on subsequent partial records. Duration Cause for Record Closing Record Sequence Number Local Record Sequence Number Diagnostics PDP Type List of Traffic Data Volumes OM OM OM OM Consecutive record number created G-CDR 中有此参数定义 by this node. The number is allocated sequentially including all CDR types. A more detailed reason for the release G-CDR 中有此参数定义 of the connection. PDP type, i.e. IPv4, IPv6, or IHOSS:OSP A list of changes in charging conditions for this IP CAN bearer, each change is time stamped. Charging conditions are used to categorize traffic volumes, such as per tariff period. Initial and subsequently changed QoS and corresponding data volumes are also listed. Record Extensions OC A set of network operator/manufacturer specific extensions to the record. Conditioned upon the existence of an extension. G-CDR 中有此参数定义 G-CDR 中有此参数定义 G-CDR 中有此参数定义 C M M Duration of this record in the PDG. from this PDG. Partial record sequence number, only G-CDR 中有此参数定义 present in case of partial records. G-CDR 中有此参数定义 说明 Time stamp when End-to-end Tunnel G-CDR 中有此参数定义 The reason for the release of record G-CDR 中有此参数定义 10.2.

话单参数描述

10.2.1. Access Point Name (APN) Network/Operator Identifier

这些字段包含了由手机、PDG决定的实际连接的APN网络/运营商的标识。APN也可以是一个通配符，由PDG来选择APN。

APN网络标识包含不只一个标签，与互联网的域名对应。APN运营商标识由三个标签组成。第一和第二个标签共同组成特定的GPRS PLMN标识(如\name>..gprs\。 有关APN的格式及接入点的的选择方法的更多信息，请参考3GPP TS 23.003 and 3GPP TS 23.060。

37

QB-╳╳-╳╳╳-╳╳╳╳

10.2.2. Cause for Record Closing

这个字段包含了话单关闭的原因，包括以下内容：

正常释放：承载释放。

部分话单产生：达到数据流量上限，时间(持续时间)上限或达到变化条件的最大值。 非正常中断(承载)；

没有被授权的网络发起的定位业务请求； 没有被授权的用户端发起的定位业务请求； 定位业务执行时定位方式发生错误；

定位业务请求时未知的或未达到定位系统的用户； 管理介入(出于 O&M 原因)

更详尽的原因有可能在诊断字段中找到。

10.2.3. Charging Characteristics

下图中定义的计费特性字段允许运营商给CDR应用不同的计费方法。计费特性参数的格式如下图，Px (x=0?3),表示计费特性的取值，“B”字段可由运营商自行定义。

图9计费特性标志

WLAN-CDR的计费特性与PDG 的承载的\相对应。 10.2.4. Charging Characteristics Selection Mode

这个字段表示WLAN-CDR中的计费特性类型。

在PDG中，它的取值可为： ? Home default ? Visiting default ? Roaming default ? SGSN supplied 10.2.5. Charging ID

这个字段是计费标识，可以与PDG地址一起使用来识别一个承载产生的所有话单记录。 Charging ID 在承载被激活时由PDG 产生并且包含在话单中。

38

QB-╳╳-╳╳╳-╳╳╳╳

不同的PDG独立地产生自己的 Charging ID, 并且可能产生相同的数字。CGF 或计费系统通过 Charging ID 及PDG地址来检查唯一性，如果有必要(通过 Charging ID 及PDG地址仍不明确)，再根据话单的产生时间来判断。 10.2.6. Diagnostics

这个字段包括了连接释放的更具体的技术原因，可参考3GPP TS 32.205。

3GPP TS 24.008 中定义的原因.

诊断消息还可被扩充，以便包含厂家及网络的特定信息。 10.2.7. Duration

这个字段包含了该承载(WLAN-CDR)的以秒为单位的时长。 对于部分话单，时长是指单个部分话单的时长而不是累计的时长。

内部的时间测量可能是以十分之一秒甚至毫秒表示的，因此，时长的计算可能出现取整情况。由于以下限制：

1) 如果所传送的数据流量比零大，允许接受零秒话单 2) 对于所有话单，应采用同样的取整方法 取整方式，本文件不予规定。 10.2.8. GGSN Address/GGSN Address Used(PDG Address used)

这些字段是指当前控制层所使用的PDG 的IP地址。 10.2.9. SGSN Address(Serving AAA Server/proxy Address)

WLAN-CDR字段中包含当前的PDG及记录中与之连接3GPP AAA Server的地址。 10.2.10.

List of Traffic Data Volumes

这个列表包括了一个或多个容器（container），每个容器中包括以下字段：

上行数据流量、下行数据流量、变化条件和时间戳。 数据流量包括了使用分组业务过程中所传送的字节数。

变化条件定义了容器关闭的原因，如费率时间改变、QoS改变或CDR关闭。变化时间是一个时间戳，它定义了新的流量开始记录或CDR关闭的时刻。所有的激活的承载没有必要因为某费率变化拥有完全一致的时间戳。

第一个容器包括以下可选字段：申请的QoS(不在WLAN-CDR中)及协商后的QoS。在后面的容器中如果前一个变化条件是“QoS change”，协商的QoS将被使用。如果变化条件是 “QoS change” ，并且 QoS 变化是由手机通过承载修改进程发起的，那么除协商的 QoS参数以外，申请的 QoS参数也要在后面的容器中表示出来。

39

QB-╳╳-╳╳╳-╳╳╳╳

以下是一个列表的例子，其中有3个容器，是由于一次QoS变化及一次费率变化产生。

表9-8话务数据流量列表举例 QoS Requested = QoS1 QoS Negotiated = QoS1 Data Volume Uplink = 1 Data Volume Downlink = 2 QoS Negotiated = QoS2 Data Volume Uplink = 5 Data Volume Downlink = 6 Data Volume Uplink = 3 Data Volume Downlink = 4 Change Condition = QoS change Change Condition = Tariff change Change Condition = Record closed Time Stamp = TIME1 Time Stamp = TIME2 Time Stamp = TIME3 第一个容器包括初始的 QoS值和与之相应的流量统计。第二个容器包括费率时间变换前新的 QoS值和与之相应的流量统计。最后的容器包括费率时间变换后的流量统计。以下分项列出了总的流量统计(费率时间变换前使用费率1，变换后使用费率2)

表9-9 QoS值和流量统计 QoS1+Tariff1 QoS2+Tariff1 QoS2+Tariff2 QoS1 QoS2 Tariff1 Tariff2 uplink = 1, downlink = 2 uplink = 5, downlink = 6 uplink = 3, downlink = 4 uplink = 1, downlink = 2 uplink = 8, downlink = 10 uplink = 6, downlink = 8 uplink = 3, downlink = 4 Container 1 2 3 1 2+3 1+2 3

PDG中统计的数据流量应该是隧道层上所传IP载荷的数据流量。所以该数据流量已经包含了IP承载协议，就是IP、TCP或UDP的包头。 10.2.11.

Local Record Sequence Number

这个字段包括了由该节点生成的唯一的记录号码。号码在一个节点中是唯一的，由 Node ID 字段或节点地址 (PDG地址、记录实体)来识别。这个字段可以用在后处理系统中， 比如识别丢失的记录。

40

QB-╳╳-╳╳╳-╳╳╳╳

10.2.12.

Node ID

这个字段包含由CDR产生的，可由运营商可选配置的节点识别字符串。 10.2.13.

PDP Type

这个字段定义了PDP类型，如 IP, PPP, 或 IHOSS:OSP (对于准确的格式参考 3GPP TS 29.060) PDP Type取值 0121 0157 0001 0002 含义 IPv4 Ipv6 PPP OSP:IHOSS 10.2.14.

Record Extensions

这个字段可以让网络运营商或厂商在标准的话单上添加自己推荐的内容。

在PDG支持内容计费时， 厂商的PDG设备应把网络侧产生的内容计费的信息填充到WLAN-CDR的该项参数中, 经过厂商的CG处理后, WLAN-CDR中的该参数应采用列表的方式填写业务类别代码和相应的上下行业务流量等属性。

表9-10 WLAN-CDR的Record Extensions 字段内容计费的字段定义

字段名 extensionType 数据类型 Unsigned char 描述 扩展字段类型，取值如下： 1：内容计费 其它：预留 Length ServiceCode1 UplinkVolume Downlink Volume Usage Duration URL contentInfo … ServiceCodeN UplinkVolume Downlink volume Usage Duration URL Int Int Int Int Int String … Int Int Int Int String 扩展字段的长度 业务编码1 此业务的上行数据流量（单位：字节） 此业务的下行数据流量（单位：字节） 业务有效使用时长 业务使用的实际URL … 业务编码N 此业务的上行数据流量（单位：字节） 此业务的下行数据流量（单位：字节） 业务有效使用时长 业务使用的实际URL 当话单流量为0时，该字段不必出现。

41

QB-╳╳-╳╳╳-╳╳╳╳

10.2.15.

Record Opening Time

这个字段包含了记录打开时的时间戳(具体的格式参考3GPP TS 32.005)。 10.2.16.

Record Sequence Number

这个字段记录了部分话单的相应序号，把某个特定的承载连接的从PDG产生的部分话单关联起来(特性与 Charging ID 和PDG地址相同)。如果承载连接只产生一个PDG话单，就没有记录序列号。 10.2.17.

Record Type

这个字段标识了记录类型，比如：S-CDR, G-CDR, M-CDR, S-SMO-CDR 及 S-SMT-CDR，WLAN-CDR。 10.2.18.

Served IMSI

这个字段包含了被使用的国际移动用户识别码(IMSI)。 该字段用来描述 参与被记录的交易的移动用户，比如终端发起的承载中的主叫用户。IMSI的格式在3GPP TS 23.003 有所定义。 10.2.19.

Served MSISDN

这个字段包含了被使用的移动台(MS)的ISDN号码(MSISDN)。 该字段用来描述 参与被记录的交易的移动用户。 MSISDN的格式在3GPP TS 23.003中有所定义。 10.2.20.

Served PDP Address(WLAN UE remote IP address)

这个字段包含了被使用的IMSI的Remote IP地址。这是网络层的IP V4或IP V6地址。每个PDP类型的地址是被临时分配或永久分配的。除了PDP类型是PPP并且使用动态PDP地址时，该参数都出现。 10.2.21.

Served IMEISV

这个字段包含了终端设备的国际移动设备识别码和软件版本(IMEISV)。IMEISV的格式在3GPP TS 23.003 有所定义。 10.2.22.

WLAN Session ID

这个字段是WLAN会话的标识，用于关联WLAN产生的计费信息和PDG产生的计费信息。

42

QB-╳╳-╳╳╳-╳╳╳╳

11. 话单的ASN.1描述

11.1.

PDG输出WLAN-CDR的ASN.1 定义

Within the current GSM 12-series of specifications the ASN.1 definitions are based on ISO8824 (90) / X.208 (88), which has been superseded by ISO8824-1 (94) / X.680 (94). This newer version not only includes new features but also removes some that were present in ISO8824 (90) / X.208 (88) .

Where possible, the GPRS work would be based on those ASN.1 features to both. However, where necessary, the new features in ISO8824-1 (94) / X.680 (94) be used in some places. ISO8824 (90) / X.208 (88)features that are no longer in ISO8824-1 (94) / X.680 (94) will not be used.

Changes (enhancements) in GSM1205-DataTypes:

CallEventRecordType ::= INTEGER { --

-- Record values 201 are WLAN specific

moCallRecord mtCallRecord roamingRecord

(0), (1), (2), (3), (4), (5), (6), (7), (8), (9), (10), (11), (12), (13), (14), (15), (16), (17), (18), (19), (20), (21), (22),

incGatewayRecord outGatewayRecord transitCallRecord moSMSRecord mtSMSRecord moSMSIWRecord mtSMSGWRecord ssActionRecord hlrIntRecord

locUpdateHLRRecord locUpdateVLRRecord commonEquipRecord moTraceRecord mtTraceRecord

termCAMELIntRecord sgsnPDPRecord ggsnPDPRecord sgsnMMRecord sgsnSMORecord sgsnSMTRecord

43

QB-╳╳-╳╳╳-╳╳╳╳

wlanRecord (201) }

WLANChargingDataTypes {itu-t (0) identified-organization (4) etsi(0) mobileDomain (0) charging (5) wlanChargingDataTypes (3) asn1Module (0) version1 (0)}

DEFINITIONS IMPLICIT TAGS ::= BEGIN

EXPORTS everything

IMPORTS

CellId,

Diagnostics,

CallDuration,

ManagementExtensions,

TimeStamp,

MSISDN,

LocationAreaCode, MessageReference, RecordingEntity, SMSResult, LevelOfCAMELService, CalledNumber, CallingNumber

FROM GenericChargingDataTypes {itu-t (0) identified-organization (4) etsi(0) mobileDomain (0) charging (5) genericChargingDataTypes (0) asn1Module (0) version1 (0)} AddressString, ISDN-AddressString, IMSI, IMEI

FROM MAP-CommonDataTypes { ccitt identified-organization (4) etsi(0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version6 (6) }

DefaultGPRS-Handling, DefaultSMS-Handling, ServiceKey

FROM MAP-MS-DataTypes { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version6 (6) }

ManagementExtension

FROM Attribute-ASN1Module {joint-iso-ccitt ms(9) smi(3) part2 (2) asn1Module(2) 1} ; --

-- Note that the syntax of AE-title to be used is from -- CCITT Rec. X.227 / ISO 8650 corrigendum and not \--

------------------------------------------------------------------------------ --

-- CALL AND EVENT RECORDS --

------------------------------------------------------------------------------

CallEventRecord ::= CHOICE {

-- Record values 0..16 are 3G curcuit switch specific --

moCallRecord

[0] MOCallRecord,

44

QB-╳╳-╳╳╳-╳╳╳╳

mtCallRecord [1] MTCallRecord, roamingRecord

[2] RoamingRecord, incGatewayRecord [3] IncGatewayRecord, outGatewayRecord [4] OutGatewayRecord, transitRecord [5] TransitCallRecord, moSMSRecord [6] MOSMSRecord, mtSMSRecord [7] MTSMSRecord, moSMSIWRecord [8] MOSMSIWRecord, mtSMSGWRecord [9] MTSMSGWRecord, ssActionRecord [10] SSActionRecord, hlrIntRecord

[11] HLRIntRecord, locUpdateHLRRecord [12] LocUpdateHLRRecord, locUpdateVLRRecord [13] LocUpdateVLRRecord, commonEquipRecord [14] CommonEquipRecord, recTypeExtensions [15] ManagementExtensions, termCAMELIntRecord

[16] TermCAMELIntRecord,

-- sgsnPDPRecord [20] SGSNPDPRecord, ggsnPDPRecord [21] GGSNPDPRecord, sgsnMMRecord [22] SGSNMMRecord, sgsnSMORecord [23] SGSNSMORecord, sgsnSMTRecord

[24] SGSNSMTRecord,

--

-- Record values 201 are WLAN specific wlanRecord [201]WLANRecord }

WLANRecord ::= SET { recordType [0] CallEventRecordType, servedIMSI

[3] IMSI, ggsnAddress [4] GSNAddress, chargingID

[5] ChargingID,

sgsnAddress

[6] SEQUENCE OF GSNAddress, accessPointNameNI [7] AccessPointNameNI OPTIONAL, pdpType

[8] PDPType OPTIONAL, servedPDPAddress [9] PDPAddress OPTIONAL,

dynamicAddressFlag

[11] DynamicAddressFlag OPTIONAL,

listOfTrafficVolumes [12] SEQUENCE OF ChangeOfCharCondition OPTIONAL, recordOpeningTime [13] TimeStamp, duration

[14] CallDuration, causeForRecClosing [15] CauseForRecClosing, diagnostics

[16] Diagnostics OPTIONAL, recordSequenceNumber [17] INTEGER OPTIONAL,

nodeID

[18] NodeID OPTIONAL,

45

QB-╳╳-╳╳╳-╳╳╳╳

recordExtensions localSequenceNumber servedMSISDN

[19] ManagementExtensions OPTIONAL, [20] LocalSequenceNumber OPTIONAL, [22] MSISDN OPTIONAL,

[23] ChargingCharacteristics, [24] ChChSelectionMode OPTIONAL, [29] IMEI OPTIONAL, [51] WLANSessionId

chargingCharacteristics chChSelectionMode servedIMEISV wlanSessionId

}

------------------------------------------------------------------------------ --

-- OBJECT IDENTIFIERS --

------------------------------------------------------------------------------

gsm1205InformationModel

gsm1205ASN1Module OBJECT IDENTIFIER ::=

------------------------------------------------------------------------------ --

-- COMMON DATA TYPES --

------------------------------------------------------------------------------

AccessPointNameNI ::= IA5String (SIZE(1..63))

AccessPointNameOI ::= IA5String (SIZE(1..37))

--

-- Operator Identifier part of APN in \

-- In the 'apn1a.apn1b.apn1c.mnc022.mcc111.gprs' example, the OI portion is --

-- Network Identifier part of APN in \

-- For example, if the complete APN is 'apn1a.apn1b.apn1c.mnc022.mcc111.gprs' -- NI is 'apn1a.apn1b.apn1c' and is presented in this form in the CDR. { gsm1205InformationModel asn1Module(2) }

OBJECT IDENTIFIER

::=

{ ccitt (0) identified-organization (4) etsi (0) mobileDomain (0) gsm-Operation-Maintenance (3) gsm-12-05 (5) informationModel (0) }

'mnc022.mcc111.gprs'

APNSelectionMode::= ENUMERATED

-- and is presented in this form in the CDR.

46

本文来源：https://www.bwwdw.com/article/ifow.html