当前位置:首页 >> 信息与通信 >>

演进的分组核心网络计费规范v0.1.1-mark


中 国 移 动 通 信 企 业 标 准
QB-╳╳-╳╳╳-╳╳╳╳

演进的分组核心网络计费规范

EPC Network Charging Sepification

版 本 号 : 0.1.1

╳ ╳ ╳ ╳ -╳ ╳ -╳ ╳ 发 布

╳ ╳ ╳ ╳ -╳ ╳

-╳ ╳ 实 施

中国移动通信有限公司

发布

3G Network Elements Charging Capability Request Packet Switch Domain Part





目 录 .............................................................................. I 前 言 ............................................................................. IV 1 范围 ................................................................................ 1 2 规范性引用文件 ...................................................................... 1 3 缩略语 .............................................................................. 2 4 概述 ................................................................................ 3 4.1 EPS 网络架构 ....................................................................... 3 4.2 网络设备 .......................................................................... 4 4.3 网络接口参考点 .................................................................... 4 5 计费系统概述 ........................................................................ 4 5.1 离线计费 .......................................................................... 8 5.1.1 概述 ............................................................................ 8 5.1.2 功能实体 ........................................................................ 9 5.1.3 参考点 ......................................................................... 10 5.2 在线计费 ......................................................................... 11 5.2.1 概述 ........................................................................... 11 5.2.2 功能实体 ....................................................................... 13 5.2.3 参考点 ......................................................................... 13 6 Serving GW 及 PDN GW 节点计费要求 .................................................. 14 6.1 要求 ............................................................................. 14 6.2 计费数据收集原则 ................................................................. 15 6.2.1 IP-CAN 承载上下文计费 .......................................................... 15 6.2.2 C-ID 的产生 ..................................................................... 16 6.2.3 部分话单的输出 ................................................................. 17 6.2.4 QOS ............................................................................ 17 6.2.5 漫游 ........................................................................... 17 6.2.6 切换 ........................................................................... 19 6.3 内容计费 ......................................................................... 20 6.3.1 基于 APN 的内容计费 ............................................................ 20 6.3.2 基于应用的内容计费 ............................................................. 20 6.4 在线计费 ......................................................................... 28 7 计费话单产生机制 ................................................................... 28 7.1 概述 ............................................................................. 28 7.2 SGW-CDR 产生机制 ................................................................ 28 7.2.1 业务流量列表追加计费信息的触发条件 ............................................. 29 7.2.2 话单关闭触发条件 ............................................................... 29 7.3 PGW-CDR 产生机制 ................................................................ 30 7.3.1 业务流量列表追加计费信息的触发条件 ............................................. 30 7.3.2 话单关闭触发条件 ............................................................... 31
I

8 CGF 对话单的处理 ................................................................... 8.1 CGF 功能实现 ..................................................................... 8.1.1 CDF 功能 ....................................................................... 8.1.2 CGF 功能 ....................................................................... 8.2 话单合并 ......................................................................... 8.2.1 简介 ........................................................................... 8.2.2 同一个 S-GW 产生的 SGW-CDR 部分话单的合并 ..................................... 8.2.3 不同 S-GW 的 SGW-CDR 的合并 ................................................... 8.2.4 SGW-CDR 合并处理小结 .......................................................... 8.2.5 PGW-CDR 的合并 ................................................................ 8.2.6 PCNs 与主 CGF 间的通信发生故障的情况 ............................................ 9 计费采集接口和协议 ................................................................. 9.1 GTP’协议栈 ....................................................................... 9.1.1 S-GW - CGF 协议栈............................................................... 9.1.2 P-GW - CGF 协议栈............................................................... 9.2 承载协议 ......................................................................... 9.3 计费节点的原则 ................................................................... 9.4 GTP’计费通信协议 ................................................................. 9.5 GTP’消息 ......................................................................... 9.5.1 GTP’消息 ...................................................................... 9.5.2 GTP’中直接使用 GTP 消息 ....................................................... 9.5.3 GTP’中修改使用 GTP 消息 ....................................................... 9.5.4 GTP’消息类型 .................................................................. 9.5.5 重复话单传送的防止 ............................................................. 9.5.6 备份方式对话单合并的影响 ....................................................... 9.6 GTP 的记录格式 ................................................................... 9.6.1 标准记录格式 ................................................................... 9.6.2 私有记录格式 ................................................................... 9.7 记录格式版本 ..................................................................... 9.8 CGF - BS 协议接口 ................................................................. 10 话单类型 .......................................................................... 10.1 类型列表 ........................................................................ 10.1.1 SGW-CDR ..................................................................... 10.1.2 PGW-CDR ..................................................................... 10.1.3 经 CGF 处理后的 SGW-CDR ...................................................... 10.1.4 经 CGF 处理后的 PGW-CDR ...................................................... 10.2 话单参数描述 .................................................................... 10.2.1 话单字段描述 .................................................................. 10.2.2 Access Point Name (APN) Network Identifier .......................................... 10.2.3 APN Selection Mode .............................................................. 10.2.4 CAMEL Information .............................................................. 10.2.5 Cause for Record Closing .......................................................... 10.2.6 Charging Characteristics ........................................................... 10.2.7 Charging Characteristics Selection Mode ..............................................
II

31 32 32 32 33 33 33 36 37 37 39 39 40 40 40 41 41 41 42 42 44 45 45 53 58 59 59 59 59 60 60 60 60 61 63 65 67 67 67 68 68 69 69 69

10.2.8 Charging ID ..................................................................... 70 10.2.9 Consolidation Result .............................................................. 70 10.2.10 Diagnostics .................................................................... 70 10.2.11 Duration....................................................................... 70 10.2.12 Dynamic Address Flag ........................................................... 70 10.2.13 External Charging Identifier ....................................................... 70 10.2.14 IMS Signalling Context ........................................................... 70 10.2.15 List of Service Data .............................................................. 70 10.2.16 List of Traffic Data Volumes ...................................................... 72 10.2.17 Local Record Sequence Number .................................................... 73 10.2.18 MS Time Zone ................................................................. 73 10.2.19 Node ID ....................................................................... 73 10.2.20 P-GW Address Used ............................................................. 73 10.2.21 P-GW PLMN Identifier ........................................................... 74 10.2.22 PDN Connection ID ............................................................. 74 10.2.23 PDP/PDN Type ................................................................. 74 10.2.24 PS Furnish Charging Information ................................................... 74 10.2.25 RAT Type ..................................................................... 74 10.2.26 Record Extensions ............................................................... 75 10.2.27 Record Opening Time ............................................................ 75 10.2.28 Record Sequence Number ......................................................... 75 10.2.29 Record Type ................................................................... 75 10.2.30 S-GW Address Used ............................................................. 75 10.2.31 Served 3GPP2 MEID ............................................................ 75 10.2.32 Served IMEISV ................................................................. 75 10.2.33 Served IMSI ................................................................... 75 10.2.34 Served MN NAI ................................................................ 75 10.2.35 Served MSISDN ................................................................ 75 10.2.36 Served PDP/PDN Address ........................................................ 75 10.2.37 Serving Node Address ............................................................ 75 10.2.38 Serving Node PLMN Identifier ..................................................... 75 10.2.39 Serving Node Type .............................................................. 76 10.2.40 S-GW Change .................................................................. 76 10.2.41 Start Time ..................................................................... 76 10.2.42 Stop Time ..................................................................... 76 10.2.43 User Location Information ........................................................ 76 11 话单的 ASN.1 描述 .................................................................. 76 11.1 S-GW 和 P-GW 输出 CDR 的 ASN.1 定义 ............................................. 76 11.2 CGF 输出 CDR 的 ASN.1 定义 ...................................................... 89 12 编制历史 ......................................................................... 103 附录 A:EPS 设备话单与 2G/3G 话单内容变化 ............................................ 104

III





本标准的目的是为中国移动通信集团公司计费相关设备引进、网络规划、设备制造、 工程设计、网络运行、管理和维护等方面提供技术依据。 本标准主要内容包括计费相关设备在功能、性能、接口、操作维护等方面的要求。 本标准是演进的分组域核心网络设备系列标准之一,该系列标准的结构、名称或预计 的名称如下:
序号 例 [1] [2] [3] [4] [5] [6] [7] ?? ?? 标准编号 标准名称

本标准需与企业标准编号《企业标准名称》配套使用。 本标准的附录 本标准由中移 为标准性附录,附录 号文件印发。 为资料性附录。

本标准由中国移动通信集团计划部提出,集团公司技术部归口。 本标准起草单位:中国移动通信研究院 本标准主要起草人:魏彬、侯志强、党京

IV

1 范围 本标准规定了中国移动通信集团公司演进的分组核心网络(EPC)计费相关要求,包括Serving GW 及PDN GW节点计费要求、计费话单产生机制、CGF功能实现、计费采集接口和协议、话单类型及ASN.1 描述等方面的要求, 供中国移动通信集团公司及设备厂家共同使用, 为设备引进、 网络规划与设备制造、 工程设计、网络运行、管理和维护等提供技术依据。 2 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。 凡是注日期的引用文件, 其随后所有的 修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究 是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。 序号 [1] 标准编号 3GPP TS 23.060 标准名称 “General Packet Radio Service (GPRS) Service description Stage 2” “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access” “Policy and charging control architecture” “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPC)” “Mobility Management Entity (MME) – Visitor Location Register (VLR) SGs interface specification” “Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol” “General Packet Radio Service (GPRS) 3GPP 发布单位

[2]

3GPP TS 23.401

3GPP

[3] [4]

3GPP TS 23.203 3GPP TS 24.301

3GPP 3GPP

[5]

3GPP TS 29.118

3GPP

[6]

3GPP TS 29.272

3GPP

[7]

3GPP TS 29.274

3GPP

1

Tunnelling Protocol for Control Plane (GTPv2-C)” [8] 3GPP TS 36.413 “Evolved Terrestrial Access (E-UTRAN); Application (S1AP)” Universal Radio Network S1 Protocol 3GPP

3 缩略语 下列缩略语适用于本标准。 词语 CDR CG CGF DNS E-UTRAN GPRS GSN GTP GTP-U GUTI HSS HPLMN IMSI IP IPv4 IPv6 MCC MME MNC MS
2

解释 Call Detail Record 呼叫详细记录 Charging Gateway 计费网关 Charging Gateway Function 计费网关功能 Domain Name Server 域名服务器 Evolved Universal Terrestrial Radio Access Network 演进的通用陆地接入网 General Packet Radio Service 通用分组 无线业务 GPRS Support Node GPRS支持节点 GPRS Tunnel Protocol GPRS隧道节点 GPRS Tunnelling Protocol for User Plane 用户面的GTP隧道协议 Globally Unique Temporary Identity 全 局唯一临时标识 Home Subscriber Server 归属签约用户服 务器 Home PLMN 归属陆地移动通信网 International Mobile Subscriber Identity 国际移动用户识别码 Internet Protocol 互联网协议 Internet Protocol version 4 互联网协议 版本4 Internet Protocol version 6 互联网协议 版本6 Mobile Country Code 移动国家号码 Mobility Management Entity 移动管理实 体 Mobile Network Code 移动网号 Mobile Station 移动台

MTBF NAS PCRF PDN P-GW QoS SGSN S-GW SIM TA TAI TAU TCP TEID TID UDP UP UTRAN VPLMN

Mean Time Between Failures 平均故障间 隔时间 Network Access Server 网络接入服务器 Policy and Charging Rules Function 策 略及计费规则功能 Packet Data Network 分组数据网 PDN Gateway 分组数据网网关 Quality of Service 业务质量 Serving GPRS Support Node 服务GPRS支持 节点 Serving Gateway 服务网关 Subscriber Identify Module 用户识别卡 Tracking Area 追踪区域 Tracking Area Identity 追踪区域标识 Tracking Area Update 追踪区域更新 Transmission Control Protocol 传输控制 协议 Tunnelling Endpoint Indentification 隧 道端点标识符 Tunnel Identifier 隧道标识 User Datagram Protocol 用户数据报协议 User Plane 用户面 UMTS Terrestrial Radio Access Network UMTS 陆地无线接入网 Visited Public Land Mobile Network 拜 访公共陆地移动通信网

4 概述 4.1 EPC 网络架构 EPC网络设备包括移动性管理设备(MME)、服务网关(S-GW)、PDN网关(P-GW)、服务GPRS支持 节点(SGSN)、归属签约用户服务器(HSS)以及策略和计费控制单元(PCRF)等组成。网络架构如图 4-1所示,其中S-GW和P-GW可以合设,也可以分设。 2G/3G SGSN只提供Gn/Gp接口,SAE架构下和Gn/Gp SGSN的互通架构如图4-2所示。

3

UTRAN SGSN GERAN S3 S1-MME S6a MME S11 LTE-Uu UE E-UTRAN S1-U S10 S12 S4 Serving S5/S8 Gateway Gx PDN Gateway SGi PCRF Rx Operator's IP Services (e.g. IMS, PSS etc.) S6d HSS

图4-1 EPC网络架构(S-GW与P-GW分设)

GERAN UTRAN S1-MME Gn/Gp SGSN

Gr HSS S6a Gn MME Gn S10 S11 SGW S1u Gx PGW S5/S8 SGi PCRF Rx

UE

E-UTRAN

Operator's IP Services (e.g. IMS, PSS etc.)

图4-2 4.2 网络设备

EPC架构与Gn/Gp SGSN互通

MME的主要功能包括:支持NAS信令及其安全、跟踪区域(Tracking Area)列表的管理、P-GW和S-GW 的选择、跨MME切换时MME的选择、在向2G/3G接入系统切换过程中SGSN的选择、用户的鉴权、漫游控制 以及承载管理、 3GPP不同接入网络的核心网络节点之间的移动性管理, 以及UE在ECM-IDLE状态下可达性 管理等。 S-GW是终止于E-UTRAN接口的网关,该设备的主要功能包括:eNodeB间切换时的本地锚定点、3GPP 不同接入系统间切换时的移动性锚点、执行合法侦听功能、数据包的路由和前转、上下行传输层的分组 标记、ECM-IDLE状态下分组缓存及寻呼触发、计费等。 P-GW是面向PDN终结于SGi接口的网关,该设备的主要功能包括:基于用户的包过滤功能、合法侦听 功能、UE的IP地址分配功能、上下行传输层的分组标记、计费、门控、QoS控制、承载控制等。 与EPC系统互通的SGSN在现有SGSN功能之上还需支持:2G/3G/LTE接入网间的移动信令交互、P-GW 和S-GW的选择、MME的选择。 HSS是用于存储用户签约信息的数据库。该设备的主要功能包括:存储用户签约信息、用户鉴权、 位置信息管理等。 PCRF终结于Rx接口和Gx接口,该设备主要功能包括:提供基于业务数据流的QoS控制、门控和计费 控制等。 EPC网络各实体之间接口均基于IP传输,各实体应具备IPv4/IPv6双栈功能。 5 计费系统概述

4

分组域计费包括在线计费和离线计费,图5-1、5-2、5-3分别给出了PCC下各种漫游场景的计费架构 图,图5-4给出了计费系统的逻辑架构图,其中包括在线计费和离线计费。在5.1节和5.2节分别详细的 描述了离线计费和在线计费。 在EPC网络中,可采用PCC架构实现计费功能。PCC架构包括非漫游架构(图5-1)、漫游架构归属地 接入(图5-2)、漫游架构local breakout(图5-3),如下所示:
Subscription Profile Repository (SPR) Sp AF Online Charging System (OCS) Service Data Flow Based Credit Control

Rx

Policy and Charging Rules Function (PCRF)

Gx Gxx Gy BBERF PCEF

Gz

Gateway

Offline Charging System (OFCS)

图5-1:PCC架构(非漫游情况下)

5

Subscription Profile Repository (SPR) HPLMN VPLMN S9 Policy and Charging Rules Function (V-PCRF)

Sp

AF

Online Charging System (OCS) Service Data Flow Based Credit Control

Rx

Policy and Charging Rules Function (H-PCRF)

Gxx

Gx

BBERF

PCEF

Gy

Gz

Gateway

Offline Charging System (OFCS)

图5-2:PCC架构(漫游情况下归属地接入)

6

VPLMN

Subscription Profile Repository HPLMN (SPR) Sp

AF

Online Charging System (OCS) Service Data Flow Based Credit Control

Rx

Policy and Charging Rules Function (H-PCRF) AF S9 Rx

Policy and Charging Rules Function (V-PCRF)

Gxx

Gx Gy

BBERF

PCEF

Gz

Gateway
图5-3:PCC架构(漫游情况下拜访地接入local breakout)

Offline Charging System (OFCS)

EPS网络的计费方式包括在线计费和离线计费。对于离线计费系统,S-GW/P-GW/SGSN采集到计费信 息后,通过CDF和CGF,传送到BD;对于在线计费系统,用户能够预先缴纳费用并转换为使用业务的额度 (例如:时间、流量),用户额度实时影响业务使用,额度耗尽后可能终止业务、降低体验或改变计费 策略,S-GW/P-GW/SGSN采集到的在线计费信息是传送到OCS的,OCS经过处理后再传送到BD。 EPS网络的计费系统架构如图所示。

7

计费系统

SGSN

CGF

CDF

S-GW

OCS
P-GW
PCEF

离线计费
PCRF AF

在线计费

红色:CAP 接口,绿色:Gy 接口,紫色:Rf 接口,深蓝色:Bp 接口,浅蓝色:Ga 接口。 图 5-4:计费系统结构图 5.1 离线计费 5.1.1 概述 离线计费系统架构如图5-2所示,可以分成多层架构,原内嵌在网元中的功能分为CTF和CDF,CTF 依然保留在网元,CDF/CGF功能与网元可分可合,如果CDF与CTF分离,则CTF和CDF间以标准Rf口相连; 如果CDF/CGF与网元合一, 则网元直接出Bp接口连接计费中心。 CDF和CGF在分离情况下仍以Ga接口相连。 CGF和Billing Domain间的接口Bp口采用诸如FTP/FTAM的文件传输方式。CDF与CGF是两个在逻辑上独立 的实体,CDF负责从CTF收集计费信息,生成相应的CDR并发送给CGF,CGF对CDR进行处理后发送给计费域 BD。一般来讲,CDF通过Ga接口向CGF传送话单。 CDF实体分别内置在S-GW、P-GW及SGSN等网元中,S-GW、P-GW及SGSN可共享同一CGF实体。

8

EPS 网络 SGSN C S-GW T F P-GW Rf C D F Ga C G F Bp Billing Domain

图 5-5 EPS 离线计费系统架构

5.1.2 功能实体 5.1.2.1 CDF 功能实体 (1)计费话单的生成 CDF通过Rf接口从CTF接收计费事件,从而产生相应的CDR。这个过程包括: 单个的计费事件可以生成一个CDR,即:事件和CDR的关系是1:1的关系; 也可以多个事件生成一个CDR,即:事件和CDR的关系是N:1的关系; 每个计费事件只用于一个CDR,即:事件和CDR之间不存在1:N的关系(N>1); 多个计费事件生成一个CDR的时候,不要求这些计费事件是同一种类型; 在计费事件的接收和CDR的生成过程之间,没有同步的要求。但是,CDF必须能够接收处理 计费事件并近乎实时地来生成CDR; 用于生成一个CDR的所有计费事件都必须是从同一个网络实体中采集的, 即: 在CDF的计费 事件中不存在网络实体或者网络实体类型的交叉关联。 PGW-CDR 用来在 P-GW 中收集用户 IP-CAN 承载相关的计费信息。 (2)CDR 话单内容 CDF应该能够产生以下几种话单: SGW-CDR:基于S-GW信息产生的话单 PGW-CDR:基于P-GW信息产生的话单

9

话单格式应遵循3GPP TS 32.298等相关标准规定。 5.1.2.2 CGF 功能实体 CDF 产生的 CDR,通过 Ga 参考点立即送到 CGF。CGF 相当于计费系统和 PCNs 之间的网关,它 利用 Bp 参考点将 CDR 文件传送给计费系统。CDF 和 CGF 之间的关系是 M:1,即:一个或多个 CDF 都可以将 CDR 输入到同一个 CGF。CGF 的功能包括: (1) 近乎实时地通过Ga参考点,从CDF接收CDR。 (2) CDR预处理功能 CDR确认与合并 CDR错误处理 CDR永久存储

(3) CDR的过滤与分拣 根据一定的过滤机制(例如:CDR 类型,CDR 参数,生成 CDR 的 CDF 地址等)将 CDR 存储在不同的文件中。 (4) CDR文件的管理 CGF 能够进行文件的建立,文件的打开关闭,文件删除等操作。 (5) 向BD传送CDR文件

5.1.2.3 CTF 功能实体 CTF 产生计费事件,提供计费信息,将计费信息组装成计费事件,并将这些计费事件发送给 CDF。 CTF 由两大功能组成: 计费数据收集 传送计费数据

5.1.3 参考点 5.1.3.1 Rf 参考点 Rf 参考点支持 CTF 和 CDF 之间的交互,能够实时提供下列信息: 从CTF到CDF的计费事件,用于离线计费; 从CDF到CTF的这些计费事件的确认信息。

Rf 参考点的协议能够支持下列功能: 10

实时交互; 无状态模式(基于事件的计费)和有状态模式(基于会话的计费)操作;

-

可靠性保护机制,比如:计费事件的重传。

另外,参考点的协议还能够保证在主 CDF 不可达的情况下,能够倒换到备用的 CDF。 Rf 接口是内部接口,暂不做要求,具体要求参见 3GPP TS 32.299。 5.1.3.2 Ga 参考点 Ga参考点支持CDF和CGF之间的交互,能够提供下列信息: 从CDF到CGF的CDR; 从CGF到CDF的这些CDR的确认信息。

Ga参考点的协议能够支持下列功能: 准实时交互; 在一个请求消息中,发送一个或多个CDR; 在主CGF不可达的情况下,可以倒换到备用的CGF; 可靠性保护机制,比如:计费事件的重传。

Ga参考点的具体要求参见3GPP TS 32.295。 5.1.3.3 Bp 参考点 Bp参考点支持CGF和BD之间的交互,能够提供下列信息: 从CGF到BG的CDR

Bp参考点的具体要求参见3GPP TS 32.297。 5.2 在线计费 5.2.1 概述 在线计费系统通过设置和发送剩余信用额度(时长或者流量)的方式通知PCEF。当PCEF检测到信用 额度达到阈值时,向OCS发送信用额度的重新授权,同时携带使用过的信用值。 在线计费系统架构如图所示,OCS由OCF、ABMF和RF功能组成。

11

EPS 网络 P-GW C PCEF T F Ro OCS Rc O C F Re
RF ABMF

图 5-6:EPS 在线计费系统架构图 在线计费应该提供实时的计费以及对网络资源使用的实时授权功能。当用户发起网络资源使用请 求时, EPS 网络需要向在线计费系统上报请求并提供计费信息, 在线计费系统通过信用控制对用户的请 求进行鉴权和授权, 并根据网络资源的使用情况在用户的预付费帐户中进行相应计费。 在线计费的计费 信息的获得方式和离线计费相同,而对请求授权,费用计算,记入及费用扣除等操作则需要在用户使用 资源过程中实时完成。 EPS 在线计费应该支持基于 Diameter 基础计费协议上的信用控制协议,并支持通过 Ro 口实时进 行用户使用业务的信用控制。支持在线计费的 EPS 实体在收到用户网络资源使用请求后,需要收集相 关的计费信息实时生成计费事件并通过 Ro 接口发送给 OCS。OCS 对请求进行鉴权并返回授权结果和 预留费用单元。实体将授权的费用资源分配给申请用户,并最终根据业务的使用情况进行计费。 在线计费应该能够同时支持以下三种在线计费类型: 1) 2) 3) 即时事件计费(IEC) 计费单元预留的事件计费(ECUR) 计费单元预留的会话计费(SCUR)

在线计费应该能够通过 Debit Units 操作完成即时事件计费, Debit Units 操作可以在业务使用之前, 业务使用同时或者业务使用完成后进行。Debit Units 操作是由对应特定的信用控制事件的 CCR 消息发 起的。 在线计费应该能够通过 Reserve Units 和 Debit Units 操作完成计费单元预留的事件计费。 操作可以

12

在业务使用之前,业务使用同时或者业务使用完成后进行。ECUR 包括资源请求,资源预留,资源释放 和返还剩余费用等操作过程。 在线计费应该能够通过 Reserve Units 和 Debit Units 操作完成计费单元预留的会话计费。 操作可以 在业务使用之前,业务使用同时或者业务使用完成后进行。SCUR 也包括资源请求,资源预留,资源释 放,返还剩余费用以及扣除相应费用等操作过程。 在线计费应该能够根据业务类型或者运营商的策略决定是否使用某种计费类型。 在线计费应该能够对不同的用户和不同的业务类型实行不同的信用控制策略。 在线计费系统也可以根据运营商的需求生成在线计费的 CDR 文件。在线计费系统可以利用离线 计费系统的 CDF 和 CGF 生成并管理在线计费 CDR 和 CDR 文件, 也可以在 OCS 中生成在线计费的 CDR 文件。 5.2.2 功能实体 5.2.2.1 OCF 功能 OCF 由两个不同的模块 SBCF (基于会话的计费功能) EBCF 和 (基于事件的计费功能) 组成。 SBCF 是基于网络或用户的会话进行在线计费的,比如:话音、IP CAN 承载、IP CAN 会话或 IMS 会话等。 EBCF 则基于事件进行在线计费(也可称为内容计费) 。 P-GW/PCEF 通过 Ro 参考点与 OCF 进行联系。

5.2.2.2 计价功能(Rating Function) 计价功能决定网络资源使用的价格。OCF 从计费事件中获取必须的信息,提供给 RF,RF 再通过 Re 参考点反馈给 OCF 计价费率。RF 可以处理的事件包括: 数据流量的计价(比如,基于接入网络实体发起的计费,即:在承载级别) 会话或连接的时间的计价(例如基于 SIP 应用发起的) 业务事件的计价

5.2.2.3 帐户余额管理功能(Account Balance Management Function) 帐户余额管理功能(Account Balance Management Function)存储和管理用户帐户中的余额信息。

5.2.3 参考点 5.2.3.1 Ro 参考点 Ro 参考点支持 PCEF 和 OCS 之间的交互,能够提供下列信息:
13

-

从PECF到OCS的计费事件,用于在线计费; 从PCEF到OCS的这些计费事件的确认信息, 这些确认消息能够根据OCS的决策, 来确定是接 收还是拒绝计费事件中请求的网络资源。

Ro 参考点的协议能够支持下列功能: 实时交互; 无状态模式(基于事件的计费)和有状态模式(基于会话的计费)操作; 可靠性保护机制,比如:计费事件的重传。

另外,参考点的协议还能够保证在主 OCS 不可达的情况下,能够倒换到备用的 OCS。 Ro 参考点具体要求参见 3GPP TS 32.299。

6 Serving GW 及 PDN GW 节点计费要求 6.1 要求 对分组域计费有以下要求,这些要求平等适用于在线计费和离线计费: 1)每个 IP-CAN 承载上下文应该赋予唯一的标识(即 charging ID) ; 2)由于数据传输所具备的上下行具备不对称性,对于上行、下行所对应的终端用户发送和接受的数据 流量须分别统计。 3)每个 IP-CAN 承载上下文的计费信息应反映时间信息,如起始时间和持续时长。 4)运营商对计费信息的产生具备一定的主控权,即可以通过在 PCN 上作配置,让 PCN 仅产生运营商 需要的计费信息。 5)P-GW 可选支持基于 IETF 技术的在线计费; 6)P-GW 能够支持基于单个 SDF 的数据流量、时间或事件的识别(基于流的承载计费) ,一条 PCC 规 则对应一个 SDF; 7)当 P-GW 支持在线计费时,信用控制应基于费率组; 8)P-GW 应支持基于费率组或基于费率组与 Service ID 绑定来上报业务使用情况,上报级别是基于每 PCC 规则的。

14

分组域对于每个 MS/UE 的计费信息分别是在 SGSNs,S-GWs 和 P-GWs 进行收集的。SGSN 和 S-GW 对于每个 MS/UE 的计费信息收集是与无线网络使用相关联的, P-GW 对于每个 MS/UE 的计费 而 信息收集是与外部数据网络使用相关联的。PCNs 也收集 PS 域网络资源使用的计费信息。 对于每个 IP-CAN 承载上下文来说,PCNs 应收集下列计费信息: 1. 无线接口的使用:计费信息应包含在 MO 和 MT 方向的数据流量,并携带 QoS 信息和用户协 议; 2、业务的时长:需要包含 IP-CAN 承载上下文激活到去活的时间间隔; 3、一般 PS 域资源的使用:计费信息应包含 PS 域相关的资源和 MS 的活动信息(如用户的移动 信息) ; 4、源和目的地址:计费信息应提供用户 IP-CAN 承载上下文实际的源地址,也应反映由 APN 所 体现的 IP-CAN 承载上下文建立并最终访问的目的地。 5、外部网络的使用情况:计费信息应包含从外网接收和发送的数据量,外部网络能用 APN 标示。 6. MS 的位置:HPLMN,VPLMN 和精确的位置信息(如 RA、LAC、CI 等) ; 对于 FBC 定义的 SDF,P-GW 应能收集下列计费信息: 1、以上描述的 IP-CAN 承载上下文的计费信息; 2、流量计费时,可以提供通过费率组标示的 MO 和 MT 方向的数据流量,或者通过费率组和业 务 ID 绑定组标示 MO 和 MT 方向的数据流量; 3、时间计费时,可以提供基于费率组级别的 SDF 的时长或基于费率组和业务 ID 绑定组的 SDF 时长; 4、事件计费时,可以提供基于费率组级别的事件数量和对应的时戳,或基于费率组和业务 ID 绑 定组的事件数量和对应的时戳; 6.2 计费数据收集原则 SGSN 能生成 CDRs,S-GW 和 P-GW 能生成 CDRs 或上报计费事件,如下所示: SGSN 能生成 S-CDR,S-GW 生成 SGW-CDR,P-GW 能生成 PGW-CDR; 在 P-GW 的 PGW-CDR 有与 SDF 相关的 CDR; 当 CDF 作为一个单独实体时(与 S-GW 和 P-GW 分离) ,CDF 将触发计费事件并上报计费内容。 CDR 的信息和上报机制如下章节描述: 6.2.1 IP-CAN 承载上下文计费 SGSN、 P-GW 和 S-GW 基于 IP-CAN 承载上下文收集计费信息, 包括 UE/MS 的发送接收的数据流
15

量、承载上下文的 QCI 和 ARP 信息。用户可以根据 MSISDN/IMSI 区分,P-GW 在创建 IP-CAN 承载上 下文时,同时生成唯一的计费 ID,并转发给 S-GW/SGSN,这样保证 S-GW/SGSN 产生的 CDR 可以与 P-GW 的 CDR 在计费系统内关联起来。IP-CAN 承载计费定义了下列计费事件: ? ? ? IP-CAN承载上下文创建:在接收到这个事件后,会生成新的CDR,流量信息保留下来; 在SGSN/S-GW/P-GW 中IP-CAN承载上下文删除:在接收到这个事件后,CDR将会关闭; 跟踪区更新 o Inter-SGSN/inter S-GW:在SGSN/S-GW中CDR关闭,在P-GW中新的SGSN/S-GW 地址 加入到CDR中。 Inter-MME:在S-GW中新的MME地址加入到CDR中。 SGSN to MME:在SGSN中CDR关闭,在S-GW新的MME地址加入到CDR中。

o o ?

系统间切换 (例如:从GSM到UMTS):触发老的CDR关闭,如果 IP-CAN承载还处于激活态, 则打开新的CDR。 在P-GW中PLMN改变: 触发老的CDR关闭, 如果 IP-CAN承载还处于激活态, 则打开新的CDR。 在P-GW中MS Timezone改变:触发老的CDR关闭,如果 IP-CAN承载还处于激活态,则打开新 的CDR。 操作者配置的时间门限超时:触发老的CDR关闭,如果 IP-CAN承载还处于激活态,则打开新 的CDR。 操作者配置的流量门限超时:触发老的CDR关闭,如果 IP-CAN承载还处于激活态,则打开新 的CDR。 在SGSN内计费条件改变:例如QoS改变,费率改变或DT建立/删除,该事件触发当前流量保存, 新的流量计数开始; 在S-GW/P-GW内计费条件改变:例如QoS改变,费率改变或DT建立/删除,该事件触发当前流 量保存,新的流量计数开始; 操作者配置的最大改变次数到:触发老的CDR关闭,如果 IP-CAN承载还处于激活态,则打开 新的CDR。 管理干涉也可以强制触发计费事件。

? ?

?

?

?

?

?

?

如果 CDF 作为一个单独实体时(与 S-GW 和 P-GW 分离) ,则 CDR 需要遵循以上所有计费处理。. 6.2.2 C-ID 的产生 话单信息可以通过分配一个唯一的 Charging ID(C-ID) ,标识与一个 IP-CAN 承载上下文相关的所有话 单记录。 在 IP-CAN 承载上下文激活时,P-GW 为其分配一个唯一的 C-ID,并前转给 S-GW/SGSN,这样将
16

S-GW/SGSN 的 CDR 与 PGW 的 CDR 关联起来。

6.2.3 部分话单的输出 因为数据流量限制、时长限制、计费条件改变、管理原因、无线接入技术类型改变等,一个 IP-CAN 承 载可能对应多个部分话单 (partial record) 并通过唯一的 C-ID 标识, , 无论是 SGW-CDR 还是 PGW-CDR 都使用 Record Sequence Number 标识部分话单的序号, 同一个 IP-CAN 承载的不同种类话单 (SGW-CDR 或 PGW-CDR)之间与同一类型话单的部分话单之间都用 C-ID 关联。 部分话单产生时的触发门限取决与运营商通过 O&M 方式设定的配置参数。 在 SGW-CDR 关闭但相应 IP-CAN 承载上下文仍然激活时, 如果发生 S-GW 改变, 则新的 SGW-CDR 序 列号重置,否则可生成序列号递增的 SGW-CDR。 在计费系统侧无法保证话单的顺序和连续接收, 合并过程中可能出现合并部分话单后收到新的话单。 因 此要求所有部分话单包含详细信息。

6.2.4 QOS S-GW 和 P-GW 中产生的 SGW-CDR 和 PGW-CDR 中包含 QoS 参数(Quality of Service Requested/ Negotiated) ,并且 QoS 在 IP-CAN 承载上下文中的动态变化可以在 SGW-CDR 的 List of Traffic Data Volumes 来记录,PGW-CDR 的 List of Service Data 来记录。据此,运营商可以确定用户在不同的 QoS 状态下所使用的系统资源,从而实现基于 QoS 的计费方式。 注意: P-GW 在每个业务数据容器中只能包含一种 QoS 信息, 如果运营商希望在计费系统内能根据 QCI 和 ARP 区分业务的不同使用,则需要确保每种业务有不同的 QCI 和 ARP。

6.2.5 漫游 基于目前的标准进展,对于3GPP接入的漫游分为如下几种情况:

17

HSS S7 S6a PDN Gateway HPLMN

PCRF Rx+ SGi Operator’s IP Services (e.g. IMS, PSS etc.)

VPLMN

UTRAN SGSN GERAN S12 S3 S1-MME S4 MME

S8a

S11 “LTE - Uu ” UE E-UTRAN S1-U S10 Serving Gateway

图 6-1 归属地接入场景(home routed traffic)

HSS

H-PCRF Rx+

S6a Home Operator’s IP Services HPLMN
S9

VPLMN

GERAN

SGSN
UTRAN

S3 S1-MME

V-PCRF

MME
S11

S4
S7

“LTE-Uu” UE

S10

SGi Serving S5 Gateway PDN Gateway Visited Operator PDN

E-UTRAN
S1-U

图 6-2: Local Breakout 漫游架构, AF 在归属地

18

HSS

H-PCRF

S6a

HPLMN

S9

VPLMN

GERAN

SGSN
UTRAN

S3 S1-MME

V-PCRF

MME
S11

S4
S7 Rx+

“LTE-Uu” UE

S10

SGi Serving S5 Gateway PDN Gateway

E-UTRAN
S1-U

Visited network IP Services or proxies to home network services

图6-3 Local Breakout的漫游架构, AF在拜访地 目前对于归属地漫游接入场景: PCEF 应位于 HPLMN 的 P-GW,与 OCS 通过 Gy 接口连接,与 CGF 通过 Gz 接口连接,不需要考虑归 属地接入情况下的移动协议。 VPLMN 运营商可以在 VPLMN S-GW 中对于跨运营商的漫游产生承载级别的计费数据。 对于 Local Breakout 漫游场景: 在这种场景下,对于在线计费和离线计费系统的所处位置来说可能存在扩展的要求。 6.2.6 切换 P-GW 产生的 PGW-CDR 话单中与位置有关的字段有 Serving node Address 地址,存储该话单打开 期间与 P-GW 连接的 S-GW 列表(由于 S-GW 间路由区更新造成的 SGSN 变更) ,因此只有在 S-GW 间 发生切换才会对 P-GW 搜集计费信息产生影响。 S-GW 产生的 SGW-CDR 可以包含漫游区编码、 可选的服务对象当前所在的小区标识组合而成的位 置信息。任何位置的改变,即漫游区更新,都可通过位置改变属性连同更新的时间一起被记录下来,该 字段为可选项,当位置变化发生在部分话单打开时没有要求。 在漫游时发生的切换,与简单的漫游相比,也体现在 SGW-CDR 的合并方面稍微复杂。 当发生 MME 与 S4 SGSN 之间的切换(ETURAN 接入和 UTRAN/GERAN 接入之间)以及 UTRAN 与 GERAN 接入之间的切换时, S-GW 可以通过 SGW-CDR 中的 RAT Type 字段区分 UTRAN/GERAN/LTE 系统,并且切换后,S-GW 可以通过发送 Update Bearer Request 消息,将用户正在使用的无线接入技术
19

类型(通过 RAT Type 字段)告知 P-GW,从而促使 P-GW 产生部分话单,并在 PGW-CDR 中通过 RAT Type 字段标识不同的无线接入技术类型。 当发生 MME 与 Gn/Gp SGSN 之间的切换时,如果 Gn/Gp SGSN 支持上报无线接入类型,P-GW 应 将其体现在 PGW-CDR RAT Type 字段中; 另外, 要求在 P-GW 上可以配置 Gn/Gp SGSN 地址列表与 RAT Type 的对应关系, Gn/Gp SGSN 没有将无线接入类型上报给 P-GW 时, 当 P-GW 设备应可以根据 Gn/Gp SGSN 地址判断 RAT Type 取值; 如果 Gn/Gp SGSN 地址不在该列表中, 则可以按照默认配置将 RAT Type 置为 GERAN 或 UTRAN,并进行后续处理(包括判断是否有 RAT 变化并生成新话单,部分话单产生原 因值为 RAT 类型改变,填写话单中 RAT 字段等) 。 6.3 内容计费 内容计费是指完成按照接入方式、业务种类、流量、时长、事件(点击等) 、QOS,及其组合的计 费。 完整内容计费应该包含下列信息的组合: ? ? ? ? 不同业务(内容)的流量信息; 不同业务(内容)的时间信息; 不同业务(内容)的事件信息; 不同业务(内容)的信息费。

内容计费信息应由流量计费平台和业务平台共同采集完成,由业务支撑系统完成最终的计费信息整合。 在内容计费体系中, P-GW 做为基于业务的流量统计点, 完成精细的, 区分到业务的数据流量统计, 不同的业务流量统计应区分上下行流量。 6.3.1 基于 APN 的内容计费 6.3.1.1 CMWAP 和 CMNET 类业务 基于 CMWAP 和 CMNET 的业务,因为分配了不同的 APN, 故可使用 SGW-CDR 及 PGW-CDR 中的 APN 字段加以业务区分, 从而实现基于 APN 的内容计费。 6.3.1.2 VPN VPN 业务采用不同 APN 时,目前 PCNs 节点使用 SGW-CDR 及 PGW-CDR 中的 APN 字段可加以 业务区分从而实现不同 VPN 的计费。 6.3.2 基于应用的内容计费 普通的 WAP 浏览业务、MMS 业务, Kjava 业务以及其他业务可能都基于同一个 APN 开展,即经 过 WAP 网关实现的。 对这些同一 APN 下的不同业务,根据市场要求需考虑采取不同的计费方式。作为与外部数据网络
20

相连的节点, 分组域的 P-GW 应该能够区分出不同业务的数据流量,并通过话单表述出来。 P-GW 设备应支持通过配置对某个 APN 关闭和开启内容计费功能,当关闭内容计费功能时 PGW-CDR 格式应不包含内容计费字段信息(Record Extensions) ; 6.3.2.1 业务解析 P-GW 要求能够解决目前移动通讯网络承载的数据业务的接入和转发, 同时要求能够根据预先配置 在 P-GW 的业务过滤计费规则,对流经 P-GW 的业务数据流(GTP 协议之上)能够进行不同协议层次 (从三层到七层)的业务分析,业务解析层次可配置从而区分不同数据业务,实现内容计费。 ? ? ? ? 承载层(基于 IP-CAN 承载上下文或 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 协议。 现阶段要求 P-GW 应支持的数据业务包括:HTTP 业务、WAP 浏览类业务、MMS 业务、流媒体业务、 邮件类业务、FTP 业务等。因此 P-GW 应具备对 HTTP、WAP1.x、WAP2.0、RTSP、RTP 和 RTCP、FTP、 POP3/SMTP 的协议分析能力。 6.3.2.2 流量统计 要求 P-GW 支持对于数据业务的 IP 层流量进行统计。 要求 P-GW 支持对于数据业务的应用层流量进行统计(可选) 。 6.3.2.3 内容计费规则配置 在业务解析区分的基础上, P-GW 根据配置的内容计费规则,对业务数据包进行匹配达到流量区分的目 的, 并针对不同业务将区分出的相应流量信息记录在话单中。 为满足今后移动数据业务灵活的计费要求,要求 P-GW 可以同时支持 6.3.2.1 节中各层次计费要求的任 意组合,这些计费要求都可以通过定义计费规则来实现。 1. 内容计费规则描述

当数据包到达 P-GW 后,P-GW 进行数据拆包分析并匹配内容计费规则,若匹配到计费规则,则进行内 容计费,针对业务统计上下行流量。内容计费规则可配置的属性如下: ? ? ? APN ? 业务 ID
21

? ? ? ? ? ? ? ? ? ?

? 源 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)七层属性:根据内容计费规则 P-GW 要能够分析与某个 URL 连接有关的所有数据流量,且计费规 则中 URL 应支持前置、中置、后置通配符和同时指定多个通配符,如 www.isp.com/*, *.isp.com,*.mp3, www.*.com,www.isp.*,*.isp.*等。并且应能将七层应用协议中的特殊字段值(现阶段要求支持 x-online-host 字段的 IP 地址)作为过滤规则的属性对数据流进行区分。 在进行七层 URL 的匹配时对于通配符按以下规定处理: ? “*”如用于 URL 的起始部分( “/”以前) ,只代表字符串且不包含“.”,如“*.monternet.com”可 以用于匹配“news.monternet.com”; ?
22

“*”如用于 URL 的路径部分( “/”以后) ,可代表任何字符,包括“/” ,如“www.monternet.com/*”

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

5)优先级:对内容计费规则按人工指定的顺序进行匹配。 (可选) P-GW 需要支持缺省(default)规则的设置,该计费规则统计所有内容计费规则匹配不成功的数据包流 量。 内容计费规则设置中,不同计费规则若存在互包含关系,则必须是真包含关系。被包含的计费规则相对 于另一条计费规则称为子集计费规则。P-GW 应具备规则冲突检测机制,若规则配置中出现违背以上原 则的情况需要提示。 2. 内容计费规则配置

要求 P-GW 支持计费规则的静态配置,即所配置的内容计费规则在数据处理流程中规则的属性不发生 变化。计费规则配置的更新不需要重启 P-GW 设备。P-GW 需要考虑未来基于 IMS 数据业务等的流量 统计需要,计费规则需要结合策略机制动态协商配置。 配置管理的功能可以在 P-GW 本地维护终端实现或者集成到现有的网管系统中 所有的内容计费配置项可以统一进行维护,P-GW 本地维护终端应该提供稳定可靠,简单易用的图形操 作界面。界面中各元素应清晰可读,不具备二义性。在配置界面上,应该能提供详细的在线帮助,可以 方便地进行搜索、查询操作。操作人员可以通过图形界面,进行内容计费规则的创建, 添加、修改、编 辑等操作。 内容计费数据配置要求: (1)P-GW 可以配置的三层至七层的计费规则数应当不少于 1000 个,其中七层计费规则数不少于 400 个; (2)P-GW 可以配置用于内容计费的 APN 个数应当不少于 200 个。 为了确保内容计费规则配置的正确性,提供带有内容计费能力 P-GW 的公司必须同时提供独立于设备 的内容计费规则配置局数据核查软件,简称“局数据核查软件” ,局数据核查软件的规范另外提供。 6.3.2.4 内容计费规则的匹配 P-GW 对计费规则的匹配和业务数据包的拆包分析结合进行,处理流程如下: 1、P-GW 分析数据包三/四层属性,获得数据包的目的 IP 地址和端口号等信息; 2、在包含三/四层属性的计费规则中进行顺序匹配,若匹配到某条规则,且该规则不包含七层属性,则

23

跳转到第 6 步; 3、P-GW 分析数据包七层属性,获得数据包的七层 URL 属性; 4、在包含七层属性的计费规则中进行顺序匹配,若匹配到某条规则,则跳转到第 6 步;若没有匹配规 则,而且规则包含三/四层属性,则在仅包含三/四层属性的计费规则中进行顺序匹配,若匹配到某条规 则,则跳转到第 6 步; 5、将数据流量统计入缺省规则对应的流量; 6、将数据流量统计入匹配规则对应的业务流量。 计费规则的匹配顺序上应遵循以下原则: 若两个计费规则之间存在互包含关系, 则子集计费规则匹配优 先级应高于另一条计费规则。 P-GW 对于计费规则应具备优先级处理机制,根据计费规则的属性配置,基于上述原则自动确定规则的 匹配顺序。 P-GW 可以对计费规则的优先级项进行人工配置调整匹配的先后顺序。 (可选) 需要注意的是,七层 URL 及 x-online-host(包括字段名及字段值)的匹配是不区分大小写的。 6.3.2.5 内容计费的业务支撑要求 经过 P-GW 的上下行分组数据包按照运营商制定的内容计费规则过滤, 依据过滤结果, 在 PGW-CDR 的 List of Service Data 域记录其业务类型标识,以方便计费中心识别。在一个 IP-CAN 承载上下文的过程 中,移动用户接收/发出属于多个应用的数据包,即使它们都使用同一 APN,不同应用的识别号以及 相应的上下行数据流量也会在 PGW-CDR 的 List of Service Data 参数相应的域中体现。做为未来内容计 费的要求, 不同应用的服务质量(QoS)也应加以记录。 同一 IP-CAN 承载上下文中不同应用的计费信息在 List of Service Data 中采取列表方式记录。 对 List of Service Data 字段的具体要求参见本规范的相关章节。 涉及内容计费的 IP-CAN 承载上下文的计费话单的部分输出, 遵循 PGW-CDR 的部分输出原则. CG 对包含有内容计费的 PGW-CDR 的合并,可根据运营商的要求, 按照内容类型的不同, 加以合并处 理。若同一应用的计费信息合并中存在部分项的数据不同(例如 RAT) ,则计费信息列表方式记录。

要求 P-GW 支持后付费的内容计费,话单产生条件和普通话单产生条件相同。 要求 P-GW 支持热付费的内容计费,话单产生条件和普通话单产生条件相同。热计费话单要求 3-10 秒 内传送到 BOSS,时间长度可设置,话单传送接口支持 FTP 方式。在产生的话单中应当有热计费标志。 (可选) 6.3.2.6 数据业务的内容计费流程

24

P-GW 内容计费所支持的业务按业务特点可以分成三类: 第一类业务,端口不动态变化,业务需基于 URL 识别,如 HTTP,WAP,MMS,下载类(流媒体下载、 KJAVA 下载) 。内容计费流程如下:
MS 1.IP-CAN承载 建立请求 4.IP-CAN承载 建立响应 P-GW WAPGW CG/BOSS Server

2.用户上线请求 3.用户上线请求响应 5.握手消息 6.Get/Post消息

规则匹配,计 费开始点 7.业务数据

流量采集

8.发送话单

9.业务结束消息 计费结束点

1-4、 IP-CAN 承载建立,P-GW、WAPGW 记录用户信息; 5、用户同业务服务器建立连接; 6、用户发起业务访问,P-GW 根据计费规则匹配业务,开始计费,统计业务流量信息; 7、用户和业务服务器之间发送业务数据; 8、P-GW 采集流量,如果满足产生部分话单条件,P-GW 产生中间话单,话单发送到 CG,CG 进行预 处理后把话单发送到 BOSS 处理; 9、业务结束,P-GW 停止该业务流量统计,IP-CAN 承载去活后,产生最终话单。

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

25

MS 1.IP-CAN承载 建立请求 4.IP-CAN承载 建立响应

P-GW

WAPGW

CG/BOSS

Server

2.用户上线请求 3.用户上线请求响应 5.握手消息 6.控制面消息

规则匹配,计 费开始点
7.生成新规则

8.数据面数据发送 流量采集 9.发送话单

10.控制面业务结束消息 计费结束点

1-4、IP-CAN 承载建立,P-GW、WAPGW 记录用户信息; 5、用户同业务服务器建立连接; 6、用户发起业务访问,同业务服务器发送控制面的交互消息,P-GW 根据计费规则匹配务,开始计费, 统计业务流量; 7、P-GW 根据控制面消息交换结果,生成新计费规则用来匹配业务数据; 8、用户和业务服务器之间通过数据面发送业务数据。P-GW 根据新计费规则,采集用户流量; 9、P-GW 采集流量,如果满足产生部分话单条件,P-GW 产生中间话单,话单发送到 CG,CG 进行预 处理后把话单发送到 BOSS 处理; 10、业务结束,P-GW 停止该业务流量统计,IP-CAN 承载去活后,产生最终话单。

第三类业务,属于 Server 端端口固定的业务,可通过 3/4 层解析进行内容计费,如 POP3/SMTP、在线 KJAVA 应用等,流程如下:

26

MS 1.IP-CAN承载 建立请求 4.IP-CAN承载 建立响应 规则匹配,计 费开始点

P-GW

WAPGW

CG/BOSS

Server

2.用户上线请求 3.用户上线请求响应

5.握手消息

6.业务数据

流量采集

7.发送话单

8.业务结束消息 计费结束点

1-4、 IP-CAN 承载建立,P-GW、WAPGW 记录用户信息; 5、用户同业务服务器建立连接,P-GW 根据 3/4 层计费规则匹配业务,开始计费; 6、用户和业务服务器之间发送业务数据; 7、P-GW 采集流量,如果满足产生部分话单条件,P-GW 产生中间话单,话单发送到 CG,CG 进行预 处理后把话单发送到 BOSS 处理; 8、业务结束,P-GW 停止该业务流量统计,IP-CAN 承载去活后,产生最终话单。

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

不同数据业务的内容计费流程参见附录二。 6.3.2.7 内容计费对 P-GW 的性能影响 P-GW 增加内容计费功能后对数据处理性能要求: 1. 2. 3. P-GW 开启内容计费功能后支持的承载数应当不少于未开启内容计费功能支持的承载数的 50%; P-GW 开启内容计费功能后的数据吞吐量应当不少于未开启内容计费功能的数据吞吐量的 60%; 开启内容计费功能对 P-GW 数据转发时延的增加小于 1ms。

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

6.4 在线计费 P-GW应支持基于Gy接口的在线计费功能。 7 计费话单产生机制 7.1 概述 SGSN 和 S-GW、P-GW 产生 S-CDR、SGW-CDR、PGW-CDR、S-SMO-CDR 和 S-SMT-CDR 以搜集计 费信息以便以后传送给计费网关功能(CGF) 。 SGSN/S-GW/P-GW 与 CGF 应支持及时产生话单(秒级) ,要求 S-GW、P-GW 与 CGF 产生话单的出单 参数可灵活配置。 可以对每个 PDP 上下文或/IP-CAN 承载上下文设定计费特性。设定后,它将决定 S-CDR、SGW-CDR、 PGW-CDR 的产生和触发条件。 如果没有对一个 PDP 上下文或/IP-CAN 承载上下文设定计费特性, 就采 用一套缺省的触发条件。 在 SGSN/S-GW/P-GW 中可以针对每个计费特性允许或禁止生成话单。如果允许生成话单,可以对每个 计费特性定义以下不同的触发条件参数: ? ? ? 数据流量门限; 时间(时长门限) ; 计费条件改变的最大数(QoS 改变,费率时间改变) 。

以下章节将描述 S-GW/P-GW 搜集计费信息和生成话单时的触发条件。

7.2 SGW-CDR 产生机制 SGW-CDR 用来采集 UE/MS 在 SGW 上的承载数据的计费信息。 SGW-CDR依据每个QCI/ARP分割收集的计费信息。SGW-CDR可以包括: ? IP-CAN承载特定容器,用于上报IP-CAN承载的QCI/ARP使用和授权。

每个 SGW-CDR 包含至少一个 IP-CAN 承载特定容器。 依赖于用户的计费特性,SGW-CDR 在用户 IP-CAN 承载激活和 IP-CAN 承载特定容器被打开时打 开,并且上行和下行流量分别统计。当计费条件发生变化时,计费流量统计到新的 SGW-CDR 中。 SGW-CDR 包含记录类型、服务的用户标识、队列号等详细信息。并非所有的计费信息是静态的,有些 计费信息依赖于动态的 PS 业务。 如果依据一个 PDP 上下文的计费特性允许产生 CDR,则一个 S-CDR 将在每个 PDP 上下文激活时 打开,并且记录包括话单类型、用户 IMSI、Charging ID、System Type 等具体信息。
28

7.2.1 业务流量列表追加计费信息的触发条件 SGW-CDR 中的“传输流量列表”属性包含一些 IP-CAN 承载传输流量的集合,它包括上行传输流 量、下行传输流量以及触发 SGW-CDR 的条件。下表描述了 SGW-CDR 计费信息增加的条件: 触发条件 QoS 改变 描述 / 操作 服务质量改变将打开的“传输流量列表”被关闭并被增加到 CDR 中,同时 打开新的 IP-CAN 承载特定容器。 费率改变 用户位置改变 到达费率时间改变点时,将打开的“传输流量列表”关闭并增加到 CDR 中 用户位置信息(ECGI、TAI、RAI、SAI、CGI)等改变,将打开的“传输流 量列表”容器关闭并增加到 CDR 中。如果需要进行位置上报,则会接收到用户 位置改变的上报 CDR 关闭 打开的“List of Traffic Data Volumes”容器关闭并增加到 CDR 中

7.2.2 话单关闭触发条件 当以下计费事件发生时,会触发 SGW-CDR 话单关闭; 表 5-1:关闭 SGW-CDR 的触发条件 关闭条件 IP-CAN 承载结束 描述 / 操作 S-GW 中的 IP-CAN 承载的去激活将导致话单关闭。触发条件包括: 部分话单的原因 IP-CAN承载中止 S-GW改变 其他异常释放。

运营商可根据管理需要设置话单关闭条件,可能的触发条件包括: 数据流量限制, 时间(时长)限制, 计费条件改变的最大次数 网管干预 MS 时间区改变 PLMN 改变 无线接入技术类型改变(RAT Type)

29

7.3 PGW-CDR 产生机制 PGW-CDR用来采集UE/MS在P-GW上的承载数据相关的计费信息, 每个PGW-CDR的数据流量、 计费时长、 事件个数是基于费率率组或绑定组(费率组+业务标识)独立统计的。 PGW-CDR每个IP-CAN可以同时激活多个业务数据流容器。当业务监测到了且没有匹配的数据流容量 存在时激活一个业务数据流容器,被监测的数据流终止时关闭业务数据流容器。 依赖于用户的计费特性, PGW-CDR在用户IP-CAN承载激活时打开,统计经历的时间、事件上报的次 数、上行和下行流量分别统计。当计费条件发生变化时,计费流量统计到新的PGW-CDR中。PGW-CDR包含 记录类型、 服务的用户标识、 队列号等详细信息以及基于流的计费信息。 并非所有的计费信息是静态的, 有些计费信息依赖于动态的PS业务。 一个IP-CAN承载可能同时激活在线和离线计费接口, 默认情况下两种计费时独立的, 但是在一些情 况下两种计费也可能是紧密耦合的,例如用来关闭SDF容器的,从而引起计费额外信息添加的OCS触发 的额度重授权。 7.3.1 业务流量列表追加计费信息的触发条件 PGW-CDR 的传输流量列表包含一套容器, 当特定条件触发时(如下表所示)将触发传输流量列表 计费信息的追加。 触发条件 IP-CAN 承载上下文修改 描述 / 操作 IP-CAN 承载上下文改变(例如: QoS 改变, SGSN/S-GW 改变, PLMN Id 改变, RAT 改变,用户位置的改变) 将产生“传输流量列表”增加到 CDR 中 费率改变 DCCA 失败处理 业务数据流上报 到达费率时间改变点时,将产生“传输流量列表”增加到 CDR 中 当 Diameter Credit-Control 失败将触发“传输流量列表”增加到 CDR 中 如果在线计费和离线计费是独立的, “传输流量列表”增加到 CDR 中依赖于 下面几个条件: 时间门限到; 流量门限到; 单元门限到; 业务数据流中止;

在线计费和离线计费紧密耦合时, “传输流量列表”增加到 CDR 中依赖于下 面几个条件: 时间门限到;

30

CDR 关闭

流量门限到; 单位门限到; 时间额度耗尽; 流量额度耗尽; 单位额度耗尽; 有效时间额度到; 业务数据流终止; OCS 请求重授权。

List of Service Data 增加到 CDR 中

7.3.2 话单关闭触发条件 当以下计费事件发生时,会触发 PGW-CDR 话单关闭; 表 5-1:关闭 PGW-CDR 的触发条件 关闭条件 IP-CAN 承载结束 描述 / 操作 P-GW 中的 IP-CAN 承载的去激活将导致话单关闭。触发条件包括: 部分话单的原因 IP-CAN承载中止 P-GW改变 其他异常释放。

运营商可根据管理需要设置话单关闭条件,可能的触发条件包括: 数据流量限制, 时间(时长)限制, 计费条件改变的最大次数 网管干预 MS 时间区改变 PLMN 改变 无线接入技术类型改变(RAT Type) S-GW 的切换

8 CGF 对话单的处理

31

8.1 CGF 功能实现 CGF提供从S-GW和P-GW节点向运营商的BS传送计费信息的机制,为了简化描述,要求从S-GW和P-GW 设备产生话单,到CGF生成BOSS可采集的话单文件的时延要求小于15分钟。 在3GPP中,离线计费系统包含2种逻辑功能,CDF功能和CGF功能,CDF与CGF是两个在逻辑上独立的 实体, CDF负责从CTF收集计费信息, 生成相应的CDR并发送给CGF, CGF对CDR进行处理后发送给计费域BD。 一般来讲,CDF通过Ga接口向CGF传送话单。 CDF实体通常分别内置在S-GW、P-GW及SGSN等网元中,S-GW、P-GW及SGSN可共享同一CGF实体。

8.1.1 CDF 功能 CDF 通过 Rf 接口从 CTF 接收计费事件,从而产生相应的 CDR。这个过程包括: 单个的计费事件可以生成一个CDR,即:事件和CDR的关系是1:1的关系; 也可以多个事件生成一个CDR,即:事件和CDR的关系是N:1的关系; 每个计费事件只用于一个CDR,即:事件和CDR之间不存在1:N的关系(N>1); 多个计费事件生成一个CDR的时候,不要求这些计费事件是同一种类型; 在计费事件的接收和CDR的生成过程之间,没有同步的要求。但是,CDF必须能够接收处理 计费事件并近乎实时地来生成CDR; 用于生成一个CDR的所有计费事件都必须是从同一个网络实体中采集的, 即: 在CDF的计费 事件中不存在网络实体或者网络实体类型的交叉关联。

CDF应该能够产生以下几种话单: SGW-CDR:基于S-GW信息产生的话单 PGW-CDR:基于P-GW信息产生的话单

话单格式应遵循3GPP TS 32.298等相关标准规定。

8.1.2 CGF 功能 CDF 产生的 CDR,通过 Ga 参考点立即送到 CGF。CGF 相当于计费系统和核心网之间的网关,它 利用 Bp 参考点将 CDR 文件传送给计费系统。CDF 和 CGF 之间的关系是 M:1,即:一个或多个 CDF 都可以将 CDR 输入到同一个 CGF。CGF 的功能包括: (1) 近乎实时地通过Ga参考点,从CDF接收CDR。 (2) CDR预处理功能
32

-

CDR确认与合并 CDR错误处理. CDR永久存储

(3) CDR的过滤与分拣 根据一定的过滤机制(例如:CDR 类型,CDR 参数,生成 CDR 的 CDF 地址等)将 CDR 存储在不同的文件中。 (4) CDR文件的管理 CGF 能够进行文件的建立,文件的打开关闭,文件删除等操作。 (5) 向BD传送CDR文件

8.2 话单合并 8.2.1 简介 对于同一个 IP-CAN 承载上下文,可能对应多个部分话单,需要进行话单合并。 部分话单的合并分两级进行:第一级合并由 CGF 进行,可以减少 CGF 与计费中心间的带宽要求以及减 轻计费中心的处理负担,由于各种原因,这一级的话单合并可能是不完全的;第二级合并由计费中心进 行,主要合并在 CGF 中未完全合并的话单,从而产生最终的话单。 对于每次 IP-CAN 承载上下文由 P-GW 负责产生一个唯一的 C-ID。根据 C-ID+P-GW 地址,可以确定 两张部分话单是否属于同一次 IP-CAN 承载上下文。 对于 SGW-CDR,C-ID+P-GW 地址+ S-GW 地址+RAT Type 相同的部分话单必须进行合并; 对于 PGW-CDR,C-ID+P-GW 地址+S-GW 地址+RAT Type 相同的部分话单必须进行合并; 对一次 IP-CAN 承载上下文,归口于一个 P-GW,因此只存在对应同一个 P-GW 的部分 PGW-CDR 的合 并问题;然而对于 S-GW 的切换,SGW-CDR 的话单合并情况就复杂多了,CGF 应该能够灵活地进行 不同程度话单合并,尽可能地完成话单合并功能。 对 SGW-CDR 合并情况列举: ? ? ? ? 同一个 S-GW 产生的 SGW-CDR 部分话单的合并; 归属于同一 CGF 的不同 S-GW 的 SGW-CDR 的合并; 归属于不同 CGF 的不同 S-GW,但这些 CGF 仍属于同一 BS; 归属于不同 CGF,而且 CGF 不属于同一 BS;

8.2.2 同一个 S-GW 产生的 SGW-CDR 部分话单的合并

33

8.2.2.1 合并依据 记录中的 P-GW 地址+C-ID+S-GW 地址+ RAT Type 及记录类型(SGW-CDR 记录类型)是合并的依据。 8.2.2.2 合并触发方式 S-GW 定期(在数十秒到数百秒)向 CGF 发送 CDR,合并可以采用事件触发方式和定期合并方式相结 合的方法,具体实现方法由厂商确定。 8.2.2.3 合并过程中各字段的处理 1. 无需额外处理的字段

在一次 IP-CAN 承载上下文中,Record Type、Served IMSI、Served MSISDN、Served IMEI、Serving node Type、 Charging ID、 S-GW Address used、 P-GW Address used.、 Serving Node PLMN Identifier、 APN Selection Mode、PDP/PDN Type、Served PDP/PDN Address、Charging Characteristics、Diagnostics、Charging Characteristics selection mode、Dynamic Address Flag、RAT Type、Start Time、Stop Time,以上字段保持 不变,合并时只需要保留一个。 2. 需要过滤的字段

在一次 IP-CAN 承载上下文中, 手机移动穿越多个小区或位置区, 不同部分话单的 User Location Information 可能不同,合并操作只保留第一个话单的位置信息,过滤掉后续话单的位置信息。 对 Record Opening Time 字段仅保留第一个部分记录的该字段,后续记录的该字段被过滤,对于一批连 续部分话单,Duration 字段 = (最后的部分记录的 Record Opening Time - 最先的部分记录的 Record Opening Time + 最后的部分记录的 Duration 字段) ;对于不连续话单 Duration 字段累加。 对 Cause for Record Closing 字段按照优先级从高到低保留,从高到低依次是 IP-CAN 承载上下文结束、 S-GW Change、Partial record,Record Extensions 保留第一个。 3. 需要拼接的字段

List of Traffic Data Volumes 字段为一列表,该字段合并实际就是将各列表拼接形成一个列表。 对于 Record Sequence Number 字段,合并前是整数类型,合并过程中将这些整数拼成一张列表,在列表 首加上本 S-GW 的地址。 对于 Local Record Sequence Number 字段,合并前是整数类型,合并过程中将这些整数拼成一张列表, 在列表首加上本 S-GW 的地址。 4. 需要保留的字段

S-GW Change 字段仅在 S-GW Handover 发生时,在新 S-GW 的中第一个部分记录的 S-GW Change 字段 被置位。如果 S-GW Change 字段被置位,部分话单合并后 S-GW Change 字段继续置位。 5.
34

需要添加的字段

添加合并结果 (Consolidation Result) 标志, 如果对一次 IP-CAN 承载上下文完成合并, 置正常 (normal) 标志;如果合并过程中发现错误,置不正常(abnormal)标志;如果还有待与其他 S-GW 的 CDR 合并, 置 S-GW 合并(ForInterS-GWConsolidation)标志;如果合并后的话单长度超过最长话单范围,那么置 超出门限(ReachLimit)标记。 6. 合并流程

第一步:根据 P-GW 地址+C-ID+S-GW 地址+RAT Type 将原始话单分类,并根据话单关键信息(P-GW 地址+C-ID+S-GW 地址+ RAT Type+QoS 列表中的 CloseTime)剔除重单; 第二步:话单合并,CDR 合并过程中首先判断该话单与已合并列表是否连续:待合并话单的 Record Opening Time 与列表中最后的 CloseTime 连续(相差 2 秒内)且 Record Sequence Number 连续,或待合 并话单 QoS 列表中的 CloseTime 与列表中的 Record Opening Time 连续 (相差 2 秒内) Record Sequence 且 Number 连续,如果条件满足,将该话单插入合并列表并合并相关的列表,进入第三步;否则创建该话 单列表,回到第二步; 第三步:比较 Record Opening Time 字段,保留小的,剔除大的; Duration 字段累加(或作更精确的处 理) ;List of Traffic Data Volumes 拼接;Cause for Record Closing 字段按优先级顺序保留。 第四步:每次合并操作后检查 Cause for Record Closing 字段,如果 Cause for Record Closing 字段 =normalRelease,检查 Record Sequence Number 列表,如果首张话单已合并进来,说明本次会话过程结 束,则完成合并过程,转第五步。如果 Cause for Record Closing 字段=S-GW Change,说明发生了 S-GW 切换,如果首张话单已合并进来, S-GW 完成合并过程, 本 转第五步。 如在规定时间内 Cause for Record Closing 字段=normalRelease 的话单仍然未能达到,置 ConsolidationResult=Abnormal,转第六步。如果 Cause for Record Closing 字段原因是 partial record(如 timelimit 或 volumelimit) ,说明还有后续记录,需 要继续合并,转第二步。 第五步:如果合并完成(即 Cause for Record Closing 字段=normalRelease 或 S-GWChange 或话单数据量 达到门限) 置 ConsolidationResult =Normal 或 ForInterS-GWConsolidation , (根据 Cause for Record Closing 而定) 。如果合并后话单达到数据量门限,则置 ConsolidationResult =ReachLimit。 第六步:可以将该 CDR 送往 BS,如 ConsolidationResult =Abnormal,则表明有部分话单丢失,如果以 后再有该次会话的部分记录到来 CGF 将之送到 BS 并由 BS 的预处理部分试图合并。 合并的流程图概要如下:

35

将原始话单分类,并剔除重单

查找待合并话单,开始合并

话单与已合并列表

Y

是否连续?

N

合并列表,字段合并处理

创建新列表

合并是否完成?

Y Y

N N
超出规定时间?

设置合并结果,话单传送计费系统

图 7-2 合并的流程图

8.2.3 不同 S-GW 的 SGW-CDR 的合并 这种情况是 MS 发生了 S-GW 之间的切换,处理原则如下: CGF 根据 P-GW 地址+C-ID+S-GW 地址+RecordType+RAT Type 先进行 S-GW1 的 SGW-CDR 合并, S-GW2 的 SGW-CDR 合并,而避免 S-GW1 的部分话单与 S-GW2 的部分话单之间的合并。 S-GW1 与 S-GW2 话单分别合并方法与同上节。 S-GW1 的合并结果是 Cause for Record Closing = S-GW Change;S-GW2 的话单经过 CG1 合并后,其 S-GW Change 置位。 CGF 可以根据 P-GW 地址+C-ID+RAT Type 及记录类型,对 S-GW1 的 SGW-CDR 和 SGW-GW2 的 SGW-CDR 进行合并,处理方法与同一 S-GW 的 CDR 合并方法类似。保留最早的 Record Opening Time 字段,累加 Duration 字段,Cause for Record Closing 字段仍然按照优先级顺序保留。Record Sequence Number 列表继续拼接。不同之处在于:S-GW 的地址需要用列表来表示。

36

对于 S-GW Change 字段,如果两个 SGW-CDR 都置位,则保持置位。在合并时如果一个记录的 S-GW Change 字段未置位,另一个该字段置位,说明通话开始于 S-GW Change 字段未置位的 S-GW,合并时 将该 S-GW 位于列表首,合并后 S-GW Change 字段不置位。

8.2.3.1 归属不同 CGF 的不同 S-GW,但这些 CGF 仍属于同一 BS BS 负责合并,合并处理原则同上节。

8.2.3.2 归属于不同 CGF,而且 CGF 不属于同一 BS 暂不考虑合并。

8.2.4 SGW-CDR 合并处理小结 SGW-CDR 的话单合并情况比较复杂, CGF 应该能够灵活地进行不同程度话单合并, 如提供原始未经合 并处理的话单,提供一部分话单合并功能(如仅对一个节点产生的话单进行合并处理,节点之间话单不 合并) ,或者尽可能地完成话单合并功能。 对于 S-GW 之间发生切换,如果要求 CGF 进行话单合并,原则上先完成各自 S-GW 的话单合并。

8.2.5 PGW-CDR 的合并 一次 IP-CAN 承载上下文归口于一个 P-GW, 因此只存在对应同一个 P-GW 的部分 PGW-CDR 的合并问 题。 1. 合并前预处理

CGF 收到 P-GW 发送的 PGW-CDR 话单后,应对 RAT Type 字段进行检查,如果该字段为空或不存在, 应通过 S-GW 地址判断 RAT Type 字段取值,并写入 PGW-CDR 话单; 2. 合并依据

记录中的 P-GW 地址+S-GW 地址+C-ID+ RAT Type 及记录类型(PGW-CDR 记录类型)是合并的依据。 3. 合并触发方式

P-GW 定期(在数十秒到数百秒)向 CGF 发送 CDR,合并可以采用事件触发方式和定期合并方式相结 合的方法,具体实现方法由厂商确定。 合并过程中各字段的处理 4. 无需额外处理的字段 在一次 IP-CAN 承载上下文中, Record Type、 Served IMSI、 Served IMEISV、 Served MSISDN、 Charging
37

ID、P-GW Address、Serving node Address、Serving node Type、 Access Point Name Network Identifier、 APN Selection Mode、PDP/PDN Type、Served PDP/PDN Address、Dynamic Address Flag、Charging Characteristics、Serving node PLMN Identifier、Diagnostics、Charging Characteristics selection mode、Node Id 、RAT Type 、Record Extensions,以上字段保持不变,合并时只需要保留一个。 5. 需要过滤的字段

如果没有发生差错,几个连续的 PGW-CDR 具备合并性。对 Record Opening Time 字段仅保留第一个部 分记录的该字段,后续记录的该字段被过滤,对于一批连续部分话单,Duration 字段 = (最后的部分 记录的 Record Opening Time - 最先的部分记录的 Record Opening Time + 最后的部分记录的 Duration 字 段) ;对于不连续话单 Duration 字段累加。 6. 需要拼接的字段

List of Service Data 字段为一列表,该字段合并实际就是将各列表链接形成一个列表。 对于 Local Record Sequence Number 字段,合并前是整数类型,合并过程中将这些整数拼成一张列表, 在列表首加上本 P-GW 的地址。 对于 Record Sequence Number 字段,合并前是整数类型,合并过程中将这些整数拼成一张列表,在列表 首加上本 P-GW 的地址。 List of Service Data 记录根据是否符合预先设置的流量累计条件选择不同的合并方法。符合流量累计条 件的,上下行流量和 Usage Duration 各自累加,第一个 IP 包时间取最小值,最后一个包时间取最大值, 其他值取合并项中时间最先的表项的值,不符合流量累计条件的,合并成列表,流量类型合并条件可以 配置,可以是业务类别相同或者费率组相同或者都相同。 7. 需要添加的字段

添加合并结果 (ConsolidationResult) 标志, 如果对一次 IP-CAN 承载上下文完成合并, 置正常 (Normal) 标志;如果合并过程中发现错误,置不正常(Abnormal)标志。如果合并后的话单中字段列表域的长 度超过最长范围,那么置超出门限(ReachLimit)标记。

8.

合并流程

第一步:根据 P-GW 地址+ S-GW 地址+C-ID+RAT Type 将原始 PGW-CDR 话单分类 第二步:话单合并,CDR 合并过程中首先看记录的 Record Sequence Number 是否在 Record Sequence Number 列表中存在,如果存在则说明是重复话单,予以剔除,回到第二步;否则将该字段加入列表, 进入第三步。 第三步:比较 Record Opening Time 字段,保留小的(先打开的) ,剔除大的;Duration 字段累加;List of
38

Service Data 记录根据是否符合预先设置的流量累计条件选择不同的合并方法。符合流量累计条件的, 上下行流量和 Usage Duration 各自累加,第一个 IP 包时间取最小值,最后一个包时间取最大值,其他 值取合并项中时间最先的表项的值, 不符合流量累计条件的, 合并成列表, 流量类型合并条件可以配置, 可以是业务类别相同或者费率组相同或者都相同,Cause for Record Closing 字段按优先级顺序保留,优 先级由高到低是:PDP 上下文结束(normalRelease) ,部分话单(Partial record) 。 第四步:每次合并操作后检查 Cause for Record Closing 字段,如果 Cause for Record Closing 字段 =normalRelease,说明本次会话过程结束,则完成合并过程,转第五步。如果 Cause for Record Closing =S-GW Change 或 maxChangeCond 或者 RAT Change, 说明部分话单由于 S-GW 切换或者计费条件改变 次数达到最大值(Qos 改变或者费率时段变更引起)或者无线接入类型改变,则停止继续合并,转第五 步。如果 Cause for Record Closing 字段原因是 Partial record(如 timelimit 或 volumelimit) ,说明还有后 续记录,需要继续合并,转第二步。 第五步:如果合并完成(即 Cause for Record Closing 字段=normalRelease 或者记录量达到门限) ,检查 相同 P-GW 地址+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.2.6 PCNs 与主 CGF 间的通信发生故障的情况 当 PCNs 与主 CGF 间的通信发生故障,CDR 将被传送给备 CGF,这种情况下,主 CGF 与备 CGF 都无 法完成完成的合并,需要 BS 做后续的合并。

9 计费采集接口和协议 CDF、 应有内部存储介质用于话单的存储, 存储介质的容量建议 CDF 可保证本计费点所产生的 CG 话单至少可保存 7 天以上,CG 应能存储 30 天以上的话单。这些存储介质应有充分的热备份设置。 CDF 与 CGF 之间的通信协议各厂商不完全一致,为了确保设备之间的互操作性,推荐在 Ga 接口 上使用 GTP’作为 CGF 从 CDF 采集计费信息的协议。GTP’协议以 GTP 协议为基础,针对计费问题
39

作了相应的补充和修正。此外也可以采用 FTP 接口采集话单。 GTP’协议包含以下功能: ? ? ? 在 CDF 与 CGF 之间传送 CDR 将 CDR 重定向到另一个 CGF 检测 CDR 传输通路正常与否 当端点(CDF 或 CGF)从不可用状态恢复为正常状态后,它应该能够通知对端可以恢复数据的传 送; 当 CGF 存在冗余配置时,对传往 BS 的 CDR 要尽量避免重复。 9.1 GTP’协议栈 9.1.1 S-GW - CGF 协议栈

SGW-CDRs
GTP’

SGW-CDRs
GTP’

UDP/TCP IP L2 L1

UDP/TCP IP L2 L1

S-GW

CGF

图 9-1 S-GW-CGF 的 协议栈 9.1.2 P-GW - CGF 协议栈

40

PGW-CDRs
GTP’

PGW-CDRs
GTP’

UDP/TCP IP L2 L1

UDP/TCP IP L2 L1

P-GW

CGF

图 9-2 P-GW-CGF 的 协议栈 9.2 承载协议 可以用 UDP 或 TCP 协议来承载 GTP’协议,当采用 UDP 协议时,UDP 的目的端口号定为 3386, 即 GTP’协议的端口号,也可以配置定义其它端口号。UDP 的源端口号由发端分配。一旦端口号确定 下来,收端的源端口号采用发端的目的端口号,收端的目的端口号采用发端的源端口号。 如果采用 TCP 协议,端口分配情况与 UDP 一样。 9.3 计费节点的原则 对每个支持 GTP’的节点(S-GW, P-GW, CGF) ,若该节点不能识别另一节点,应能相互发送信息: “Service/Version not supported” 。 在 IP-CAN 承载激活或越 S-GW 切换时, P-GW 可以通知 S-GW 相应的 CGF 地址。 每个 CDF 都可以配置一个 CGF 列表,列表中定义各 CGF 的优先等级,如果主 CGF 退出服务(出 现故障或负荷太重) ,那么 CDF 将把 CDR 送下一级的 CGF,以此类推。 CDF 原则上只能将 CDR 送到位于同一 PLMN 中的 CGF,而不能送到不同 PLMN 的 CGF 中。 9.4 GTP’计费通信协议 GTP’采用 GTP 的协议框架,但仅采用 GTP 协议的信令平面。消息内容部分详见 3GPP TS 29.060. 1、GTP 消息头 下图表示了 GTP’协议头的格式: Bits Octets 1 8 7 Version 6 5 PT 4 3 2 1 “0“
41

Spare “ 1 1 1 “

2 3-4 5-6 以下为各个单元的说明: PT 为”0” ,表示是 GTP’消息; Version 指 GTP’的版本,建议为 GTP’V1; 第一位”0”在 GTP’中未用; Message Type 表示消息类型;

Message Type Length Sequence Number 图 9-3 GTP’协议头的格式

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

2、GTP 消息体
Bits Octets 1 0
8 7 6 5 4 3 2 1

Type -> TV format

Bits Octets 1 1
8 7 6 5 4 3 2 1

Type -> TLV format

图 9-4 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 协议的基础上增加了两类信令消息: 通路管理消息:
42

? ? ? ?

Node Alive Request(MTV=4) Node Alive Response(MTV=5) Redirection Request(MTV=6) Redirection Response(MTV=7)

记录传输消息: ? ? Data Record Transfer Request(MTV=240) Data Record Transfer Response(MTV=241)

1、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

43

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 表 9-1 计费相关的 GTP’消息 Message Type value (Decimal) 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’协议。
44

GTP' message

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

注 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 的消息如下所述: 产生 IP-CAN 承载时:Charging ID,Charging Gateway Address 更新 IP-CAN 承载时:Charging ID,Charging Gateway Address 产生 AA IP-CAN 承载时:Charging ID,Charging Gateway Address (详见 3GPP TS 29.060) 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 的发送间隔,这样减轻网络负荷。 表 9-2 Node Alive Request 消息参数 参数(IE) Node Address Private Extension 9.5.4.2 Node Alive Response Node Alive Response 用于对 Node Alive Request 的响应。 表 9-3 Node Alive Response 消息参数 参数(IE) Private Extension 9.5.4.3 Redirection Request 当 CGF 不能继续正常工作或者 CGF 与后面的系统 (如 BS) 失去联系时, CGF 发 Redirection Request 消息给 CDF,指示 CDF 将 CDR 发送到其它 CGF。 注:指示的 CGF 必须是位于同一个 PLMN 之内的,而不能是位于其它 PLMN 的 CGF。
45

必备(M)/ 任选(O) M O

必备(M)/ 任选(O) O

表 9-4Redirection Request 消息参数 参数(IE) Cause 必备(M)/ 任选(O)

DOCUMENTTYPE

M TypeUnitOrDepartmentHere Address of Recommended Node O TypeYourNameHere Private Extension O 原因码定义: 1 2 3 4 5 This node is about to go down Another node is about to go down System failure Receive buffers becoming full Send buffers becoming full

TypeDateHere

CGF 的地址消息有两种格式:IPv4、 IPv6(见下图)
Bits Oc tets 1 2-3 4-7
8 7 6 5 4 3 2 1

Ty p e = 2 5 4 ( De c ima l) L e n g t h = 4 ( De c ima l) IPv 4 A d d r e s s

图 8-6 CGF 的 IPV4 地址格式

Bits Octets 1 2-3 4-19
8 7 6 5 4 3 2 1

Type = 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)
46

必备(M)/ 任选(O)

Cause Private Extension 原因码定义: 1 2 3 4 5 6 7 8 9 Request Accepted No resources available Service not supported System failure Mandatory IE incorrect Mandatory IE missing Optional IE incorrect Invalid message format Version not supported

M O

9.5.4.5 Data Record Transfer Request 1、背景介绍 正常情况的 GTP’通信过程为:CDF 向 CGF 发送数据包,CGF 返回响应“Request Accepted” 。 冗余 CGF 防止重单进入计费系统的机制介绍: (流程见下图所示,数字表示处理顺序,带”a” 或 “b”的数字,表示可选顺序) ? ? ? ? 发送 CDR 给 CGF1,没有返回成功响应的消息 重试后,仍无响应 发送该 CDR 给 CGF2(标记为可能为重单) CGF2 返回接收响应的消息

......(CDF 等待 CGF1 的响应,CGF2 将等待进一步处理的消息) ? ? ? ? ? ? CGF1 向 CDF 发送节点活动请求的消息 CDF 向 CGF1 发送节点活动接收的消息 用相同的序列号发送空包 CGF1 返回:a)返回接收该包的消息;b)返回该包为重包的消息 CDF 根据 CGF1 的返回消息,向 CGF2 发送消息 a)提交处理该包;b)停止处理该包 CGF2 返回请求接收的消息

注:2b)和 11a)为可能向计费系统发送 CDR 的处理

47

异常处理:缺省情况下,超时将重发 CDR。 若发送 CDR 给 CGF1 和 CGF2 都失败,CDF 将尝试 CGF3。 若未收到(10),CDF 将不断重发(9a)或(9b) 若 CDF-CGF 通讯联接断,CDF 将向管理平台发告警,管理平台进行后续处理

图 8-8 冗余 CGF 防止重单的机制 CGF 冗余机制详述:

如果是网络原因, CGF 可能无法在额定时间内对 CDF 的请求消息响应。 根据 3GPP TS 29.060, CDF 将再试一次。若 CDF 联接 CGF 失败,它将尝试下一个 CGF。

48

序列号缓冲:若联接失败,CDF 将无法和主 CGF 通信。在重试失败后,CDF 将 CDR 重发到次 CGF。 CDF 在内部缓冲中维护了主 CGF 未响应的请求的序列号,以等待该 CGF 恢复后再行处理。同时,CDF 在内部缓冲中也维护了发送到次 CGF 的数据包的序列号(若到次 CGF 的通信也失败,CDF 将与下一 个 CGF 进行通信) 。另外 CGF 在内部缓冲中也维护了每个 CDF 联接的序列号,以用于可能的 CDF 重 单处理:若主 CGF 未成功处理,次 CGF 可将 CDR 提交到计费系统;若主 CGF 处理成功,次 CGF 取 消该 CDR 的处理。 当接收到主 CGF 的响应后,CDF 可以取消次 CGF 对 CDR 的处理。为确认 CDR 的处理情况,CDF 向 主 CGF 发送测试包(带有消息: ”Send possibly duplicated Data Record Packet” ,并和先前的包有相同的 序列号) ,若主 CGF 返回响应”Request Accepted” ,CDF 将通知次 CGF 提交 CDR 并发送到计费系统; 若主 CGF 返回响应” Request related to possibly duplicated packets already fulfilled “,CDF 将通知次 CGF 取消 CDR 处理。 为避免 CDF 异常时(序列号缓冲坏或重包)CDR 一直驻留在 CGF 中,须通过清理 CGF 缓冲的方法。 为了避免以下情况:直到 CDR 的最后一个序列号产生,CDF 的备份缓冲一直都不能正常使用。必须有 可配置的参数去控制 CGF 决定是否将 CDR 发送到计费系统。使操作员可进行以下操作: 通过配置可以使 CDF 和 CGF 进行排除重单,计费系统不必排除 CGF 冗余引起的重单。 通过配置可以使计费系统进行排除重单。为更有效地排除重单,CGF 可以在可能的重单后加标记(该 标记不应出现在 CDF 为计费系统提供的内容中) (也可以用特殊的文件名进行标识) 尽管重单有标记, 。 计费系统也会多一些额外的工作。 同时, 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 参数意义如下:
49

必备(M)/ 任选(O)/ 特定条件必须(C) M C C C O

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 消息参数

4、Data Record Packet 参数 当 Packet Transfer Command 为”Send Data Record Packet”或”Send possibly duplicated Data Record Packet”时,Data Record Packet 出现在消息体中。 Data Record Packet 的内容如下图所示:

50

Bits Octets 1 2...3 4 5 6...7 8...9 10...n
8 7 6 5 4 3 2 1

Type = 252 (Decimal) Length
Number of Data Records Data Record Format Data RecordFormat Version

Length of Data Record 1 Data Record 1

x...x+1 x+2...y

Length of Data Record N Data Record N

图 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 参数的序列号 比 特 字节 1 2…3 4…5 8 7 6 5 4 3 2 1

Type=249(十进制) Length Sequence Number 1

n…n+1

Sequence Number N 图 8-11 Released Packets 消息参数

6、Cancelled Packets 参数的序列号 比 特 字节 1 2…3 4…5 8 7 6 5 4 3 2 1

Type=250(十进制) Length Sequence Number 1
51

n…n+1 7、Private Extension 参数

Sequence Number N 图 8-12 Canceled Packets 消息参数

Private Extension 包含了用户或运营商的特殊信息。 9.5.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 2 3 4 5 6 7 8 9 Request Accepted No resources available Service not supported System failure Mandatory IE incorrect Mandatory IE missing Optional IE incorrect Invalid message format Version not supported 必备(M)/ 任选(O)/ 特定条件必须(C) M M O

10 Request not fulfilled 11 CDR decoding error

12 Request already fulfilled 13 Request related to possibly duplicated packet already fulfilled

原因码“CDR decoding error”为可选,用来通知 CDF 不能解析它的 CDR。 Data Record Transfer Response 涉及的参数如图所示: 比 特
52

字节 1 2…3 4…5

8

7

6

5

4

3

2

1

Type=253(十进制) Length Sequence Number 1

n…n+1

Sequence Number N 图 8-12 Requests Responded 消息参数

Private Extension 包含了用户或运营商的特殊信息。 若产生的原因码级别高或出现频率高,CDF 可以选择另一个 CGF。 9.5.5 重复话单传送的防止 以下例子说明了 3 种 Data Record Transfer Request/Response 情况: ? 正常情况 CDR 的传送 CDF 发送 CDR 到 CGF 成功并接收到正确响应,不需作重发处理 ? CDR 未正确接收前 CDF-CGF1 之间的连接中断 发送 CDR 已失败,且未接收到 CGF 响应。 ? CDR 已经正确接收后 CDF-CGF1 之间链路中断 CGF 已接收 CDR 成功,但发送接收成功响应时和 CDF 通信中断。 以下为这 3 种情况的处理流程: 9.5.5.1 正常情况 CDR 的传送 以下为处理顺序图:

53

CDF 1. Data Record Transfer Request: Send Data Record Packet

CGF’s volatile memory

Non-volatile CGF memory

2. CDRs are stored in a secure way 3. Data Record Transfer Response: Request Accepted

4. < Succesfully sent CDRs are deleted from the CDF buffers >

...

...

图 8-13 正常情况 CDR 的传送处理顺序图 以下为对各个处理的说明: 1) 2) 3) 4) CDF 发送 CDR 到 CGF,发送的相应的消息为”Send Data Record Packet” 。 CGF 处理消息,并存储 CDR 到本地。 CGF 发送响应消息到 CDF ,消息内容为”Request Accepted” CDF 接收消息”Request Accepted”后,从缓冲内删除该 CDR

GTP’接收响应时失败,会在额定时间内和达到设定次数前重新发送请求。 9.5.5.2 CDR 未正确接收前 CDF-CGF1 之间的连接中断 以下为处理顺序图:

54

CDF

CGF1

CGF2

CDR postprocessing system

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 CDF 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 CDF 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 未正确接收前 CDF-CGF1 之间的连接中断时的处理顺序图 以下为对各个处理的说明: 1) CDF 向 CGF1 (主用 CGF) Data Record Transfer Request 消息, 发 其中 Packet Transfer Command 参数是 Send Data Record Packet。 2) 因为 CDF 与 CGF1 之间失去联系,CGF1 没有将 CDR 安全保存。 3) CDF 无法收到响应或者收到”No resources available”之类的拒绝响应。 4) CDF 检测与备用 CGF2 之间的链路(用 Echo Request) ,如果正常则 CDF 将与送往 CGF1 相同 的 CDR 送往 CGF2, 使用 Data Record Transfer Request 消息, Packet Transfer Command 参数是 Send possible duplicated Data Record Packet。

55

5) CGF2 处理接收到的 CDR,因为该分组被标识为 possible duplicated,虽然 CGF2 保存该分组, 但是不立刻送往 BS。 6) CGF2 送正确接收确认信息给 CDF,采用 Data Record Transfer Response 消息,Cause 参数置为 Request Accepted。 7) CDF 可以将成功发送的 CDR(但可能重复)删除,但是仍然保留该分组的序列号(Sequence Number) 。 8) CGF1 恢复以后,向 CDF 送 Node Alive Request 消息,CDF 知道又可以与 CGF 进行通信。 9) CDF 采用 Node Alive Response 消息确认。 10) 对于前面未得到确认的 Data Record Transfer Request 消息,CDF 向 CGF1 发送空的测试分组, 空分组仅仅是 Data Record Packet 参数中不包含 CDR 负载,其它都一样。 11) CGF1 以 Data Record Transfer Response 消息响应,Cause 参数置为 Request Accepted。因为在 CGF1 保存 CDR 之前,CGF1 已经与 CDF 失去联系,所以对于测试分组它认为是新的分组予以接 受。 12) CDF 知道 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 向 CDF 发 Data Record Transfer Response 消息,Cause 参数置为 Request Accepted。

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

9.5.5.3 CDR 已经正确接收后 CDF-CGF1 之间链路中断 以下为处理顺序图:

56

CDF

CGF1

CGF2

CDR postprocessing system

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 CDF, 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 CDF 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. <The cancelled packet(s) are deleted in CGF2 > 14. Data Record Transfer Response: Request Accepted . . . . . .

图 8-15 CDR 已经正确接收后 CDF-CGF1 之间链路中断的处理顺序图 以下为对各个处理的说明: 1)CDF 向 CGF1(主用 CGF)发 Data Record Transfer Request 消息,Packet Transfer Command 参 数是 Send Data Record Packet。 2)CGF1 将 CDR 安全保存。 3)CDF 与 CGF1 之间通信中断,CDF 无法收到 Cause 参数置为 Request Accepted 的 Data Record Transfer Response 消息响应, 4) CDF 检测与备用 CGF2 之间的链路(用 Echo Request) ,如果正常则 CDF 将与送往 CGF1 相同 的 CDR 送往 CGF2, 使用 Data Record Transfer Request 消息, Packet Transfer Command 参数是 Send

57

possible duplicated Data Record Packet。 5) CGF2 处理接收到的 CDR,因为该分组被标识为 possible duplicated,虽然 CGF2 保存该分组, 但是不立刻送往 BS。 6)CGF2 送正确接收确认信息给 CDF,采用 Data Record Transfer Response 消息,Cause 参数置为 Request Accepted。 7) CDF 可以将成功发送的 CDR(但可能重复)删除,但是仍然保留该分组的序列号(Sequence Number) 。 8) CGF1 恢复以后,向 CDF 送 Node Alive Request 消息,CDF 知道又可以与 CGF 进行通信。 9)CDF 采用 Node Alive Response 消息确认 10)对于前面未得到确认的 Data Record Transfer Request 消息,CDF 向 CGF1 发送空的测试分组, 空分组仅仅是 Data Record Packet 参数中不包含 CDR 负载,其它都一样。 11)CGF1 以 Data Record Transfer Response 消息响应,Cause 参数置为 Request related to possibly duplicated packets already fulfilled。因为在 CGF1 与 CDF 失去联系之前,CGF1 已经保存 CDR,所 以对于测试它告知 CDF 该可能重复分组已经正确传送。 12)CDF 知道 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 向 CDF 发 Data Record Transfer Response 消息,Cause 参数置为 Request Accepted。

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

9.5.6 备份方式对话单合并的影响 CGF 采用备份工作方式是非常必要的,本节论述如何解决备份工作方式可能带来的重单,备份工作方 式也会造成 CDR 分布在不同的 CGF 中,这会对话单合并带来一定的影响,如果一次 IP-CAN 承载涉及 两个 CGF,其情况阐述如下: CDF 向 CGF1(主用 CGF)发送话单,如果 CGF1 不能继续接收话单, CGF1 向 CDF 发送 Redirection 则 Request 消息, 消息中携带 Address of Recommended Node 参数, 该参数指示了下面 CDF 可以传送的 CGF 地址。 CGF1 发出 Redirection Request 消息的原因有多种,有可能 CGF1 不能继续工作,但是对于 CGF1 已经
58

接收的话单是不能丢失的。当 CGF1 恢复后,仍然执行话单合并的工作。 CDF 继续向 CGF2 发送话单,CGF2 完成剩余话单的合并。 因为重定向的 CGF2 必须与 CGF1 位于同一 BS 中,因此由 BS 的预处理部分完成剩余的合并工作。

9.6 GTP 的记录格式 从 CDF 发送到 CGF 的 CDR 格式由 8 字节组成,值域为 1-255 的十进制数,标准中只使用 1-10 和 51-255,11-50 为运营商使用,值”1”说明使用 ASN.1 格式,其它情况见下节。 (参见”Data Record Packet 参数”图中的第 5 个 8 位位组) 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 的版本 (其结构见如图所示) 。
Data Record Packet IE Bits Octets 6 7
8 7 6 5 4 3 2 1

Application Identifier

Release Identifier

Version Identifier

图 9-16 Data Record Format Version 格式 说明: 若为计费作用,话单的 Application 标识为”1” (十进制) ;其它作用,Application 标识为其它值。 Release 标识为顺从的技术规范的 Release 号,即技术规范版本号的第一个数字,如”8.5.0”,Release 标 识为 8。 Version 标识为顺从的技术规范的 Version 号加 1,即技术规范版本号的第二个数字加 1,如”8.5.0”, Version 标识为 6。 技术规范版本号的第二个数字可能为字母,则 Version 标识为字母的 ASCII 码。

59

9.8 CGF - BS 协议接口 建议采用基于 TCP/IP 的 FTP;或者 TCP/IP 的 FTAM。

10 话单类型 10.1 类型列表 10.1.1 SGW-CDR 表 10-1 字段名 属 性 M M OC M M OM M S-GW IP CAN 承载数据(SGW-CDR) 描述

Record Type Served IMSI Served IMEISV S-GW Address used Charging ID PDN Connection Id Serving Node Address

表示本话单是SGW-CDR 用户的IMSI 如果能够提供,该字段记录移动设备的IMEISV 使用的S-GW的控制面IP地址 IP CAN承载标识用来识别PCNs创建的不同IP CAN承载 该字段包含PDN连接标识,用来识别属于同一个PDN连接的不同话单 在此记录期间使用的服务节点(如:SGSN、MME…)的控制面IP地 址的列表 在控制面的服务节点类型的列表,列表中的服务节点类型与 “Serving Node Address”字段中的服务节点地址一一对应 当S-GW改变后的第一张部分话单中将出现 P-GW使用的PLMN标识(MCC MNC) APN的网络标识部分

Serving Node Type

M

S-GW Change PGW PLMN Identifier Access Point Name Network Identifier PDP/PDN Type Served PDP/PDN Address

OC OC OM

OM OC

该字段指示PDN类型(如IPv4,IPv6,IPv4v6) 如果能够提供,该字段记录IP-CAN承载/PDN连接分配的IP地址,如 IPv4或IPv6 表示IP CAN承载激活、初始附着和UE请求PDN连接时分配的IP是否 是动态的。如果是静态的,该字段就不出现 IP CAN承载中的计费条件改变的列表,每个改变都包含时间戳。计 费条件用来为数据流量分类,如每个费率时段。最初和后续改变的

Dynamic Address Flag

OM

List

of

Traffic

Data

OM

60

Volumes Record Opening Time MS Time Zone Duration Cause for Record Closing Diagnostics Record Sequence Number Node ID Record Extensions Local Record Number Sequence M OC M M OM C OM OC OM

QoS和对应的数据流量都列出来。 记录打开时间 如果可以提供,该字段记录MS当前所在的时区 本话单的持续时长 本话单关闭的原因 连接释放更详细的原因 部分话单的序列号,仅在部分话单中出现 S-GW的名称 由网络或制造商定义的一系列的话单扩展信息 该节点为所有话单类型产生的序列号

APN Selection Mode Served MSISDN User Information Location

OM OM OC

APN选择模式 用户的MSISDN 如果可以提供,该字段记录用户的位置信息,GPRS场景的定义见TS 29.060,EPC场景见TS 29.274 此IP CAN承载应用的计费特性 计费特性的选择模式

Charging Characteristics Charging Characteristics Selection Mode IMS Signalling Context

M OM

OC

当IM-CN子系统信令标志被置位时,该字段表示IP CAN承载用于IMS 信令 P-GW的控制面IP地址 如果可以提供,该字段记录本话单使用的服务节点PLMN标识(MCC 和MNC) 如果可以提供, 该字段指示MS当前使用的无线接入技术类型 (RAT) , GTP场景下的定义见29.060, eGTP场景见29.274, PMIP场景见29.275 用户IP-CAN会话开始的时间,该字段出现在IP-CAN会话第一个承载 的话单中 用户IP-CAN会话终止的时间,该字段出现在IP-CAN会话最后一个承 载的话单中

P-GW Address used. Serving Node Identifier RAT Type PLMN

OC OC

OC

Start Time

OC

Stop Time

OC

话单格式遵循3GPP TS32.251-860及TS32.298-850规定(2009年6月份版本)。 10.1.2 PGW-CDR
61

表 10-2 P-GW IP CAN 承载数据(PGW-CDR) 字段名 属 性 M M OC OC OC M M OM M M 描述

Record Type Served IMSI Served IMEISV Served 3GPP2 MEID Served MN NAI P-GW Address used Charging ID PDN Connection Id Serving Node Address Serving Node Type

表示本话单是PGW-CDR 用户的IMSI 如果能够提供,该字段记录移动设备的IMEISV 用户终端设备的MEID,用于3GPP2访问 如果能够提供,该字段记录NAI格式的移动节点标识(基于IMSI) 使用的P-GW的控制面IP地址 IP CAN承载标识用来识别PCNs创建的不同IP CAN承载 该字段包含PDN连接标识,用来识别属于同一个PDN连接的不同话单 在此记录期间使用的SGSN、S-GW的控制面IP地址的列表 在控制面的服务节点类型的列表,列表中的服务节点类型与 “Serving Node Address”字段中的服务节点地址一一对应 P-GW使用的PLMN标识(MCC MNC) APN的网络标识部分

PGW PLMN Identifier Access Point Name Network Identifier PDP/PDN Type Served PDP/PDN Address

OC OM

OM OC

该字段指示PDN类型(如IPv4,IPv6,IPv4v6) 如果能够提供,该字段记录IP-CAN承载/PDN连接分配的IP地址,如 IPv4或IPv6 表示IP CAN承载激活、初始附着和UE请求PDN连接时分配的IP是否 是动态的。如果是静态的,该字段就不出现 IP CAN承载中的所有业务数据流计费条件改变的列表,按每个费率 组或每个费率组和业务键的组合进行分类,每个改变都包含时间 戳。计费条件用来为数据流量、共用时间和事件次数分类,如每个 费率时段。最初和后续改变的QoS和对应的数据流量都列出来 在线计费信息(PS Furnish Charging Information),可能加入 每个业务数据流的容器中,万一OCS发送了这些信息 Failure-Handling:该字段将出现,万一P-GW触发了失败控制过程

Dynamic Address Flag

OM

List of Service Data

OM

Record Opening Time MS Time Zone

M OC

记录打开时间 如果可以提供,该字段记录MS当前所在的时区

62

Duration Cause for Record Closing Diagnostics Record Sequence Number Node ID Record Extensions Local Record Number Sequence

M M OM C OM OC OM

本话单的持续时长 本话单关闭的原因 连接释放更详细的原因 部分话单的序列号,仅在部分话单中出现 P-GW的名称 由网络或制造商定义的一系列的话单扩展信息 该节点为所有话单类型产生的序列号

APN Selection Mode Served MSISDN User Information Location

OM OM OC

APN选择模式 用户的MSISDN 如果可以提供,该字段记录用户的位置信息,GPRS场景的定义见TS 29.060,EPC场景见TS 29.274 此IP CAN承载应用的计费特性 计费特性的选择模式

Charging Characteristics Charging Characteristics Selection Mode IMS Signalling Context

M OM

OC

当IM-CN子系统信令标志被置位时,该字段表示IP CAN承载用于IMS 信令 从非EPC、外部网络实体收到的计费标识,如ICID

External Identifier Serving Node Identifier PS Furnish Information

Charging

OC

PLMN

Om

该字段记录本话单使用的服务节点PLMN标识(MCC和MNC)

Charging

OC

在线计费会话特定的信息

CAMEL Information RAT Type

OC OC

与IP CAN承载相关的一组CAMEL信息,该字段仅适用与GPRS 如果可以提供, 该字段指示MS当前使用的无线接入技术类型 (RAT) , GTP场景下的定义见29.060, eGTP场景见29.274, PMIP场景见29.275 用户IP-CAN会话开始的时间,该字段出现在IP-CAN会话第一个承载 的话单中 用户IP-CAN会话终止的时间,该字段出现在IP-CAN会话最后一个承 载的话单中

Start Time

OC

Stop Time

OC

话单格式遵循3GPP TS32.251-860及TS32.298-850规定(2009年6月份版本)。 10.1.3 经 CGF 处理后的 SGW-CDR
63

表 10-3 字段名 属 性 M M OC M M OM M 描述

经 CGF 处理后的 SGW-CDR

Record Type Served IMSI Served IMEISV S-GW Address used Charging ID PDN Connection Id Serving Node Address

表示本话单是SGW-CDR 用户的IMSI 如果能够提供,该字段记录移动设备的IMEISV 使用的S-GW的控制面IP地址 IP CAN承载标识用来识别PCNs创建的不同IP CAN承载 该字段包含PDN连接标识,用来识别属于同一个PDN连接的不同话单 在此记录期间使用的服务节点(如:SGSN、MME…)的控制面IP地 址的列表 在控制面的服务节点类型的列表,列表中的服务节点类型与 “Serving Node Address”字段中的服务节点地址一一对应 当S-GW改变后的第一张部分话单中将出现 P-GW使用的PLMN标识(MCC MNC) APN的网络标识部分

Serving Node Type

M

S-GW Change PGW PLMN Identifier Access Point Name Network Identifier PDP/PDN Type Served PDP/PDN Address

OC OC OM

OM OC

该字段指示PDN类型(如IPv4,IPv6,IPv4v6) 如果能够提供,该字段记录IP-CAN承载/PDN连接分配的IP地址,如 IPv4或IPv6 表示IP CAN承载激活、初始附着和UE请求PDN连接时分配的IP是否 是动态的。如果是静态的,该字段就不出现 IP CAN承载中的计费条件改变的列表,每个改变都包含时间戳。计 费条件用来为数据流量分类,如每个费率时段。最初和后续改变的 QoS和对应的数据流量都列出来。 记录打开时间 如果可以提供,该字段记录MS当前所在的时区 本话单的持续时长 本话单关闭的原因 连接释放更详细的原因 部分话单的序列号,仅在部分话单中出现

Dynamic Address Flag

OM

List of Volumes

Traffic

Data

OM

Record Opening Time MS Time Zone Duration Cause for Record Closing Diagnostics Record Sequence Number

M OC M M OM C

64

Node ID Record Extensions Local Record Number Sequence

OM OC OM

S-GW的名称 由网络或制造商定义的一系列的话单扩展信息 该节点为所有话单类型产生的序列号

APN Selection Mode Served MSISDN User Information Location

OM OM OC

APN选择模式 用户的MSISDN 如果可以提供,该字段记录用户的位置信息,GPRS场景的定义见TS 29.060,EPC场景见TS 29.274 此IP CAN承载应用的计费特性 计费特性的选择模式

Charging Characteristics Charging Characteristics Selection Mode IMS Signalling Context

M OM

OC

当IM-CN子系统信令标志被置位时,该字段表示IP CAN承载用于IMS 信令 P-GW的控制面IP地址 如果可以提供,该字段记录本话单使用的服务节点PLMN标识(MCC 和MNC) 如果可以提供, 该字段指示MS当前使用的无线接入技术类型 (RAT) , GTP场景下的定义见29.060, eGTP场景见29.274, PMIP场景见29.275 用户IP-CAN会话开始的时间,该字段出现在IP-CAN会话第一个承载 的话单中 用户IP-CAN会话终止的时间,该字段出现在IP-CAN会话最后一个承 载的话单中 合并结果

P-GW Address used. Serving Node Identifier RAT Type PLMN

OC OC

OC

Start Time

OC

Stop Time

OC

Consolidation Result

M

10.1.4 经 CGF 处理后的 PGW-CDR 表 10-4 字段名 属 性 M M OC OC 描述 经 CGF 处理后的 PGW-CDR

Record Type Served IMSI Served IMEISV Served 3GPP2 MEID

表示本话单是PGW-CDR 用户的IMSI 如果能够提供,该字段记录移动设备的IMEISV 用户终端设备的MEID,用于3GPP2访问
65

Served MN NAI P-GW Address used Charging ID PDN Connection Id Serving Node Address Serving Node Type

OC M M OM M M

如果能够提供,该字段记录NAI格式的移动节点标识(基于IMSI) 使用的P-GW的控制面IP地址 IP CAN承载标识用来识别PCNs创建的不同IP CAN承载 该字段包含PDN连接标识,用来识别属于同一个PDN连接的不同话单 在此记录期间使用的SGSN、S-GW的控制面IP地址的列表 在控制面的服务节点类型的列表,列表中的服务节点类型与 “Serving Node Address”字段中的服务节点地址一一对应 P-GW使用的PLMN标识(MCC MNC) APN的网络标识部分

PGW PLMN Identifier Access Point Name Network Identifier PDP/PDN Type Served PDP/PDN Address

OC OM

OM OC

该字段指示PDN类型(如IPv4,IPv6,IPv4v6) 如果能够提供,该字段记录IP-CAN承载/PDN连接分配的IP地址,如 IPv4或IPv6 表示IP CAN承载激活、初始附着和UE请求PDN连接时分配的IP是否 是动态的。如果是静态的,该字段就不出现 IP CAN承载中的所有业务数据流计费条件改变的列表,按每个费率 组或每个费率组和业务键的组合进行分类,每个改变都包含时间 戳。计费条件用来为数据流量、共用时间和事件次数分类,如每个 费率时段。最初和后续改变的QoS和对应的数据流量都列出来 在线计费信息(PS Furnish Charging Information),可能加入 每个业务数据流的容器中,万一OCS发送了这些信息 Failure-Handling:该字段将出现,万一P-GW触发了失败控制过程

Dynamic Address Flag

OM

List of Service Data

OM

Record Opening Time MS Time Zone Duration Cause for Record Closing Diagnostics Record Sequence Number Node ID Record Extensions

M OC M M OM C OM OC

记录打开时间 如果可以提供,该字段记录MS当前所在的时区 本话单的持续时长 本话单关闭的原因 连接释放更详细的原因 部分话单的序列号,仅在部分话单中出现 P-GW的名称 由网络或制造商定义的一系列的话单扩展信息

66

Local Record Number

Sequence

OM

该节点为所有话单类型产生的序列号

APN Selection Mode Served MSISDN User Information Location

OM OM OC

APN选择模式 用户的MSISDN 如果可以提供,该字段记录用户的位置信息,GPRS场景的定义见TS 29.060,EPC场景见TS 29.274 此IP CAN承载应用的计费特性 计费特性的选择模式

Charging Characteristics Charging Characteristics Selection Mode IMS Signalling Context

M OM

OC

当IM-CN子系统信令标志被置位时,该字段表示IP CAN承载用于IMS 信令 从非EPC、外部网络实体收到的计费标识,如ICID

External Identifier Serving Node Identifier PS Furnish Information

Charging

OC

PLMN

Om

该字段记录本话单使用的服务节点PLMN标识(MCC和MNC)

Charging

OC

在线计费会话特定的信息

CAMEL Information RAT Type

OC OC

与IP CAN承载相关的一组CAMEL信息,该字段仅适用与GPRS 如果可以提供, 该字段指示MS当前使用的无线接入技术类型 (RAT) , GTP场景下的定义见29.060, eGTP场景见29.274, PMIP场景见29.275 用户IP-CAN会话开始的时间,该字段出现在IP-CAN会话第一个承载 的话单中 用户IP-CAN会话终止的时间,该字段出现在IP-CAN会话最后一个承 载的话单中 合并结果

Start Time

OC

Stop Time

OC

Consolidation Result

M

10.2 话单参数描述 10.2.1 话单字段描述 这章内容是有关前面提到的CDR的每个字段的简要描述。 10.2.2 Access Point Name (APN) Network Identifier 这些字段包含了由手机、SGSN/MME决定或由CAMEL业务修改的实际连接的APN网络/运营商的标识。 APN也可以是一个通配符,这种情况下由SGSN/MME来选择APN。 APN网络标识包含一个或多个标签,在TS 23.003中描述。 在PCN CDRs中为了表达APN NI可以使用"."符号。
67

有关APN的格式及接入点的的选择方法的更多信息,请参考3GPP TS 23.003和3GPP TS 23.060。 10.2.3 APN Selection Mode 这个字段描述了SGSN/MME如何选择使用的APN。 参数的取值及含义在规范3GPP TS 29.060 (GTP情况) 和3GPP TS29.274(eGTP情况)中有所描述。 10.2.4 CAMEL Information 这个字段包括SCDR、MCDR、S-SMS-CDR的以下CAMEL信息元。 CAMEL Access Point Name NI (S-CDR) 这个字段包含了APN中被SCF修改前的网络标识。 CAMEL Access Point Name OI (S-CDR) 这个字段包含了APN中被SCF修改前的运营商标识。 CAMEL Calling Party Number (S-SMO-CDR) 这个字段包含了由CAMEL业务修改的主叫号码。 CAMEL Destination Subscriber Number (S-SMO-CDR) 这个字段包含了由CAMEL业务修改的短消息目的号码。 CAMEL SMSC Address (S-SMO-CDR) 这个字段包含了由CAMEL业务修改的SMSC地址。 SCF address (S-CDR, M-CDR, S-SMO-CDR) 这个字段表示为用户服务的CAMEL服务器。地址作为CAMEL签约信息的一部分在 HLR中定义。 Service key (S-CDR, M-CDR, S-SMO-CDR) 这个字段表示所使用的CAMEL业务逻辑。业务键作为CAMEL签约信息的一部分在 HLR中定义。 Default Transaction/SMS Handling (S-CDR, M-CDR, S-SMO-CDR) 这个字段表示CAMEL是否遇到缺省的GPRS或SMS处理。 该字段只有在缺省呼叫处理时出现。 参数作为 CAMEL签约信息的一部分在 HLR中定义。 Free Format Data (S-CDR, M-CDR, S-SMO-CDR) 这个字段包含在由gsmSCF发送的提供GPRS计费信息 (FCI) 这个CAP操作中 (3GPP TS 29.078中定义) 。 数据可以在一个FCI消息或几个FCI消息中发送,并添加标识符。这个数据在相关呼叫记录的CAMEL session中透明传输。 如果在一个CAME呼叫中不只一次收到FCI,附加的标识符定义该FCI信息是否被添加到前一个FCI, 并且存到相关的记录或最后收到的FCI的信息被存到相关的记录(前一个FCI的信息应被覆盖)。 在部分话单事件中,目前有效的'Free format data'存放在部分话单中。 FFD Append Indicator (S-CDR, M-CDR) 这个字段包含了一个标识符表明CAMEL自由格式数据是否附加到前一个部分话单所存储的自由格式 数据。 计费后处理系统需要该字段以便从部分话单中过滤出呼叫分支的有效的自由格式数据。 部分话单 的产生不取决于所收到的FCI,所以有效的自由格式数据可能被分为不同的包含话单记录。 如果字段丢失, 那么这个CDR中的自由格式数据将替换所有以前的CDR中的自由数据格式。 添加的标 识符在第一个部分话单中不需要。如果那个部分话单过程中所有收到的FCI已添加了标识符,在以下的 部分话单中标识符应得到真实值。如果那个部分话单过程中收到的一个或多个FCI没有添加标识符,那 么这个字段空缺。 Level of CAMEL services (S-CDR, M-CDR) 这个字段简单描述了CAMEL调用的复杂性。 分级与电路域的业务相同, VPLMN请求的资源使用测量在 HPLMN中完成。 ‘Basic’是指只有在IP-CAN承载激活阶段CAMEL的功能被调用(如修改 APN_NI / APN_OI)。

68

‘Call duration supervision’是指在VPLMN的 gprsSSF中使用IP-CAN承载或流量 监控。(使用从 gsmSCF 接收到的计费消息) Number of DP encountered (S-CDR, M-CDR) 这个字段表示相隔多久CAMEL检查点(TDP和EDP)遇到一次, 并且衡量VPLMN 之间的信令及CAMEL业务 和补充‘Level of CAMEL service’字段。 10.2.5 Cause for Record Closing 这个字段包含了话单关闭的原因,包括以下内容: - 正常释放:IP-CAN承载释放或附着分离 - 数据流量达到门限 - 时间(持续时长) 达到门限 - 计费条件改变次数达到最大值 - 无线接入技术类型(RAT)改变 - 异常中断(IP-CAN承载或MM) - S-GW切换 - 时区改变 - SGSN或S-GW PLMN改变 - 管理干涉(出于 O&M 原因) 更详尽的原因有可能在诊断字段中找到。 10.2.6 Charging Characteristics 计费特性字段允许运营商给CDR应用不同的计费方法。 用户的签约信息可能包含计费特性,这些特性作为签约信息的一部分由HLR/HSS提供给SGSN/MME, 然后上激活到IP-CAN承载,根据TS 32.251的附录A,SGSN/MME将计费特性发送给P-GW/S-GW。PCNs可以 使用这些信息激活话单产生机制, 例如控制话单或数据流量容器的关闭, 使用Ga接口把话单传输给话单 处理节点(如CGF或计费系统)。话单处理节点也可以使用这些信息改变话单处理的优先级和路径。 计费特性字段的格式在下图中描述,Px (x=0?3),表示计费特性的取值,“B”字段可由运营商自 行定义。

Bits Octets
1 7
B4

6
B3

5
B2

4
B1

3
P3

2
P2

1
P1

0
P0

2

B12 B11 B10 B9

B8

B7

B6

B5

图10-1 计费特性标志 10.2.7 Charging Characteristics Selection Mode 这个字段表示PCNs在话单中应用的计费特性类型。 在S-GW/P-GW,它的取值可为: - Home default; - Visiting default; - Roaming default;
69

-

Serving node supplied.

10.2.8 Charging ID 这个字段是计费标识,可以与P-GW地址一起用来识别一个IP-CAN承载在SGSN(s)、S-GW和P-GW上产 生的所有话单记录。 Charging ID 在IP-CAN承载激活时由P-GW产生并且传送到相应的SGSN/S-GW。在跨 SGSN/S-GW之间切换时,Charging ID作为激活的IP-CAN承载一个部分一起传送到新的SGSN/S-GW。 不同的P-GW独立地产生自己的Charging ID, 并且可能产生相同的数字。 CGF 和/或计费系统可以通 过Charging ID及P-GW地址来检查话单的唯一性,如果还无法确定,可以选择根据话单的产生时间来判 断。 10.2.9 Consolidation Result 该字段是一次IP-CAN承载产生的部分话单的合并结果标志, 如果对一次IP-CAN承载完成合并, 置正 常(Normal)标志;如果合并过程中发现错误,置不正常(NotNormal)标志。如果合并后的话单长度 超过最长话单范围,那么置超出门限(ReachLimit)标记。 10.2.10 Diagnostics 这个字段包括了连接释放的更具体的技术原因,可参考3GPP TS 32.205。 诊断消息还可被扩充,以便包含厂家及网络的特定信息。 10.2.11 Duration 这个字段包含了IP-CAN承载(SGW-CDR,PGW-CDR)以秒为单位的时长,对于部分话单,时长是指单个 部分话单的时长而不是累计的时长。 内部的时间测量可能是以十分之一秒甚至毫秒表示的,因此,时长的计算可能出现取整情况。由于 以下限制: 1) 如果所传送的数据流量比零大,允许接受零秒话单 2) 对于所有话单,应采用同样的取整方法 取整方式,本文件不予规定。 10.2.12 Dynamic Address Flag 这个字段表明为该IP-CAN承载(PDN连接)分配的PDN地址是动态分配的。如果地址是静态的,这个 字段不出现。 10.2.13 External Charging Identifier 从非EPC的外部网络实体接收到的计费标识。 当与IMS互连时,外部计费标识为ICID(IMS计费标识),该值由IMS网元传递给P-GW。 10.2.14 IMS Signalling Context 指示该IP-CAN承载被用于IMS信令传输。仅当IP-CAN承载作为IMS信令承载时出现。一个用于IMS信 令的IP-CAN承载的建立在手机向网络发送的 “Active PDP context request” 消息中设置 “IM CN Subsytem Signnalling Flag”标志实现。 10.2.15 List of Service Data 这个列表包含一个或多个业务数据容器,依赖于PCC规则的上报级别,一个业务数据容器或者包含 一个费率组的计费数据, 或者包含一个费率组和业务键的组合的计费数据。 每个业务数据容器包含以下 字段: AF-Record-Information Charging Rule Base Name Data Volume Downlink
70

Data Volume Uplink Event Based Charging Information Local Sequence Number PS Furnish Charging Information Qos Information Rating Group Report Time Result Code Service Condition Change Service Identifier Service Specific Info Serving Node Address Time of First Usage Time of Last Usage Time Quota Mechanism Time Usage user location information Rating Group: 是费率组的标识, 这个字段是必选的, 相当于TS 23.203中详细说明的Charging Key。 Charging Rule Base Name:是PCEF预定义的PCC规则组的参考。任何一个PCC规则是使用TS 29.212 中说明的Charging Rule Base Name来激活的,需要报告使用的业务数据容器将包含该字段。假如多个 Charging Rule Base Name激活了PCC规则,P-GW在需要报告使用的业务数据容器中只包含一个。 Result Code:包含与OCS互连的结果码,如果在线和离线计费都使用同样的费率组,该字段可能增 加到业务数据容器中。 Local Sequence Number:是业务数据容器的序列号,在这个IP-CAN承载的生命周期内产生的每个 业务数据容器从1开始并按1累加。 Time of First Usage:业务数据容器所对应的第一个IP包传输时的时间戳。 Time of Last Usage:业务数据容器所对应的最后一个IP包传输时的时间戳。 Time Usage:包含业务数据容器中的有效使用时间。 Service Condition Change: 定义业务数据容器关闭的原因, 如费率时段改变, IP-CAN承载改变 (如 QoS改变、S-GW切换,用户位置改变)等等。该字段指定为比特掩码以支持多个改变触发(如S-GW和QoS 改变) Qos Information:包含此IP-CAN承载采用的协商QoS。 Serving Node Address:包含有效的服务节点(如SGSN/S-GW)的控制面IP地址。 Data Volume Uplink and Downlink:包含此业务数据容器记录期间传输的字节数,在上行、下行 方向分别计数。 Report Time:定义业务数据容器关闭时的时间戳。 Service Identifier:是业务的标识。 PS Furnish Charging Information:包含每个费率组的计费信息如果OCS发送。 User location information:包含业务数据容器记录期间用户所在的位置信息。 AF-Record-Information:包含"AF Charging Identifier"(IMS的ICID)和AF产生的相关流标识和 P-GW从Gx接口接收到的。 Event Based Charging Information:包含事件次数和相关的时间戳。 Time Quota Mechanism:包含两个子字段,需要封包上报时才出现。
71

Time Quota Type:标识需上报哪种基于时间的使用机制,在3GPP TS 32.299中定义。 Base Time Interval:标识控制上报基于时间的使用的基准时间间隔的长度,以秒为单位。 Service Specific Info:包含业务特定的预定义PCC规则,以用来增强包过滤。 10.2.16 List of Traffic Data Volumes 这个列表适用于S-CDR和SGW-CDR,包括一个或多个容器(container),每个容器中包括以下字段: Data Volume Uplink,Data Volume Downlink,Change Condition,Change Time。 Data Volume Uplink: 上行数据流量包括了使用分组业务过程中在上行方向所传送的字节数。 在MBMS 计费中,该字段一般置为0,因为MBMS计费是基于下行数据的流量。上行数据流量的计数是可选的。当 SGSN在RNC和P-GW之间成功地建立了直接隧道(Direct Tunnel),S-CDR中的该字段为0或不出现。 Data Volume Downlink:下行数据流量包括了使用分组业务过程中在下行方向所传送的字节数。当 SGSN在RNC和P-GW之间成功地建立了直接隧道(Direct Tunnel),S-CDR中的该字段为0或不出现。 Change Condition:改变条件定义了容器关闭的原因,如费率时间改变、QoS改变或CDR关闭。 Change Time:改变时间是一个时间戳,它定义了新的流量开始记录或CDR关闭的时刻。所有激活的 IP-CAN承载没有必要因为同一个费率改变而拥有完全一致的时间戳。 User Location Information:用户位置信息只适用于SGW-CDR,包含容器统计的数据流量传输时用 户所在的位置(如CGI/SAI,ECGI/TAI或RAI)。该字段仅在前一个容器的改变条件为"user location change"时在数据流量容器中出现。注意SGW-CDR中的用户位置信息主要级别包含PGW-CDR打开后的用户 位置。 EPC QoS Information:假如IP-CAN明确,容器将包含IP-CAN承载授权的QoS,每个QCI/ARP对的第 一个容器包含此字段,后续的容器中此字段只在前面的改变条件为“QoS change”时才出现。这个字段 只适用与SGW-CDR。 第一个容器包括以下可选字段:QoS Requested(不出现在SGW-CDR)和QoS Negotiated。在后面的容 器中如果前一个变化条件是 “QoS change” QoS Negotiated字段将出现。 , 如果变化条件是 “QoS change” , 并且QoS变化是由手机通过IP-CAN承载修改进程发起的, 那么除QoS Negotiated字段以外, Requested QoS 字段也要在后面的容器中表示出来。 以下是一个列表的例子,其中有五个容器,是由于一次QoS改变、一次位置改变、一次费率时段变 化和一次DT建立而产生的(DT改变仅适用于S-CDR)。当话单打开时,用户的位置是CGI1。 表 10-5 话务数据流量列表举例
QoS Requested = QoS1 QoS Requested = QoS2 (if requested by the MS) QoS Negotiated = QoS1 QoS Negotiated = QoS2

Data Volume Uplink = 1 Data Volume Downlink = 2

Data Volume Uplink = 5 Data Volume Downlink = 6

Data Volume Uplink = 10 Data Volume Downlink = 3

Change Condition = QoS change Time Stamp = TIME1

Change Condition = Tariff change Time Stamp = TIME2

Change Condition = CGI/SAI Change Time Stamp = TIME3

72

Data Volume Uplink = 3 Data Volume Downlink = 4 Change Condition = Record closed User Location Info = CGI2 Time Stamp = TIME5

Change Condition = Direct Tunnel establishment Occurrence Time Stamp = TIME4

第一个容器包括初始的QoS值和与之相应的流量计数,第二个容器包括费率时间变换前新的 QoS值 和与之相应的流量计数,第三个容器包括位置改变的指示和费率时段改变后、位置改变前的流量计数, 第四个容器包括位置改变后的流量计数和DT建立的指示, 因为建立了DT最后一个容器没有流量计数。 下 表分项列出了总的流量计数(费率时段改变前使用Tariff1,改变后使用Tariff2): 表 10-6 QoS 值和流量统计
Container QoS1+Tariff1 QoS2+Tariff1 QoS2+Tariff2 QoS1 QoS2 Tariff1 Tariff2 CGI1 CGI2 No Direct Tunnel Direct Tunnel uplink = 1, downlink = 2 uplink = 5, downlink = 6 uplink = 13, downlink = 7 uplink = 1, downlink = 2 uplink = 18, downlink = 13 uplink = 6, downlink = 8 uplink = 13, downlink = 7 uplink = 16, downlink = 11 uplink = 3, downlink = 4 uplink = 19, downlink = 15 -, 1 2 3+4 1 2+3+4 1+2 3+4 1+2+3 4 1+2+3+4 5

S-GW中统计的数据流量应该是用户面S1-U/S4/S2接口上的有效载荷。 所以该数据流量已经包含了IP PDP承载协议,即IP或PPP。 10.2.17 Local Record Sequence Number 这个字段包括了由该节点生成的唯一的记录号码, 号码是为所有话单类型的每个部分话单 (或完整 话单)连续分配的。在一个节点中是唯一的,因此可以和Node ID字段或节点地址(SGSN地址、 S-/P-GW 地址、记录实体)一起来识别话单。 这个字段可以用在后处理系统中,比如识别丢失的话单。 10.2.18 MS Time Zone 这个字段包含了当IP-CAN承载激活/更新过程时由SGSN/MME传送给S-GW/P-GW的消息元“Time Zone”,在规范TS 29.060中定义。 10.2.19 Node ID 这个字段包含产生此话单的节点的可选的、运营商可配置的识别字符串。 Node ID可能是也可能不是节点的DNS主机名。 10.2.20 P-GW Address Used

73

这个字段指当前使用的P-GW的控制面IP地址, 如果P-GW有IPv4地址和IPv6地址, P-GW会将IPv4地址 填入话单。 10.2.21 P-GW PLMN Identifier 这个字段是P-GW PLMN标识(移动国家码和移动网络码)。 10.2.22 PDN Connection ID 这个字段定义了PDN连接(IP-CAN会话)标识,用来识别属于同一个PDN连接的不同话单,包含这个 PDN连接中激活的第一个IP-CAN承载的CID。这个字段与P-GW地址一起唯一识别一个PDN连接。

10.2.23 PDP/PDN Type 这个字段定义了承载类型,如IP,PPP或IHOSS:OSP。对于准确的格式参考: - GTP场景的PDP类型见TS 29.060 - eGTP场景的PDN类型见TS 29.274 - PMIP场景的PDN类型见TS 29.275 10.2.24 PS Furnish Charging Information 这个字段包含以下IP-CAN的信元(PGW-CDR ): ? PS Free Format Data 这个字段包含OCS在Diameter信用控制Credit-Control-Answer消息中发送的计费信息,定义在TS 32.251。这些数据或者是一个Diameter信用控制Credit-Control-Answer消息中发送的,或者是多个 Diameter信用控制Credit-Control-Answer消息带添加指示发送的,这些数据在相关话单的 “PS Furnish Charging Information”字段中透明转换。 如果为建立一个离线会话的IP-CAN承载期间收到了多个“PS Free Format Data”,添加指示表示 “PS Free Format Data”是添加到之前收到的“PS Free Format Data”的后面并保存到相关话单中, 还是最后的“PS Free Format Data”中的信息保存到相关话单中,前面的“PS Free Format Data”信 息被覆盖。 导致部分话单输出的事件时有效的“PS Free Format Data”保存在这个部分话单中。 ? PS FFD Append Indicator: 这个字段包含一个指示“PS Free Format Data”是否添加到前面的部分话单中的“PS Free Format Data”。这个字段在话单后处理从IP-CAN承载的一系列部分话单中挑选有效的“PS Free Format Data” 时是必须的。 部分话单的产生独立于 “PS Free Format Data” 的收到, 因此有效的 “PS Free Format Data” 可能分散在不同的部分话单中。 如果该字段不出现,这个话单中的“PS Free Format Data”替换前面收到的所有话单中的“PS Free Format Data”。第一张部分话单中不需要添加指示,如果在那个部分话单输出期间收到的“PS Free Format Data”有添加指示,随后的部分话单中添加指示应该赋真值。如果在部分话单输出期间,从那 个IP-CAN承载收到的一个或多个“PS Free Format Data”不包含附加标识,则该字段将不出现。 10.2.25 RAT Type 这个字段包含提供给S-GW和P-GW的RAT类型的值,在以下规范中描述: - GTP场景见TS 29.060 - eGTP场景见TS 29.274 - PMIP场景见TS 29.275 该字段由SGSN/MME在IP-CAN承载激活/修改过程中传递给S-GW/P-GW。
74

10.2.26 Record Extensions 这个字段可以让网络运营商和/或厂商在标准的话单上添加自己推荐的内容。 10.2.27 Record Opening Time 这个字段包含了IP-CAN承载在S-GW/P-GW(SGW-CDR, PGW-CDR)激活或后续部分话单打开时的时间 戳。 10.2.28 Record Sequence Number 这个字段包含了部分话单的序列号,用来把SGSN/SGW/PGW为特定的IP-CAN承载产生的部分话单(特 点是Charging ID和PGW地址都相同)连接起来。在S-CDR中,序列号总是在跨SGSN路由区更新时从1开始 产生, 参见"SGSN change"字段。 如果SGSN/SGW/PGW上只产生一个话单, 该字段就不出现。 (比如: 跨SGSN 路由区更新时,可能产生两个没有序列号的S-CDR,并且第二个话单中会出现"SGSN update"字段)。 10.2.29 Record Type 这个字段标识了话单记录的类型,比如:SGW-CDR, PGW-CDR等。 10.2.30 S-GW Address Used 这个字段指当前使用的S-GW的控制面IP地址, 如果S-GW有IPv4地址和IPv6地址, S-GW会将IPv4地址 填入话单。 10.2.31 Served 3GPP2 MEID 这个字段包含用户终端在3GPP2访问中移动设备标识(MEID),内容定义在3GPP TS 29.272。 10.2.32 Served IMEISV 这个字段包含了终端设备的国际移动设备识别码和软件版本号(IMEISV), 在3GPP TS 23.003中定义。 10.2.33 Served IMSI 这个字段包含了接收服务方的国际移动用户识别码(IMSI)。 术语"接收服务方"用来描述与被记录的 事务有关的移动用户,比如移动始发IP-CAN承载中的主叫用户。 IMSI的结构在3GPP TS 23.003中定义。 10.2.34 Served MN NAI 这个字段包含用户的移动标识,以NAI格式基于IMSI,定义在3GPP TS 23.003。 10.2.35 Served MSISDN 这个字段包含了接收服务方的移动台(MS)的ISDN号码(MSISDN)。 术语"接收服务方"用来描述与被记 录的事务有关的移动用户。在多号码(multi-numbering)的情况下,主叫话单中存储的MSISDN为主叫方 的基本MSISDN。 MSISDN的结构在3GPP TS 23.003中有所定义。 10.2.36 Served PDP/PDN Address 这个字段包含了PDN连接(IP-CAN承载,IP-CAN承载)使用的IP地址,是网络层地址即IPv4或IPv6 类型。每个承载类型的地址是临时分配的或永久分配的(见"Dynamic Address Flag"字段)。除非承载 类型是PPP并且使用动态地址的情况,该字段都出现。 10.2.37 Serving Node Address 这个字段包含了话单期间连接的一个或多个SGSN、MME、ePDG、HSGW或S-GW的控制面地址。 如果SGSN/S-GW/MME/ePDG/HSGW有IPv4地址和IPv6地址,S-GW/P-GW会将IPv4地址填入话单。 10.2.38 Serving Node PLMN Identifier
75

这个字段包含了服务点(SGSN/S-GW/MME/ePDG/HSGW)的PLMN识别号(MCC移动国家代号和MNC移动 网络代号)。 MCC和MNC的编码在TS 29.060中描述。 10.2.39 Serving Node Type 这个字段包含了话单期间连接的一个或多个S-GW或P-GW控制面的服务节点类型。 列表中的服务节点 类型与“Serving Node Address”字段中的服务节点地址一一对应。 10.2.40 S-GW Change 这个字段只在SGW-CDR中出现,用来标识这是S-GW切换后的第一个话单记录。 10.2.41 Start Time 这个字段包含用户IP-CAN会话在S-GW/P-GW开始的时间,出现在IP-CAN会话第一个承载的话单中。 10.2.42 Stop Time 这个字段包含用户IP-CAN会话在S-GW/P-GW终止的时间, 出现在IP-CAN会话最后一个承载的话单中。 10.2.43 User Location Information 这个字段包含用户位置信息,在以下规范中描述: - GTP场景见TS 29.060(如CGI,SAI,RAI) - eGTP场景见TS 29.274(如CGI,SAI,RAI,TAI和ECGI) - PMIP场景见TS 29.275 该字段由SGSN/MME在IP-CAN承载激活/修改过程中传递给S-GW/P-GW。

11 话单的 ASN.1 描述 11.1 S-GW 和 P-GW 输出 CDR 的 ASN.1 定义
DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-------------------------------------------------------------------------------- GPRS RECORDS -------------------------------------------------------------------------------

GPRSRecord --

::= CHOICE

-- Record values 20, 22..27 are specific -- Record values 76..77 are MBMS specific -- Record values 78..79 are EPC specific {

76

sgsnPDPRecord sgsnMMRecord sgsnSMORecord sgsnSMTRecord sgsnLCTRecord sgsnLCORecord sgsnLCNRecord --sgsnMBMSRecord ggsnMBMSRecord sGWRecord pGWRecord }

[20] SGSNPDPRecord, [22] SGSNMMRecord, [23] SGSNSMORecord, [24] SGSNSMTRecord, [25] SGSNLCTRecord, [26] SGSNLCORecord, [27] SGSNLCNRecord,

[76] SGSNMBMSRecord, [77] GGSNMBMSRecord [78] SGWRecord, [79] PGWRecord

SGWRecord {

::= SET

recordType servedIMSI s-GWAddress chargingID servingNodeAddress accessPointNameNI pdpPDNType servedPDPPDNAddress dynamicAddressFlag listOfTrafficVolumes recordOpeningTime duration causeForRecClosing diagnostics recordSequenceNumber nodeID recordExtensions localSequenceNumber apnSelectionMode servedMSISDN chargingCharacteristics chChSelectionMode iMSsignalingContext servingNodePLMNIdentifier servedIMEISV rATType mSTimeZone userLocationInformation

[0] RecordType, [3] IMSI, [4] GSNAddress, [5] ChargingID, [6] SEQUENCE OF GSNAddress, [7] AccessPointNameNI OPTIONAL, [8] PDPType OPTIONAL, [9] PDPAddress OPTIONAL, [11] DynamicAddressFlag OPTIONAL, [12] SEQUENCE OF ChangeOfCharCondition OPTIONAL, [13] TimeStamp, [14] CallDuration, [15] CauseForRecClosing, [16] Diagnostics OPTIONAL, [17] INTEGER OPTIONAL, [18] NodeID OPTIONAL, [19] ManagementExtensions OPTIONAL, [20] LocalSequenceNumber OPTIONAL, [21] APNSelectionMode OPTIONAL, [22] MSISDN OPTIONAL, [23] ChargingCharacteristics, [24] ChChSelectionMode OPTIONAL, [25] NULL OPTIONAL, [27] PLMN-Id OPTIONAL, [29] IMEI OPTIONAL, [30] RATType OPTIONAL, [31] MSTimeZone OPTIONAL, [32] OCTET STRING OPTIONAL,

77

sGWChange servingNodeType p-GWAddressUsed p-GWPLMNIdentifier startTime stopTime pDNConnectionID

[34] SGWChange OPTIONAL, [35] SEQUENCE OF ServingNodeType, [36] GSNAddress OPTIONAL, [37] PLMN-Id OPTIONAL, [38] TimeStamp OPTIONAL, [39] TimeStamp OPTIONAL, [40] ChargingID OPTIONAL

}

PGWRecord {

::= SET

recordType servedIMSI p-GWAddress chargingID servingNodeAddress accessPointNameNI pdpPDNType servedPDPPDNAddress dynamicAddressFlag recordOpeningTime duration causeForRecClosing diagnostics recordSequenceNumber nodeID recordExtensions localSequenceNumber apnSelectionMode servedMSISDN chargingCharacteristics chChSelectionMode iMSsignalingContext externalChargingID servinggNodePLMNIdentifier pSFurnishChargingInformation servedIMEISV rATType mSTimeZone userLocationInformation cAMELChargingInformation listOfServiceData servingNodeType

[0] RecordType, [3] IMSI, [4] GSNAddress, [5] ChargingID, [6] SEQUENCE OF GSNAddress, [7] AccessPointNameNI OPTIONAL, [8] PDPType OPTIONAL, [9] PDPAddress OPTIONAL, [11] DynamicAddressFlag OPTIONAL, [13] TimeStamp, [14] CallDuration, [15] CauseForRecClosing, [16] Diagnostics OPTIONAL, [17] INTEGER OPTIONAL, [18] NodeID OPTIONAL, [19] ManagementExtensions OPTIONAL, [20] LocalSequenceNumber OPTIONAL, [21] APNSelectionMode OPTIONAL, [22] MSISDN OPTIONAL, [23] ChargingCharacteristics, [24] ChChSelectionMode OPTIONAL, [25] NULL OPTIONAL, [26] OCTET STRING OPTIONAL, [27] PLMN-Id OPTIONAL, [28] PSFurnishChargingInformation OPTIONAL, [29] IMEI OPTIONAL, [30] RATType OPTIONAL, [31] MSTimeZone OPTIONAL, [32] OCTET STRING OPTIONAL, [33] OCTET STRING OPTIONAL, [34] SEQUENCE OF ChangeOfServiceCondition OPTIONAL, [35] SEQUENCE OF ServingNodeType,

78

servedMNNAI p-GWPLMNIdentifier startTime stopTime served3gpp2MEID pDNConnectionID

[36] SubscriptionID OPTIONAL, [37] PLMN-Id OPTIONAL, [38] TimeStamp OPTIONAL, [39] TimeStamp OPTIONAL, [40] OCTET STRING OPTIONAL, [41] ChargingID OPTIONAL

}

-------------------------------------------------------------------------------- Generic Data Types -------------------------------------------------------------------------------

CallDuration --

::= INTEGER

-- The call duration is counted in seconds. -- For successful calls /sessions / PDP contexts, this is the chargeable duration. -- For call attempts this is the call holding time. --

RecordType { -----

::= INTEGER

Record values 18..22 are GPRS specific. The contents are defined in TS 32.251 [11]

SGSNPDPRecord SGSNMMRecord SGSNSMORecord SGSNSMTRecord

(18), (20), (21), (22),

sGWRecord pGWRecord }

(84), (85)

Diagnostics { gsm0408Cause -- See TS 24.008 [64] gsm0902MapErrorValue

::= CHOICE

[0] INTEGER,

[1] INTEGER,

-- Note: The value to be stored here corresponds to -- the local values defined in the MAP-Errors and

79

-- MAP-DialogueInformation modules, for full details -- see TS 29.002 [60]. itu-tQ767Cause -- See ITU-T Q.767 [67] networkSpecificCause [3] ManagementExtension, [2] INTEGER,

-- To be defined by network operator manufacturerSpecificCause [4] ManagementExtension,

-- To be defined by manufacturer positionMethodFailureCause -- see TS 29.002 [60] unauthorizedLCSClientCause -- see TS 29.002 [60] } [6] UnauthorizedLCSClient-Diagnostic [5] PositionMethodFailure-Diagnostic,

IPAddress {

::= CHOICE

iPBinaryAddress

IPBinaryAddress, IPTextRepresentedAddress

iPTextRepresentedAddress }

IPBinaryAddress ::= CHOICE { iPBinV4Address iPBinV6Address } [0] OCTET STRING (SIZE(4)), [1] OCTET STRING (SIZE(16))

IPTextRepresentedAddress { --

::= CHOICE

-- IP address in the familiar "dot" notation -iPTextV4Address iPTextV6Address } [2] IA5String (SIZE(7..15)), [3] IA5String (SIZE(15..45))

LocalSequenceNumber ::= INTEGER (0..4294967295) --- Sequence number of the record in this node -- 0.. 4294967295 is equivalent to 0..2**32-1, unsigned integer in four octets

MSISDN --

::= ISDN-AddressString

-- See TS 23.003 [68] --

80

MSTimeZone --

::= OCTET STRING (SIZE (2))

-- 1.Octet: Time Zone and 2. Octet: Daylight saving time, see TS 29.060 [75] --

TimeStamp --

::= OCTET STRING (SIZE(9))

-- The contents of this field are a compact form of the UTCTime format -- containing local time plus an offset to universal time. Binary coded -- decimal encoding is employed for the digits to reduce the storage and -- transmission overhead -- e.g. YYMMDDhhmmssShhmm -- where -- YY -- MM -- DD -- hh -- mm -- ss -- S -- hh -- mm -= = = = = = = = = Year 00 to 99 Month 01 to 12 Day 01 to 31 hour 00 to 23 minute 00 to 59 second 00 to 59 Sign 0 = "+", "-" hour 00 to 23 minute 00 to 59 BCD encoded BCD encoded BCD encoded BCD encoded BCD encoded BCD encoded ASCII encoded BCD encoded BCD encoded

-------------------------------------------------------------------------------- PS DATA TYPES -------------------------------------------------------------------------------

AccessPointNameNI --

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

-- Network Identifier part of APN in dot representation. -- 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.. --

AFChargingIdentifier ::= OCTECT STRING --- see AF-Charging-Identifier AVP as defined in TS 29.214[89] --

AFRecordInformation ::= SEQUENCE {

81

aFChargingIdentifier flows }

[1] AFChargingIdentifier, [2] Flows OPTIONAL

APNSelectionMode::= ENUMERATED { --- See Information Elements TS 29.060 [75], TS 29.274 [91] or TS 29.275 [92] -mSorNetworkProvidedSubscriptionVerified mSProvidedSubscriptionNotVerified networkProvidedSubscriptionNotVerified } (0), (1), (2)

CAMELAccessPointNameNI

::= AccessPointNameNI

CAMELAccessPointNameOI

::= AccessPointNameOI

CAMELInformationPDP ::= SET { sCFAddress serviceKey defaultTransactionHandling cAMELAccessPointNameNI cAMELAccessPointNameOI numberOfDPEncountered levelOfCAMELService freeFormatData fFDAppendIndicator } [1] SCFAddress OPTIONAL, [2] ServiceKey OPTIONAL, [3] DefaultGPRS-Handling OPTIONAL, [4] CAMELAccessPointNameNI OPTIONAL, [5] CAMELAccessPointNameOI OPTIONAL, [6] NumberOfDPEncountered OPTIONAL, [7] LevelOfCAMELService OPTIONAL, [8] FreeFormatData OPTIONAL, [9] FFDAppendIndicator OPTIONAL

CauseForRecClosing { --

::= INTEGER

-- In PGW-CDR and SGW-CDR the value servingNodeChange is used for partial record -- generation due to Serving Node Address list Overflow -- In SGSN servingNodeChange indicates the SGSN change --- LCS related causes belong to the MAP error causes acc. TS 29.002 [60] --- cause codes 0 to 15 are defined 'CauseForTerm' (cause for termination) -normalRelease abnormalRelease (0), (4),

82

cAMELInitCallRelease volumeLimit timeLimit servingNodeChange maxChangeCond managementIntervention intraSGSNIntersystemChange rATChange mSTimeZoneChange sGSNPLMNIDChange unauthorizedRequestingNetwork unauthorizedLCSClient positionMethodFailure unknownOrUnreachableLCSClient listofDownstreamNodeChange }

(5), (16), (17), (18), (19), (20), (21), (22), (23), (24), (52), (53), (54), (58), (59)

ChangeCondition ::= ENUMERATED { qoSChange tariffTime recordClosure cGI-SAICHange rAIChange dT-Establishment dT-Removal eCGIChange tAIChange userLocationChange } (0), (1), (2), (6), -- bearer modification. “CGI-SAI Change” (7), -- bearer modification. “RAI Change” (8), (9) (10), (11), (12) -- bearer modification. “ECGI Change” -- bearer modification. “TAI Change” -- bearer modification. “User Location Change”

ChangeOfCharCondition { --

::= SEQUENCE

-- qosRequested and qosNegotiated are used in S-CDR only -- ePCQoSInformation used in SGW-CDR only -qosRequested qosNegotiated dataVolumeGPRSUplink dataVolumeGPRSDownlink changeCondition changeTime userLocationInformation ePCQoSInformation [1] QoSInformation OPTIONAL, [2] QoSInformation OPTIONAL, [3] DataVolumeGPRS OPTIONAL, [4] DataVolumeGPRS OPTIONAL, [5] ChangeCondition, [6] TimeStamp, [8] OCTET STRING OPTIONAL, [9] EPCQoSInformation OPTIONAL

83

}

ChangeOfServiceCondition { --

::= SEQUENCE

-- Used for Flow based Charging service data container -ratingGroup chargingRuleBaseName resultCode localSequenceNumber timeOfFirstUsage timeOfLastUsage timeUsage serviceConditionChange qoSInformationNeg servingNodeAddress datavolumeFBCUplink datavolumeFBCDownlink timeOfReport failureHandlingContinue serviceIdentifier pSFurnishChargingInformation aFRecordInformation userLocationInformation eventBasedChargingInformation timeQuotaMechanism serviceSpecificInfo } [1] RatingGroupId, [2] ChargingRuleBaseName OPTIONAL, [3] ResultCode OPTIONAL, [4] LocalSequenceNumber OPTIONAL, [5] TimeStamp OPTIONAL, [6] TimeStamp OPTIONAL, [7] CallDuration OPTIONAL, [8] ServiceConditionChange, [9] EPCQoSInformation OPTIONAL, [10] GSNAddress OPTIONAL, [12] DataVolumeGPRS OPTIONAL, [13] DataVolumeGPRS OPTIONAL, [14] TimeStamp, [16] FailureHandlingContinue OPTIONAL, [17] ServiceIdentifier OPTIONAL, [18] PSFurnishChargingInformation OPTIONAL, [19] SEQUENCE OF AFRecordInformation OPTIONAL, [20] OCTER STRING OPTIONAL, [21] EventBasedChargingInformation OPTIONAL, [22] TimeQuotaMechanism OPTIONAL, [23] SEQUENCE OF ServiceSpecificInfo OPTIONAL

ChargingCharacteristics ::= OCTET STRING (SIZE(2)) ----Bit 0-3: Profile Index Bit 4-15: For Behavior

ChargingID --

::= INTEGER (0..4294967295)

-- Generated in P-GW, part of IP CAN bearer -- 0..4294967295 is equivalent to 0..2**32-1 --

ChargingRuleBaseName ::= IA5String (SIZE(1..16)) --- identifier for the group of charging rules -- see Charging-Rule-Base-Name AVP as desined in TS 29.212 [88]

84

--

ChChSelectionMode { servingNodeSupplied subscriptionSpecific aPNSpecific homeDefault roamingDefault visitingDefault }

::= ENUMERATED

(0), (1), (2), (3), (4), (5)

-- For S-GW/P-GW -- For SGSN only -- For SGSN only -- For SGSN, S-GW and P-GW -- For SGSN, S-GW and P-GW -- For SGSN, S-GW and P-GW

DataVolumeGPRS --

::= INTEGER

-- The volume of data transferred in octets. --

DynamicAddressFlag

::= BOOLEAN

EPCQoSInformation { --

::= SEQUENCE

-- See TS 29.212 [88] for more information -qCI maxRequestedBandwithUL maxRequestedBandwithDL guaranteedBitrateUL guaranteedBitrateDL aRP } [1] INTEGER, [2] INTEGER OPTIONAL, [3] INTEGER OPTIONAL, [4] INTEGER OPTIONAL, [5] INTEGER OPTIONAL, [6] INTEGER OPTIONAL

ETSIAddress ::= AddressString --- First octet for nature of address, and numbering plan indicator (3 for X.121) -- Other octets TBCD -- See TS 29.002 [60]

--

EventBasedChargingInformation ::= SEQUENCE { numberOfEvents eventTimeStamps } [1] INTEGER, [2] SEQUENCE OF TimeStamp OPTIONAL

85

FailureHandlingContinue ::= BOOLEAN --- This parameter is included when the failure handling procedure has been executed and new -- containers are opened. This parameter shall be included in the first and subsequent -- containers opened after the failure handling execution. --

FFDAppendIndicator

::= BOOLEAN

Flows ::= --

SEQUENCE

-- See Flows AVP as defined in TS 29.214 [89] -{ mediaComponentNumber flowNumber } [1] INTEGER, [2] SEQUENCE OF INTEGER OPTIONAL

FreeFormatData --

::= OCTET STRING (SIZE(1..160))

-- Free formatted data as sent in the FurnishChargingInformationGPRS -- see TS 29.078 [66] --

GSNAddress

::= IPAddress

NodeID

::= IA5String (SIZE(1..20))

NumberOfDPEncountered ::= INTEGER

PDPAddress {

::= CHOICE

iPAddress eTSIAddress }

[0] IPAddress, [1] ETSIAddress

PDPType --

::= OCTET STRING (SIZE(2))

-- OCTET 1: PDP Type Organization -- OCTET 2: PDP/PDN Type Number -- See TS 29.060 [75] for GTP, TS 29.274 [91] clause 8.14 for eGTP and TS 29.275 [92] for PMIP --

PLMN-Id

::= OCTET STRING (SIZE (3))

86

--This is a 1:1 copy from the Routing Area Identity (RAI) IE specified in TS 29.060 [75]

-- as follows: ----OCTET 1 of PLMN-Id = OCTET 2 of RAI OCTET 2 of PLMN-Id = OCTET 3 of RAI OCTET 3 of PLMN-Id = OCTET 4 of RAI

PSFurnishChargingInformation ::= SEQUENCE { pSFreeFormatData pSFFDAppendIndicator } [1] FreeFormatData, [2] FFDAppendIndicator OPTIONAL

QoSInformation --

::= OCTET STRING (SIZE (4..255))

-- This octet string -- is a 1:1 copy of the contents (i.e. starting with octet 5) of the "Bearer Quality of -- Service" information element specified in TS 29.274 [92]. --

RatingGroupId ::= INTEGER --- IP service flow identity (DCCA), range of 4 byte (0...4294967259) -- see Rating-Group AVP as used in TS 32.299 [40] --

RATType ::= INTEGER (0..255) --- Ihis integer is 1:1 copy of the RAT type value as defined in TS 29.060 [75] for GTP, -- TS 29.274 [91] for eGTP and TS 29.275 [92] for PMIP. --

ResultCode ::= INTEGER --- charging protocol return value, range of 4 byte (0...4294967259) -- see Result-Code AVP as used in 3GPP 32.299 [40] --

ServiceConditionChange { qoSChange sGSNChange sGSNPLMNIDChange

::= BIT STRING

(0), (1), (2),

-- bearer modification -- bearer modification -- bearer modification

87

tariffTimeSwitch pDPContextRelease rATChange serviceIdledOut reserved configurationChange serviceStop dCCATimeThresholdReached dCCAVolumeThresholdReached

(3), (4), (5), (6),

-- tariff time change -- bearer release -- bearer modification

-- IP flow idle out, DCCA QHT expiry -- old: QCTexpiry is no report event

(7), (8), (9),

-- configuration change -- IP flow termination -- DCCA quota reauthorization -- DCCA quota reauthorization -- DCCA quota reauthorization -- DCCA quota reauthorization

(10), (11),

dCCAServiceSpecificUnitThresholdReached (12), dCCATimeExhausted dCCAVolumeExhausted dCCAValidityTimeout reserved1 (13), (14), (15),

-- DCCA quota reauthorization -- DCCA quota validity time (QVT expiry) -- reserved due to no use case, -- old: return Requested is covered by (17),(18)

(16),

dCCAReauthorisationRequest dCCAContinueOngoingSession

(17), (18),

-- DCCA quota reauthorization request by OCS -- DCCA failure handling (CCFH), -- continue IP flow

dCCARetryAndTerminateOngoingSession

(19),

-- DCCA failure handling (CCFH), -- terminate IP flow after DCCA retry

dCCATerminateOngoingSession

(20),

-- DCCA failure handling, -- terminate IP flow

cGI-SAIChange rAIChange dCCAServiceSpecificUnitExhausted recordClosure timeLimit volumeLimit serviceSpecificUnitLimit envelopeClosure eCGIChange tAIChange userLocationChange } --

(21), (22), (23), (24), (25), (26), (27), (28) (29), (30), (31)

-- bearer modification.“CGI-SAI Change” -- bearer modification.“RAI Change” -- DCCA quota reauthorization -- PGW-CDR closure -- intermediate recording -- intermediate recording -- intermediate recording

-- bearer modification. “ECGI Change” -- bearer modification. “TAI Change” -- bearer modification. “User Location Change”

-- Trigger and cause values for IP flow level recording are defined for support of independent -- online and offline charging and also for tight interworking between online and offline charging. -- Unused bits will always be zero. -- Some of the values are non-exclusive (e.g. bearer modification reasons). --

SCFAddress --

::= AddressString

-- See TS 29.002 [60] --

88

ServiceIdentifier --

::= INTEGER (0..4294967295)

-- The service identifier is used to identify the service or the service component -- the service data flow relates to. See Service-Identifier AVP as defined -- in TS 29.212 [88] --

ServingNodeType ::= ENUMERATED { sGSN pMIPSGW gTPSGW ePDG hSGW mME } (0), (1), (2), (3), (4), (5)

SGWChange --

::= BOOLEAN

-- present if first record after inter S-GW change --

TimeQuotaMechanism { timeQuotaType baseTimeInterval }

::= SEQUENCE

[1] TimeQuotaType, [2] Integer

TimeQuotaType {

::= ENUMERATED

dISCRETE_TIME_PERIOD cONTINUOUS_TIME_PERIOD }

(0), (1)

END

11.2 CGF 输出 CDR 的 ASN.1 定义
DEFINITIONS IMPLICIT TAGS ::=

BEGIN

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

89

--- GPRS RECORDS -------------------------------------------------------------------------------

GPRSRecord --

::= CHOICE

-- Record values 20, 22..27 are specific -- Record values 76..77 are MBMS specific -- Record values 78..79 are EPC specific { sgsnPDPRecord sgsnMMRecord sgsnSMORecord sgsnSMTRecord sgsnLCTRecord sgsnLCORecord sgsnLCNRecord --sgsnMBMSRecord ggsnMBMSRecord sGWRecord pGWRecord } [76] SGSNMBMSRecord, [77] GGSNMBMSRecord [78] SGWRecord, [79] PGWRecord [20] SGSNPDPRecord, [22] SGSNMMRecord, [23] SGSNSMORecord, [24] SGSNSMTRecord, [25] SGSNLCTRecord, [26] SGSNLCORecord, [27] SGSNLCNRecord,

SGWRecord {

::= SET

recordType servedIMSI s-GWAddress chargingID servingNodeAddress accessPointNameNI pdpPDNType servedPDPPDNAddress dynamicAddressFlag listOfTrafficVolumes recordOpeningTime duration causeForRecClosing diagnostics recordSequenceNumber nodeID recordExtensions

[0] RecordType, [3] IMSI, [4] GSNAddress, [5] ChargingID, [6] SEQUENCE OF GSNAddress, [7] AccessPointNameNI OPTIONAL, [8] PDPType OPTIONAL, [9] PDPAddress OPTIONAL, [11] DynamicAddressFlag OPTIONAL, [12] SEQUENCE OF ChangeOfCharCondition OPTIONAL, [13] TimeStamp, [14] CallDuration, [15] CauseForRecClosing, [16] Diagnostics OPTIONAL, [17] RECORDSequenceNumber OPTIONAL, [18] NodeID OPTIONAL, [19] ManagementExtensions OPTIONAL,

90

localSequenceNumber apnSelectionMode servedMSISDN chargingCharacteristics chChSelectionMode iMSsignalingContext servingNodePLMNIdentifier servedIMEISV rATType mSTimeZone userLocationInformation sGWChange servingNodeType p-GWAddressUsed p-GWPLMNIdentifier startTime stopTime pDNConnectionID

[20] LOCALRECORDSequenceNumber OPTIONAL, [21] APNSelectionMode OPTIONAL, [22] MSISDN OPTIONAL, [23] ChargingCharacteristics, [24] ChChSelectionMode OPTIONAL, [25] NULL OPTIONAL, [27] PLMN-Id OPTIONAL, [29] IMEI OPTIONAL, [30] RATType OPTIONAL, [31] MSTimeZone OPTIONAL, [32] OCTET STRING OPTIONAL, [34] SGWChange OPTIONAL, [35] SEQUENCE OF ServingNodeType, [36] GSNAddress OPTIONAL, [37] PLMN-Id OPTIONAL, [38] TimeStamp OPTIONAL, [39] TimeStamp OPTIONAL, [40] ChargingID OPTIONAL,

consolidationResult }

[101] ConsolidationResult

PGWRecord {

::= SET

recordType servedIMSI p-GWAddress chargingID servingNodeAddress accessPointNameNI pdpPDNType servedPDPPDNAddress dynamicAddressFlag recordOpeningTime duration causeForRecClosing diagnostics recordSequenceNumber nodeID recordExtensions localSequenceNumber apnSelectionMode servedMSISDN chargingCharacteristics chChSelectionMode

[0] RecordType, [3] IMSI, [4] GSNAddress, [5] ChargingID, [6] SEQUENCE OF GSNAddress, [7] AccessPointNameNI OPTIONAL, [8] PDPType OPTIONAL, [9] PDPAddress OPTIONAL, [11] DynamicAddressFlag OPTIONAL, [13] TimeStamp, [14] CallDuration, [15] CauseForRecClosing, [16] Diagnostics OPTIONAL, [17] RECORDSequenceNumber OPTIONAL, [18] NodeID OPTIONAL, [19] ManagementExtensions OPTIONAL, [20] LOCALRECORDSequenceNumber OPTIONAL, [21] APNSelectionMode OPTIONAL, [22] MSISDN OPTIONAL, [23] ChargingCharacteristics, [24] ChChSelectionMode OPTIONAL,

91

iMSsignalingContext externalChargingID servinggNodePLMNIdentifier pSFurnishChargingInformation servedIMEISV rATType mSTimeZone userLocationInformation cAMELChargingInformation listOfServiceData servingNodeType servedMNNAI p-GWPLMNIdentifier startTime stopTime served3gpp2MEID pDNConnectionID

[25] NULL OPTIONAL, [26] OCTET STRING OPTIONAL, [27] PLMN-Id OPTIONAL, [28] PSFurnishChargingInformation OPTIONAL, [29] IMEI OPTIONAL, [30] RATType OPTIONAL, [31] MSTimeZone OPTIONAL, [32] OCTET STRING OPTIONAL, [33] OCTET STRING OPTIONAL, [34] SEQUENCE OF ChangeOfServiceCondition OPTIONAL, [35] SEQUENCE OF ServingNodeType, [36] SubscriptionID OPTIONAL, [37] PLMN-Id OPTIONAL, [38] TimeStamp OPTIONAL, [39] TimeStamp OPTIONAL, [40] OCTET STRING OPTIONAL, [41] ChargingID OPTIONAL,

consolidationResult }

[101] ConsolidationResult

-------------------------------------------------------------------------------- Generic Data Types -------------------------------------------------------------------------------

CallDuration --

::= INTEGER

-- The call duration is counted in seconds. -- For successful calls /sessions / PDP contexts, this is the chargeable duration. -- For call attempts this is the call holding time. --

RecordType { -----

::= INTEGER

Record values 18..22 are GPRS specific. The contents are defined in TS 32.251 [11]

SGSNPDPRecord SGSNMMRecord SGSNSMORecord SGSNSMTRecord

(18), (20), (21), (22),

92

sGWRecord pGWRecord }

(84), (85)

Diagnostics { gsm0408Cause -- See TS 24.008 [64] gsm0902MapErrorValue

::= CHOICE

[0] INTEGER,

[1] INTEGER,

-- Note: The value to be stored here corresponds to -- the local values defined in the MAP-Errors and -- MAP-DialogueInformation modules, for full details -- see TS 29.002 [60]. itu-tQ767Cause -- See ITU-T Q.767 [67] networkSpecificCause [3] ManagementExtension, [2] INTEGER,

-- To be defined by network operator manufacturerSpecificCause [4] ManagementExtension,

-- To be defined by manufacturer positionMethodFailureCause -- see TS 29.002 [60] unauthorizedLCSClientCause -- see TS 29.002 [60] } [6] UnauthorizedLCSClient-Diagnostic [5] PositionMethodFailure-Diagnostic,

IPAddress {

::= CHOICE

iPBinaryAddress

IPBinaryAddress, IPTextRepresentedAddress

iPTextRepresentedAddress }

IPBinaryAddress ::= CHOICE { iPBinV4Address iPBinV6Address } [0] OCTET STRING (SIZE(4)), [1] OCTET STRING (SIZE(16))

IPTextRepresentedAddress { --

::= CHOICE

-- IP address in the familiar "dot" notation -iPTextV4Address iPTextV6Address [2] IA5String (SIZE(7..15)), [3] IA5String (SIZE(15..45))

93

}

LocalSequenceNumber ::= INTEGER (0..4294967295) --- Sequence number of the record in this node -- 0.. 4294967295 is equivalent to 0..2**32-1, unsigned integer in four octets

MSISDN --

::= ISDN-AddressString

-- See TS 23.003 [68] --

MSTimeZone --

::= OCTET STRING (SIZE (2))

-- 1.Octet: Time Zone and 2. Octet: Daylight saving time, see TS 29.060 [75] --

TimeStamp --

::= OCTET STRING (SIZE(9))

-- The contents of this field are a compact form of the UTCTime format -- containing local time plus an offset to universal time. Binary coded -- decimal encoding is employed for the digits to reduce the storage and -- transmission overhead -- e.g. YYMMDDhhmmssShhmm -- where -- YY -- MM -- DD -- hh -- mm -- ss -- S -- hh -- mm -= = = = = = = = = Year 00 to 99 Month 01 to 12 Day 01 to 31 hour 00 to 23 minute 00 to 59 second 00 to 59 Sign 0 = "+", "-" hour 00 to 23 minute 00 to 59 BCD encoded BCD encoded BCD encoded BCD encoded BCD encoded BCD encoded ASCII encoded BCD encoded BCD encoded

-------------------------------------------------------------------------------- PS DATA TYPES -------------------------------------------------------------------------------

AccessPointNameNI --

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

94

-- Network Identifier part of APN in dot representation. -- 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.. --

AFChargingIdentifier ::= OCTECT STRING --- see AF-Charging-Identifier AVP as defined in TS 29.214[89] --

AFRecordInformation ::= SEQUENCE { aFChargingIdentifier flows } [1] AFChargingIdentifier, [2] Flows OPTIONAL

APNSelectionMode::= ENUMERATED { --- See Information Elements TS 29.060 [75], TS 29.274 [91] or TS 29.275 [92] -mSorNetworkProvidedSubscriptionVerified mSProvidedSubscriptionNotVerified networkProvidedSubscriptionNotVerified } (0), (1), (2)

CAMELAccessPointNameNI

::= AccessPointNameNI

CAMELAccessPointNameOI

::= AccessPointNameOI

CAMELInformationPDP ::= SET { sCFAddress serviceKey defaultTransactionHandling cAMELAccessPointNameNI cAMELAccessPointNameOI numberOfDPEncountered levelOfCAMELService freeFormatData fFDAppendIndicator } [1] SCFAddress OPTIONAL, [2] ServiceKey OPTIONAL, [3] DefaultGPRS-Handling OPTIONAL, [4] CAMELAccessPointNameNI OPTIONAL, [5] CAMELAccessPointNameOI OPTIONAL, [6] NumberOfDPEncountered OPTIONAL, [7] LevelOfCAMELService OPTIONAL, [8] FreeFormatData OPTIONAL, [9] FFDAppendIndicator OPTIONAL

CauseForRecClosing

::= INTEGER

95

{ --- In PGW-CDR and SGW-CDR the value servingNodeChange is used for partial record -- generation due to Serving Node Address list Overflow -- In SGSN servingNodeChange indicates the SGSN change --- LCS related causes belong to the MAP error causes acc. TS 29.002 [60] --- cause codes 0 to 15 are defined 'CauseForTerm' (cause for termination) -normalRelease abnormalRelease cAMELInitCallRelease volumeLimit timeLimit servingNodeChange maxChangeCond managementIntervention intraSGSNIntersystemChange rATChange mSTimeZoneChange sGSNPLMNIDChange unauthorizedRequestingNetwork unauthorizedLCSClient positionMethodFailure unknownOrUnreachableLCSClient listofDownstreamNodeChange } (0), (4), (5), (16), (17), (18), (19), (20), (21), (22), (23), (24), (52), (53), (54), (58), (59)

ChangeCondition ::= ENUMERATED { qoSChange tariffTime recordClosure cGI-SAICHange rAIChange dT-Establishment dT-Removal eCGIChange tAIChange userLocationChange } (0), (1), (2), (6), (7), (8), (9) (10), (11), (12) -- bearer modification. “ECGI Change” -- bearer modification. “TAI Change” -- bearer modification. “User Location Change”

ChangeOfCharCondition {

::= SEQUENCE

96

--- qosRequested and qosNegotiated are used in S-CDR only -- ePCQoSInformation used in SGW-CDR only -qosRequested qosNegotiated dataVolumeGPRSUplink dataVolumeGPRSDownlink changeCondition changeTime userLocationInformation ePCQoSInformation } [1] QoSInformation OPTIONAL, [2] QoSInformation OPTIONAL, [3] DataVolumeGPRS OPTIONAL, [4] DataVolumeGPRS OPTIONAL, [5] ChangeCondition, [6] TimeStamp, [8] OCTET STRING OPTIONAL, [9] EPCQoSInformation OPTIONAL

ChangeOfServiceCondition { --

::= SEQUENCE

-- Used for Flow based Charging service data container -ratingGroup chargingRuleBaseName resultCode localSequenceNumber timeOfFirstUsage timeOfLastUsage timeUsage serviceConditionChange qoSInformationNeg servingNodeAddress datavolumeFBCUplink datavolumeFBCDownlink timeOfReport failureHandlingContinue serviceIdentifier pSFurnishChargingInformation aFRecordInformation userLocationInformation eventBasedChargingInformation timeQuotaMechanism serviceSpecificInfo } [1] RatingGroupId, [2] ChargingRuleBaseName OPTIONAL, [3] ResultCode OPTIONAL, [4] LocalSequenceNumber OPTIONAL, [5] TimeStamp OPTIONAL, [6] TimeStamp OPTIONAL, [7] CallDuration OPTIONAL, [8] ServiceConditionChange, [9] EPCQoSInformation OPTIONAL, [10] GSNAddress OPTIONAL, [12] DataVolumeGPRS OPTIONAL, [13] DataVolumeGPRS OPTIONAL, [14] TimeStamp, [16] FailureHandlingContinue OPTIONAL, [17] ServiceIdentifier OPTIONAL, [18] PSFurnishChargingInformation OPTIONAL, [19] SEQUENCE OF AFRecordInformation OPTIONAL, [20] OCTER STRING OPTIONAL, [21] EventBasedChargingInformation OPTIONAL, [22] TimeQuotaMechanism OPTIONAL, [23] SEQUENCE OF ServiceSpecificInfo OPTIONAL

ChargingCharacteristics ::= OCTET STRING (SIZE(2)) --Bit 0-3: Profile Index

97

---

Bit 4-15: For Behavior

ChargingID --

::= INTEGER (0..4294967295)

-- Generated in P-GW, part of IP CAN bearer -- 0..4294967295 is equivalent to 0..2**32-1 --

ChargingRuleBaseName ::= IA5String (SIZE(1..16)) --- identifier for the group of charging rules -- see Charging-Rule-Base-Name AVP as desined in TS 29.212 [88] --

ChChSelectionMode { servingNodeSupplied subscriptionSpecific aPNSpecific homeDefault roamingDefault visitingDefault }

::= ENUMERATED

(0), (1), (2), (3), (4), (5)

-- For S-GW/P-GW -- For SGSN only -- For SGSN only -- For SGSN, S-GW and P-GW -- For SGSN, S-GW and P-GW -- For SGSN, S-GW and P-GW

ConsolidationResult::= ENUMERATED { normal abnormal forInterSGSNConsolidation reachLimit onlyOneCDRGenerated } (0), (1)), (2), (3), (4)

DataVolumeGPRS --

::= INTEGER

-- The volume of data transferred in octets. --

DynamicAddressFlag

::= BOOLEAN

EPCQoSInformation { --

::= SEQUENCE

-- See TS 29.212 [88] for more information --

98

qCI maxRequestedBandwithUL maxRequestedBandwithDL guaranteedBitrateUL guaranteedBitrateDL aRP }

[1] INTEGER, [2] INTEGER OPTIONAL, [3] INTEGER OPTIONAL, [4] INTEGER OPTIONAL, [5] INTEGER OPTIONAL, [6] INTEGER OPTIONAL

ETSIAddress ::= AddressString --- First octet for nature of address, and numbering plan indicator (3 for X.121) -- Other octets TBCD -- See TS 29.002 [60]

--

EventBasedChargingInformation ::= SEQUENCE { numberOfEvents eventTimeStamps } [1] INTEGER, [2] SEQUENCE OF TimeStamp OPTIONAL

FailureHandlingContinue ::= BOOLEAN --- This parameter is included when the failure handling procedure has been executed and new -- containers are opened. This parameter shall be included in the first and subsequent -- containers opened after the failure handling execution. --

FFDAppendIndicator

::= BOOLEAN

Flows ::= --

SEQUENCE

-- See Flows AVP as defined in TS 29.214 [89] -{ mediaComponentNumber flowNumber } [1] INTEGER, [2] SEQUENCE OF INTEGER OPTIONAL

FreeFormatData --

::= OCTET STRING (SIZE(1..160))

-- Free formatted data as sent in the FurnishChargingInformationGPRS -- see TS 29.078 [66] --

99

GSNAddress

::= IPAddress

LocalRecordNumber ::= INTEGER(0..4294967295) --- Sequence number of the record in this node -- 0.. 4294967295 is equivalent to 0..2**32-1, unsigned integer in four octets

LocalRecordNumberList::= SEQUENCE OF LocalRecordNumber LOCALRECORDSequenceNumber ::= SEQUENCE { CDFAddress [0] EXPLICIT CDFAddress, [1] LocalRecordNumberList

localrecordNumberList }

NodeID

::= IA5String (SIZE(1..20))

NumberOfDPEncountered ::= INTEGER

PDPAddress {

::= CHOICE

iPAddress eTSIAddress }

[0] IPAddress, [1] ETSIAddress

PDPType --

::= OCTET STRING (SIZE(2))

-- OCTET 1: PDP Type Organization -- OCTET 2: PDP/PDN Type Number -- See TS 29.060 [75] for GTP, TS 29.274 [91] clause 8.14 for eGTP and TS 29.275 [92] for PMIP --

PLMN-Id ---

::= OCTET STRING (SIZE (3))

This is a 1:1 copy from the Routing Area Identity (RAI) IE specified in TS 29.060 [75]

-- as follows: ----OCTET 1 of PLMN-Id = OCTET 2 of RAI OCTET 2 of PLMN-Id = OCTET 3 of RAI OCTET 3 of PLMN-Id = OCTET 4 of RAI

PSFurnishChargingInformation ::= SEQUENCE { pSFreeFormatData [1] FreeFormatData,

100

pSFFDAppendIndicator }

[2] FFDAppendIndicator OPTIONAL

QoSInformation --

::= OCTET STRING (SIZE (4..255))

-- This octet string -- is a 1:1 copy of the contents (i.e. starting with octet 5) of the "Bearer Quality of -- Service" information element specified in TS 29.274 [92]. --

RatingGroupId ::= INTEGER --- IP service flow identity (DCCA), range of 4 byte (0...4294967259) -- see Rating-Group AVP as used in TS 32.299 [40] --

RATType ::= INTEGER (0..255) --- Ihis integer is 1:1 copy of the RAT type value as defined in TS 29.060 [75] for GTP, -- TS 29.274 [91] for eGTP and TS 29.275 [92] for PMIP. --

RecordNumber ::= INTEGER RecordNumberList::= SEQUENCE OF RecordNumber RECORDSequenceNumber ::= SEQUENCE { CDFAddress recordNumberList } [0] EXPLICIT CDFAddress, [1] RecordNumberList

ResultCode ::= INTEGER --- charging protocol return value, range of 4 byte (0...4294967259) -- see Result-Code AVP as used in 3GPP 32.299 [40] --

ServiceConditionChange { qoSChange sGSNChange sGSNPLMNIDChange tariffTimeSwitch pDPContextRelease rATChange serviceIdledOut

::= BIT STRING

(0), (1), (2), (3), (4), (5), (6),

-- bearer modification -- bearer modification -- bearer modification -- tariff time change -- bearer release -- bearer modification

-- IP flow idle out, DCCA QHT expiry

101

reserved configurationChange serviceStop dCCATimeThresholdReached dCCAVolumeThresholdReached

(7), (8), (9),

-- old: QCTexpiry is no report event

-- configuration change -- IP flow termination -- DCCA quota reauthorization -- DCCA quota reauthorization -- DCCA quota reauthorization -- DCCA quota reauthorization

(10), (11),

dCCAServiceSpecificUnitThresholdReached (12), dCCATimeExhausted dCCAVolumeExhausted dCCAValidityTimeout reserved1 (13), (14), (15),

-- DCCA quota reauthorization -- DCCA quota validity time (QVT expiry) -- reserved due to no use case, -- old: return Requested is covered by (17),(18)

(16),

dCCAReauthorisationRequest dCCAContinueOngoingSession

(17), (18),

-- DCCA quota reauthorization request by OCS -- DCCA failure handling (CCFH), -- continue IP flow

dCCARetryAndTerminateOngoingSession

(19),

-- DCCA failure handling (CCFH), -- terminate IP flow after DCCA retry

dCCATerminateOngoingSession

(20),

-- DCCA failure handling, -- terminate IP flow

cGI-SAIChange rAIChange dCCAServiceSpecificUnitExhausted recordClosure timeLimit volumeLimit serviceSpecificUnitLimit envelopeClosure eCGIChange tAIChange userLocationChange } --

(21), (22), (23), (24), (25), (26), (27), (28) (29), (30), (31)

-- bearer modification -- bearer modification -- DCCA quota reauthorization -- PGW-CDR closure -- intermediate recording -- intermediate recording -- intermediate recording

-- bearer modification. “ECGI Change” -- bearer modification. “TAI Change” -- bearer modification. “User Location Change”

-- Trigger and cause values for IP flow level recording are defined for support of independent -- online and offline charging and also for tight interworking between online and offline charging. -- Unused bits will always be zero. -- Some of the values are non-exclusive (e.g. bearer modification reasons). --

SCFAddress --

::= AddressString

-- See TS 29.002 [60] --

ServiceIdentifier --

::= INTEGER (0..4294967295)

-- The service identifier is used to identify the service or the service component

102

-- the service data flow relates to. See Service-Identifier AVP as defined -- in TS 29.212 [88] --

ServingNodeType ::= ENUMERATED { sGSN pMIPSGW gTPSGW ePDG hSGW mME } (0), (1), (2), (3), (4), (5)

SGWChange --

::= BOOLEAN

-- present if first record after inter S-GW change --

TimeQuotaMechanism { timeQuotaType baseTimeInterval }

::= SEQUENCE

[1] TimeQuotaType, [2] Integer

TimeQuotaType {

::= ENUMERATED

dISCRETE_TIME_PERIOD cONTINUOUS_TIME_PERIOD }

(0), (1)

END

12 编制历史 版本号 1.0.0 更新时间 2009-05-20 主要内容或重大修改

103

附录A

接口版本要求(标准性附录)

接口名称 计费总体 计费话单

标准协议 32.251 32.298

基线版本 V8.7.0 V8.6.0

补充CR 无 0126、0130

附录B

EPC设备话单与2G/3G话单内容变化(参考性附录)

SGW-CDR相对于S-CDR删除了以下字段: networkInitiation MS Network Capability Routing Area Code (RAC) Local Area Code (LAC) Local Area Code (LAC) 增加了以下字段: iMSsignalingContext mSTimeZone userLocationInformation servingNodeType servingNodeAddress 以下字段名称发生变化: s-GWAddress p-GWAddressUsed sGWChange pdpPDNType servedPDPPDNAddress servingNodePLMNIdentifier 相对于G-CDR删除了以下字段: networkInitiation 增加了以下字段: iMSsignalingContext mSTimeZone userLocationInformation cAMELChargingInformation sGWChange servingNodeType p-GWAddressUsed 以下字段名称发生变化:
104

s-GWAddress servingNodeAddress pdpPDNType servedPDPPDNAddress servingNodePLMNIdentifier PGW-CDR相对于G-CDR删除了以下字段: networkInitiation listOfTrafficVolumes 增加了以下字段: iMSsignalingContext mSTimeZone userLocationInformation cAMELChargingInformation listOfServiceData servingNodeType externalChargingID pSFurnishChargingInformation 以下字段名称发生变化: p-GWAddress servingNodeAddress pdpPDNType servedPDPPDNAddress servingNodePLMNIdentifier

105


相关文章:
演进的分组核心网络MME设备功能测试规范-v2.0.0-送审版
演进的分组核心网络MME设备功能测试规范-v2.0.0-送审版_计算机硬件及网络_IT/计算机_专业资料。中国移动通信企业标准 QB-╳╳-╳╳╳-╳╳╳╳ 演进的分组核心...
核心网络演进趋势探讨
层,其技术标准为了适应新的业务发展需求在不断演进...图 1 示出的是核心网演进的目标架构。 1.1 用户...尤其是分组核心网络正在面临新的挑战,核心网络需要不...
MOCN在演进分组核心网中的应用研究
2 EPC 中启用 MOCN 实现原理 2.1 演进分组核心网 EPC 在 LTE 接入场景下,EPC(E-Packet Core,演进的分组核心网)提供了更低的延迟,并允 许更多的无线接入...
08.EPS核心网分组域性能测量参数技术规范(v0.0.4)
7 4.1.1.1 处于激活态的专用承载平均数 ......移动通信网网络管理接口技术规范 演进分组核心网(EPC...“计费策略和计费控制架构” [8] 3GPP TS 23.060...
中国电信CDMA分组核心网络向LTE/EPC 网络演进技术分析...
中国电信CDMA分组核心网络向LTE/EPC 网络演进技术分析...1x CS 的语音业务互操作方案包括 CSFB 规范和 ...X.P0057 Rev A v0 与 R9 对齐 ? 3GPP2 A.S...
高中起点计算机基础模拟试题一_3
高中起点计算机基础模拟试题 1. 早期的计算机是...( A.ENIAC B.EDVAC C.EDSAC D.MARK-II )A 3...就计算机网络分类而言,下列说法中规范的是 ()D A....
中文核心期刊-电气应用2009.9-基于优化决策的分布式环...
基于优化决策的分布式环境测控装置系统高鹤 1,朱本春...MARK_TYPE MARK_CODE EVENT_TYPE EVENT_CODE C_ID...通过监控软件,可以根据管理需要,对现场设备进行分组和...
2​0​1​4​年​F​a​c​e​b​...
AD: Mark Zuckerberg 从来就不是个墨守成规的人,...他认为 Facebook 的发展、 壮大离不开与开发者群体...1 月起,该 Facebook 的自家广告网络 Audience ...
AIX系统调优指导书V1.0
AIX系统调优指导书V1.0_计算机软件及应用_IT/计算机...2.1.1 调度算法 在多线程操作系统中,线程的调度...最大进程数、 High water mark、 Low water mark...
计算机高级操作员理论题第一套及解答
一定职业劳动的人们,在长期的活动中形成的道德规范。...C.自定义动画 D.动作设置 网络登录与信息浏览 1....HEML(Hyper TextMark—upLanguage)即超文本标记语言...
更多相关标签:
演进分组系统 | 建筑设计服务计费规范 | pcb mark点设计规范 | mark点设计规范 | mark点相关设计规范 | 地震分组 查什么规范 | 长期演进技术 | 朝核问题的历史演进 |