计费培训教程ver1.3（上海贝尔） 39页

计费培训教程ver1.3黄辉杨坚 第一章计费概述也许您是一个从事Evolium(TM)MSCALM7/7.2/8交换机开通、维护或管理的工程师，那么对直接关系到运营效益的计费的维护和管理对您来说就显得是举足轻重了。您是否想把这项工作做得更出色呢？俗话说“功欲善其事，必先利其器”，下面的内容就是为您准备的。1.1概述我国对移动用户呼叫计费的特点是不但对主叫移动用户计费，同时也对被叫移动用户计费。目前国内的移动用户主要采用两种付费方式，一种是依赖移动智能网来实现的预付费业务PPS（prepayservice），这种用户预先购买可以不断充值的SIM卡，计费由SSP和SCP协作完成，SSP向SCP汇报通话的时长，SCP通过访问计费距阵计算出通话费用并自动从储备金中扣除。另一种方式是每月付一次月租费和通话费，而通话费是由用户的计费中心根据我们MSC和USBS生成的记录通话时长和特服等信息的话单结合用户的不同费率而计算出来的。下面先让我们来认识一下MSC的计费系统，MSC计费系统由信令系统或呼叫处理系统来触发和终止。按计费系统在计费中完成的不同功能来区分，计费系统可以进一部细分为四个部分：计费分析部分计费产生部分计费收集部分计费输出部分在一次呼叫中，由计费分析部分软件确定相应的计费控制信息，计费产生部分的软件就可以根据此控制信息在呼叫过程中生成计费帐单了。在呼叫结束或呼叫过程中，计费结果必须被收集并归类存放在安全地方（SACECHRG）模块的内存），这就是计费收集部分软件的功能。计费输出部分软件将收集到的计费结果－称为原始帐单（rawrecord ）输出至计费采集器USBS(unixsystembillingserver)，在计费采集器中把rawrecord根据运营商的要求格式化成熟帐单（cookedrecord）并由此进一步送至计费分检中心完成话单的分检。1.2计费种类所谓计费种类（chargingtype或AMAtype）是指交换机可以根据运营商的不同要求产生不同的计费帐单和提供多样的计费功能。Evolium(TM)MSCALM7/7.2/8交换机输出到USBS服务器上的原始话单（rawrecord）包含了全部的计费信息，这样USBS服务器就可以从原始话单中提取相应的数据用来生成不同的计费帐单（称为熟话单cookedrecord）。Evolium(TM)MSCALM7/7.2/8交换机的计费系统支持多种计费种类和功能，根据需要您只须关心下面三种类型的话单就够了：Ø详细话单(DetailedBilling)是指在一次呼叫通话结束后生成一张记录详细计费信息的表单，这张详细表单中一般包括主叫和被叫用户的IMSI，MSISDN,BillingRecordIDRecordType,LAC,CELLID，TKGID，计费开始的日期和时间，以及计费的时长等参数，具体话单格式请参阅《TRS-CHARGING-RECORD》文档7.3章。表单中收集的通常都是信令过程和呼叫处理过程中产生的参数。因此计费子系统所要做的只是收集这些参数并且按照一定的格式(由专门的计费软件定义)形成详细帐单。Ø资费分摊(DivisionOfRevenue)为了在不同电信运营商（如中国电信和中国联通）之间完成话费的分摊而生成的类似详细帐单的针对不同去话目的地或来话方向的统计帐单，比详细话单多提供了信道或中继的占用和释放时间，具体话单格式请参阅《TRS-CHARGING-RECORD》文档7.5章。Ø热计费(Hotbilling)热记费（HotBilling）其实也是一种详细话单(DetailedBilling)，只是话单多了一个特服标志（SupplimentServicecode为F1），具体话单格式请参阅《TRS-CHARGING-RECORD》文档7.4章。1.3完成计费功能的硬件模块Evolium(TM)MSCALM7/7.2/8交换机最大的特点是分散控制，其逻辑功能是分布在不同的硬件模块（controlelement）中的软件ＦＭＭ和ＳＳＭ来实现的，计费系统也不例外。那么，在继续学习之前，我们先来认识一下计费功能赖以实现的主要硬件模块：PSACE（PrefixSystemAuxiliaryControlElement） 其中装载软件的主要功能是完成字冠分析，得到进一步的呼叫控制数据包括计费控制数据的索引指针。MRSACE（MobileRadioSystemACE）根据计费控制数据的索引指针找到计费控制数据并完成计费临时参数的缓存及提供与其他计费软件功能块的接口。SACEIN(IntelligentNetworkSACE)完成移动智能网呼叫SSP中的计费。ISVCE（ImprovedServiceCircuitControlElement）提供会议桥用以完成多方通话并产生此类通话的话单，同时提供双音多频信号（DTMF）用于完成局间CAS信令。SACECHRG（SystemACECharging）完成计费帐单的收集并根据AMATYPE的不同分类收集到不同的2KBUFFER中，并在一定条件下每次传送2K个字节至EPMCE模块，以配对负荷分担的形式工作。SACECP（SystemACECharging）完成计费帐单传输的控制模块，以主备用的形式工作。EPMCE(EthernetPrepherialModuleCE)将SACECHRG话单通过以太网口传送到USBS上，每次传送2K个字节，工作在单独的负荷分担的形式。1.4基本的计费原则根据不同的通话行为，有可能会产生几张计费话单，但这是遵循以下基本的计费原则：Ø普通手机----》它网用户产生话单2张：DBILL（MOC）+DOR（PTC）Ø它网用户----》普通手机产生话单2张：DOR（POC）+DBILL（MTC）Ø它网用户----》普通手机----》它网用户产生话单3张：DOR（POC）+DBILL（呼转MTC）+DOR（PTC）Ø它网用户----》普通手机----》普通手机 产生话单3张：DOR（POC）+DBILL（呼转MTC）+DBILL（MTC）Ø它网用户----》它网用户----》普通手机（在它网前转）产生话单2张：DOR（POC）+DBILL（MTC）Ø普通手机----》它网用户----》它网用户（在它网前转）产生话单2张：DBILL（MOC）+DOR(PTC)Ø普通手机----》它网用户----》普通手机（在它网前转）产生话单4张：DBILL（MOC）+DOR(POC)+DOR(PTC)+DBILL（MTC）Ø普通手机----》普通手机----》它网用户产生话单3张：DBILL（MOC）+DBILL（呼转MTC）+DOR(PTC)注：DBILL（DetailedBilling）详细计费话单-MOC（MOBILEORIGINALCALL）主叫话单-MTC（MOBILETERMINALCALL）被叫话单DOR（DivisionOfRevenue）网间结算话单-POC（PSTNORIGINALCALL）入局网间结算话单-PTC（PSTNTERMINALCALL）出局网间结算话单MOC、MTC、呼转MTC话单如果没有特别情况，都在端局产生,但外网打入引起的无条件或不可及呼转的话，呼转MTC话单则会直接在入口关口局产生。DOR话单全部在关口局或混合局产生。预付费和VPMN等智能网用户手机与普通手机的话单产生原则是基本一样的。但是如果端局MSC集成了SCP（智能网外设）功能后，则预付费和VPMN手机做被叫的话，会在其触发T-CSI的端局MSC上多产生一张智能网业务补充话单（TerminatingCAMELInterrogationRecord），作为最后的那张MTC话单的智能网相关的补充信息。 第二章基本计费软件及其简单的工作原理到目前为止，您已经对Evolium(TM)MSCALM7/7.2/8交换机的计费有了初步的认识。“欲穷千理目，更上一层楼”，下面让我们再稍微深入的了解一下基本计费软件组成和工作原理。2.1基本计费软件概述基本计费软件是在呼叫过程中实现对呼叫计费的软件，它们在呼叫过程中由呼叫系统或信令系统激活和终止，其组成关系如下图。注：AMAAutomaticMessageAccountingASN.1AbstractSyntaxNotationoneALCUAlarmConverterUnixCECOChargeErrorCollectorCFCSCallandFacilityControlSystem CGCChargeGenerationControlCHANCHargeANalysis(FMM)COLCCollectorControllerCHRONCHRONologicalcollectorEPMExtendedPeripheralModuleHUTHandleUnixTasksLCGLocalChargeGeneration(FMM)TCASTaxCellAccess(SSM)TDOTaxDataOutputTFPTaxFieldProvider(SSM)TLTaxLayouter(FMM)TRASTaxRecordAccessSSMTXCSTaxCollectorSSM2.2计费控制CGCFMMCGC作为计费呼叫处理的控制中心和接口，用来连接CFCSFMM、CHANFMM、以及LCGFMM等软件，并为LCGFMM创建TAXcell作准备。在呼叫处理过程中，呼叫控制软件(CFCSFMM)发送消息1352_CHRQ给CGCFMM，激活基本计费软件，在这个消息中包含了计费目的码、计费源码等所有计费分析必须的参数。CGCFMM在关系R_CGC_CELL中找到一个空闲的元组为本次呼叫计费分配一个CGC单元(CGCcell，存放计费数据的内部变量)。CGC内部单元分配以后，CGCFMM发送一个27_CHIR消息给计费分析软件(CHANFMM)，将来自CFCSFMM的计费参数传送给CHAN，CHAN根据这些参数进行分析，最终得到必要的计费控制数据并通过消息8378_CHIF回送给CGCFMM，CGCFMM将这些参数存放在为本次呼叫计费创建的内部单元(CGCcell)中，之后CGC将所有的这些参数通过消息16586_LCG_REQ传送给LCGFMM，在LCGFMM中将创建一个LCG内部单元(LCGcell)存放这些参数。2.3计费分析CHANFMM主要通过访问数据库关系来分析呼叫中必需的计费控制数据。当CGCFMM收到CFSC发来的1352_CHRG消息后，向CHANFMM发消息27_CHIR，请求进行计费分析，如检查是否有AMA功能请求，如果有则增加详细帐单计费，通过一个或若干个消息将计费分析结果返回给CGCFMM。2.4本地计费产生LCGFMM LCG是计费系统中的一个重要软件，可以说它是话单中各个元素的初始收集和提供者，没有它计费就成了无米之炊。那么，LCG是怎样工作的呢？下面让我们来看一看LCG简化的计费过程：A．激活计费(activationofcharging)LCG可由CGC激活，也可由信令系统直接激活，参考后面相关章节。LCG被激活后，为了收集所有本次呼叫需要的数据，LCG为其分配相应计费内部单元(LCGcell)，计费单元的分配是通过在关系R_LCG_CELL中找到一个空闲的元组来实现的;B．开始计费(startcharging)每一个呼叫事件(如占用、应答、前向释放、后向释放、强拆等)都由信令系统检测到，并由3118_CHG_EVENT消息通知LCG。LCG根据这些事件起动或终止计费。同时在呼叫过程中，LCG在相应的事件(如ANSWER,CONNECT)发生时，对事件作时间标记(timestamp)，计算呼叫时长并依此生成不同话单类型（recordtype）的话单。LCGCELL中事件与数据的记录是通过调用访问LCGcell的TCASSSM实现的。Ｃ.结束计费(stopcharging)每一个计费事件都由信令系统检测到，并送到LCGFMM，如果是结束计费事件(如RELEASE,DELAYRELEASE)，则LCG停止计费并记录相关事件的时间。Ｄ.释放计费(releaseofcharging)LCG收到结束计费事件消息后(如RELEASE)，便开始调用TLSSM将计费结果格式化后形成帐单通过消息17002T送到计费收集模块(SACECHRG)，SACECHRG中的CHRONFMM接收到帐单后，将通过17003T消息向LCG送应答信号，LCG释放LCGCELL，这个LCGCELL就可以为其它的呼叫所利用。 第三章话单的收集和输出在每个生成话单的模块中，当LCG完成话单记录的格式化后要立即将记录传给到SACECHRG模块中的CHRONFMM并缓存到BUFFER中，在这里组织成以每2K个BYTES为一个BLOCK的数据块，并在条件满足时通过EPMCE模块传到USBS上，参考下图。3.1话单收集软件及作用 CHRON：ChronologicalFMMCHRONFMM以时序方式接收TLSSM格式化后的RAWrecord，通过SEQN和"窗口"策略，保证帐单的安全传送，并与TXCSFMM一起实现帐单在内存中的存放。TXCS：TaxCollectorSSM负责RAWrecord在内存中的安全存放；在帐单收集过程中负责存放帐单的R_TDFM_2KB的tuplestate的转换；负责监控主备用CE间状态的转换及主备用CE间的同步；所有发往备用CE的MSG都由TXCS发送；TDO：TaxDataOutputFMM接收TXCS送来的帐单，将RAWrecord发往EPM。3.2话单记录块的输出TDO将2K 字节的BUFFER通过19592_EPI_ACCESS传给EPMCE中的EPIFMM，并为其设定一顺序号。EPI通过TCP/IP协议再转给USBS，成功后，EPI向TDO发送证实消息19593_EPI_RESP，并带有原顺序号，此时，TDO将2KBUFFER置成FREE。由于EPMCE和USBS之间的通信是基于TCP/IP协议通过调用SOCKET来完成的，所以EPMCE和USBS中都装载有完成TCP/IP协议和应用TCP/IP协议的上层软件包。EPMCE 的IP地址可通过人机命令或宏来管理（具体方法详见附件3《EPM的IP设置与检查》）。 第四章计费采集器USBS4.1基本结构MSC计费的输出系统由两个主备用的DS10服务器构成（UnixSystemBillingServer：简称USBS）。作为一个独立的机架，它与移动交换机（MSC）之间用TCP/IP协议互联，收集原始的计费话单，经过一定的处理，存储在USBS的硬盘阵列中，等待记费中心（BILLINGCENTER）存取。其机架结构图、网络连接图如下：网络连接图 USBS机架结构图 两个INVERTER为USBS机架上的所有设备提供电源；TerminalServer又称IOLAN（在MODEM的配合下）可使工程师远程接入USBS进行操作和维护。三个HUB中的两个（PRIMARYLANHUB和SECONDARYLANHUB）用来和交换机（MSC）建立传送话单的通信局域网（LAN）；另一个（CUSTOMERLANHUB）用来和记费中心（BILLINGCENTER）联系。两台DS10服务器（一台DS10服务器硬件上包括一个CPU，一个IDE硬盘，一个光驱CDDRIVER，一个软驱FLOPPYDRIVER，一个磁带机DATDRIVER和两个SCSIADAPTER）运行底层平台软件和记费应用程序，处理交换机发来的记费数据；每台服务器除安装了UNIX操作系统外，还装有ALCATEL开发的平台软件NECTAR和DSM；两个磁盘阵列（StorageWorks）互为镜像（Mirrored），存贮记费应用程序（APPLICATIONPROGRAMM）和话单；除了机架上的设备外，USBS还配有一台预装了NT4.0和EXCEED软件的PC。现场对USBS的维护和监控都是在这台PC机上进行的。目前，现网运行的USBS系统有两个版本，大部分现网局安装的是为CLM7版和CLM7.2版交换机服务的3.3.0版，而为最新的CLM8版交换机服务的3.3.3版也已经在吉林完成升版。4.2工作原理在收集原始话单的过程中，USBS相当于一个服务器（SERVER），交换机（MSC）作为客户（CLIENT）主动向USBS吐原始话单。USBS将收到的原始话单按一定的格式处理后生成熟话单（COOKEDRECORDS）存储在磁盘上。此刻USBS作为FTP服务器（FTPSERVER），记费中心则作为FTP客户（FTPCLIENT）登录到USBS上取话单。平时，两个DS10服务器以主备用(ACTIVESTANDBY)的方式工作，任意时刻只有一台服务器运行记费应用程序（被称为主用侧服务器ACTIVESERVER），另一台只运行底层的平台软件（NECTAR，DSM）（被称为备用侧服务器STANDBYSERVER）。如果主用侧服务器发生故障，USBS系统自动进行切换，原来的备用侧服务器将接替故障的机器继续服务。在日常维护时，工程师也可通过命令强制USBS进行主备用服务器的切换。 下图介绍了USBS处理话单的基本工作原理：USBS通过安装时的配置，对DBILL话单和DOR话单进行处理，周期性地产生话单文件（每15，30，45或60分钟产生一个话单）。其工作原理如下图。WorkingFile在一个周期内（比如15分钟）不停地增长（因为USBS在这个过程中一直接收、处理话单），周期结束时，WorkingFile变成TransferFile存储在CircularDataBase；TransferFile就是计费中心将要取走的话单文件。在接下来的新周期里，一个新的WorkingFile生成，重复以上过程。当CDB（CircularDataBase）中的TF（TransferFile）容量到达一定阀值，USBS系统采用覆盖、删除老文件的方法使CDB中的文件容量在安全范围内。USBS生成的熟话单根据不同的话单类型，分别放在不同的目录中：ØDB(DetailedBilling)话单文件的目录为/CDB/buffer/dbill；ØDOR(divisionofrevenue)话单文件的目录为/CDB/buffer/dor。文件的命名规则为：交换机名.年.月.日.小时分钟.循环序列号，如：NJGW1N1.2001.04.10.2345.95。USBS将向用户开放上述的两个目录，供用户取数据。具体操作参看附件1《简介话单的人工采集和分拣》。对另一种比较特殊的话单HBILL（HOTBILLING），USBS3.3.0对它的处理与对DBILL和DOR话单的处理有些不同。以一个时间间隔为单位（15秒），USBS如果收到HOTBILLING话单，就产生相应的话单文件。如果没有收到，就不会有话单文件生成。HOTBILLING将生成的话单文件放置在目录：/uce_rel/rtb/buffer/hbill文件的命名规则跟DBILL和DOR类似。USBS也会开放这个目录，供用户取数据。关于USBS的相关文档和资料可以查询我们TAC的网页：http://aww.sbamc.com.cn/mte/mte2/tac_web/tech_cen/usbs 第五章话单的格式及内容正如在第一章计费概述中所述，在Evolium(TM)MSCALM7/7.2/8交换机的计费系统支持的多种计费种类和功能中，目前我们主要关心两种计费类型的熟话单，即详细话单(DetailedBilling)和资费分摊话单(DivisionOfRevenue)，所以USBS上生成的熟话单也是分这两种类型。而无论是DBILL话单还是DOR话单都是有很多域组成的，如下面的两个表（DetailedBilling&DORASN.1typesandtagsSummary）。LM7P2DetailedBillingASN.1typesandtagsSummaryThetableshowstheASN.1typesandtheASN.1tagsofthe“cooked”detailedbillingrecordfields:Nbr.FieldnameASN.1-TypeTag1Tag2Remark1.BillingRecordSEQUENCEE1002.BillingRecordIdOCTET_STRING(SIZE(3..8))DF633.TestcaseIdentityOCTET_STRINGDF67Onlyfortest4.RecordTypeINTEGER02005.CallTransactionTypeINTEGER02006.ServedIMEITBCD-String(SIZE(8))C8007.ServedIMSITBCD-String(SIZE(8))C6008.ServedMSISDNTBCD-String(SIZE(8))C7009.ChargedPartyIdOCTET_STRING(SIZE(1..16))DF1F10.ChargingTimeDataSEQUENCEEE0011.…StartOfChargingDateOCTET_STRING(SIZE(3))D30012.…StartOfChargingTimeSETOFTimestampF40013.……TimeStampOCTET_STRING(SIZE(3))040014.…CallDurationINTEGERD10015.TimeQualityINTEGER020016.MSC-IDOCTET_STRING(SIZE(4))CA00Clm7p217.ConnectedSwitchIDCHOICE000018.…BSC-IDOCTET_STRING(SIZE(2))CB0019.…DAIdTBCD-String(SIZE(1..12))C20020.LocationAreaCodeOCTET_STRING(SIZE(2))CC0021.CellIdOCTET_STRING(SIZE(2))CF0022.TransactionIdentifierOCTET_STRING(SIZE(1))CD0023.OtherPartyAddressString(SIZE(12))C90024.BasicServiceCHOICE000025.…TeleServiceOCTET_STRING(SIZE(1))D50026.…BearerServiceOCTET_STRING(SIZE(1))D60027.…ISDNServiceOCTET_STRING(SIZE(1))D00028.TransmissionModeOCTET_STRING(SIZE(1))DB0029.SupplementaryServiceOCTET_STRING(SIZE(1..10))D70030.MSAccessRateOCTET_STRING(SIZE(1))D80031.MSClassMarkOCTET_STRING(SIZE(1))DC0032.ChargeAdviceInfoSETOFAOCParameterFA0033.…AOCParameterSEQUENCE300034.……e1OCTET_STRING(SIZE(2))8100 1.……e2OCTET_STRING(SIZE(2))82002.……e3OCTET_STRING(SIZE(2))83003.……e4OCTET_STRING(SIZE(2))84004.……e5OCTET_STRING(SIZE(2))85005.……e6OCTET_STRING(SIZE(2))86006.……e7OCTET_STRING(SIZE(2))87007.CauseForTerminationCHOICE00008.…GSMCauseINTEGERDE009.…PADCauseINTEGERC400Notused10.MSRNAddressString(SIZE(1..12))C50011.CallingPartyNumberOCTET_STRING(SIZE(2..12))DF2112.CAMELDestinationNumberAddressString(SIZE(3..12))DF2213.INServiceIndicatorINTEGERDF2314.CorrelationIdINTEGERDF2415.ChargeInfosSEQUENCEOFChargeInfoFF2516.…ChargeInfoSEQUENCE300017.……ChargeNumberINTEGER020018.……ChargeParameterOCTET_STRING(SIZE(1..20))040019.PartialRecordTypeENUMERATEDDF5820.PartRecordCorrelationIDOCTET_STRING(SIZE(6))DF5721.SequenceNumberINTEGERDF5622.GSM-SCFAddressISDN-AddressStringDF5E23.ServiceKeyINTEGERDF6124.NetworkCallReferenceCallReferenceNumberDF5F25.MSCAddressISDN-AddressStringDF6026.DefaultCallHandlingENUMERATEDDF5C27.FreeFormatDataOCTET_STRING(SIZE(1..40))DF6228.CAMELLegInformationSEQUENCEFF5A29.…CAMELDestinationNumberAddressString(SIZE(3..12)DF5930.…CamelInitCFIndINTEGERDF5B31.…ChargingTimeDataSEQUENCEEE0032.……StartOfChargingDateOCTET_STRING(SIZE(3))D30033.……StartOfChargingTimeSETOFTimeStampF40034.………TimeStampOCTET_STRING(SIZE(3))040035.……CallDurationINTEGERD10036.…FreeFormatDataOCTET_STRING(SIZE(1..40))DF6237.PPSAreaCodeTBCD-StringDF3BChinaonly38.IncTkMnemOCTET_STRING(SIZE(16))DF32Chinaonly39.OutTkMnemOCTET_STRING(SIZE(16))DF35Chinaonly40.CUGInfoSEQUENCEFF44Notused41.…CUGIndexINTEGERDF43Notused42.…CUGInterlockCodeOCTET_STRINGDF42Notused43.…OAParameterBOOLEANDF41Notused44.…OASuppressedBOOLEANDF40Notused45.USSDCodeSEQUENCEFF3FNotused46.…USSDSchemeOCTET_STRINGDF3ENotused47.…USSDStringOCTET_STRINGDF3DNotused48.CarrierIdentificationCodeOCTET_STRINGDF3CNotused83.Forwarded-A-Party-NumberAddressString(SIZE(12))DF4ACLM7P2 LM7P2TollTicket/DORASN.1typesandtagsThetableshowstheASN.1typesandtheASN.1tagsoftheTollTicketfields:FieldnameASN.1-TypeTag1Tag2Remark1.DetailedDORTicketSEQUENCEE1002.TestcaseIdentityOCTET_STRINGDF67Onlyfortest3.RecordTypeINTEGER02004.MSC-IDOCTET_STRING(SIZE(4))C200CLM7P25.OtherPartyAddressString(SIZE(12))C3006.SeizureTimeInformationSEQUENCEE4007.…StartOfSeizureDateOCTET_STRING(SIZE(3))C5008.…StartOfSeizureTimeOCTET_STRING(SIZE(3))C6009.…SeizureDurationINTEGERC70010.ChargingTimeInformationSEQUENCEE80011.…StartOfChargingDateOCTET_STRING(SIZE(3))C90012.…StartOfChargingTimeOCTET_STRING(SIZE(3))CA0013.…CallDurationINTEGERCB0014.IncTkMnemOCTET_STRING(SIZE(16))CC0015.OutTkMnemOCTET_STRING(SIZE(16))CD0016.BasicServiceCHOICE000017.…TeleServiceOCTET_STRING(SIZE(1))CE0018.…BearerServiceOCTET_STRING(SIZE(1))CF0019.GSMCauseINTEGERD00020.CallingPartyAddressAddressString(SIZE(2..12)D100NewinLM721.MSRNAddressString(SIZE(2..12)D200OnlyforChina在这只选LM72版DBILL话单几个域作例子讲解，其它域的格式和含义请参考相关资料（《TRS-CHARGING-RCD7D01P01》）。具体的话单实例参阅附件2《话单举例》。Ø呼叫类型(CallTransactionType)定义本话单为何种类型的呼叫产生的话单。例：01:MOC(MobileOriginatedCall)手机主叫话单02:MTC(MobileTerminatedCall)手机被叫话单2B:TCI(TerminatingCAMELInterrogation)被叫智能网业务补充话单Ø话单记录的类型（RecordType）在移动通信领域有其特定的含义。根据移动通信的计费规范，每当通话时长持续30分钟时交换机就需生成一张针对此30分钟的话单记录，根据其在一次通话中产生于哪个以30分钟为分割的时间段来定义其记录类型。Evolium(TM)MSCALM7/7.2/8交换机每产生一个这样的话单记录便输出至USBS上，但USBS不对其进行合并，合并工作可由计费分检中心来完成。 下面是ASN1（abstractsyntaxnotation1）定义的recordtype。RecordType::=INTEGERsingleTypeA(00)，firstTypeA(01)，intermediateTypeA(02)，lastTypeA(03)，我们看两个例子，假设某次的通话时长为T，时间轴为t，则不同时间产生的话单的recordtype如下：T<=30分T30min0tRecordType=0T=100分T30min60min90min120min0tRecordType=1RecordType=2RecordType=2RecordType=3但是，这里要注意，只有对于DB话单有30分钟的分割机制，而DOR话单是没有的，所以DOR话单的recordtype取值始终为singleTypeA(00)。Ø用户号码（ServedMSISDN）取值（8bytes）：MOC话单中——主叫用户的号码；MTC话单中——被叫用户的号码；呼转话单中——做呼转用户的号码。ØMSC标示（MSC-ID）MSC从LM7版升为LM7P2版以后，该字段由原来的4位数字（2bytes）扩展为8位数字（4bytes）。Ø呼叫参与者之一的号码（OtherParty）ü12bytes（共24bits）中最多20bits是有效的号码，其他位用“F”补足；ü根据通话情况的不同，OtherParty中分别反映不同的呼叫参与者号码：1.在MOC话单中是被叫用户的号码；2.在MTC话单中是主叫用户的号码；3.在呼转话单中是呼转至用户的号码。ü 根据号码属性的不同和附带的某些特服（如CLIR主叫号码隐藏），在用户号码前会有不同的前缀来标示（详见下表，粗体部分为可能出现的前缀）：ExtensionBitTypeofNumberNumberingPlanOctet3Octet3afollowsunknown1000000181Nonational10100001A1Nointernational1001000191Nonetworkspecificnumber10110001B1Nodedicatedaccess,shortcode11000001C1Nounknown0000000101Yesnational0010000121Yesinternational0001000111Yesnetworkspecificnumber0011000131Yesdedicatedaccess,shortcode0100000141Yesü对于前缀中出现附加“3a”的情况，可以跳过“3a”，直接取其后真正的用户号码；ü所有用户拨打的号码，包括“*、#、a、b、c”等符号，都是未经修改而以特殊字段直接反映到话单中的OtherParty项。Ø附加业务标示（SupplementaryServices）SS-code（附加业务码的标志）有效取值详见下表：SS-CodeSupplementaryServiceInv12Callinglineid.restrict.Y14Connectedlineid.restrct.Y21Callfwd.unconditionalY29Callfwd.onsubscr.BusyY2ACallfwd.onnoreplyY2BCallfwd.onnotreachableY41CallwaitingY42CallholdY51MultipartyY61CUGY71Adviceofcharge-inform.Y72Adviceofcharge–chargingY81UsertoUserSignalling-Service3(UUS3)YA0PriorityCallinstateofdisasterYE0DelayedHotLineY*E1CallDeflectionY*F1HotBillingYF4CompletionofCallstoBusySubscriberY备注：“*”标记表示该项附加业务暂时不用。Ø在呼转话单中标示主叫用户的号码（ForwardedAPartyNumber）：此项字段也是MSC升为LM7P2版后新增加的。最近吉林等地又将开始LM8版的交换机升版，计费方面除了USBS要升级为3.3.3 版外，为配合LM8版的各项新功能，相关的话单格式也将有所变化，关于LM8版的话单格式变化说明如下：1.与LM7版相比，LM8版的DOR话单格式没有任何变化；2.与LM7版相比，LM8版的DBILL话单中增加了一些字段（即下表粗斜体字段）：NAMETAGBillingRecordE1BillingRecordIdDF63TestcaseIdentityDF67RecordType02CallTransactionType02ServedIMEIC8ServedIMSIC6ServedMSISDNC7ChargedPartyIdDF1FChargingTimeDataEE……StartOfChargingDateD3……StartOfChargingTimeF4…………TimeStamp04……CallDurationD1TimeQuality02MSC-IDCAConnectedSwitchID……BSC-IDCB……DAIdC2LocationAreaCodeCCCellIdCFTransactionIdentifierCDOtherPartyC9BasicService……TeleServiceD5……BearerServiceD6……ISDNServiceD0TransmissionModeDBSupplementaryServiceD7MSAccessRateD8MSClassMarkDCChargeAdviceInfoFA……AOCParameter30…………E181 …………E282…………E383…………E484…………E585…………E686…………E787CauseForTermination……GSMCauseDE……PADCauseC4MSRN*C5CallingPartyNumberDF21CAMELDestinationNumberDF59CorrelationId*DF24ChargeInfosFF25……ChargeInfo30…………ChargeNumber02…………ChargeParameter04PartRecordTypeDF58PartRecordCorrelationIDDF57SequenceNumberDF56GSM-SCF-AddressDF5EGsmSCFAddress-SDSDF53ServiceKeyDF61ServiceKey-SDSDF54NetworkCallReferenceDF5FMSC-AddressDF60DefaultCallHandlingDF5CDefaultCallHandling-SDSDF55FreeFormatDataDF62FreeFormatData-SDSDF4FFreeFormatData-NDSDF4ECAMELLegInformationFF5A……CAMELDestinationNumberDF59……CAMELDestinationNumber-SDSDF4D……CAMELDestinationNumber-NDSDF4C……ChargingTimeDataEE…………StartOfChargingDate*D3…………StartOfChargingTimeF4………………TimeStamp*04…………CallDurationD1……CamelInitCFIndDF5B ……FreeFormatDataDF62……FreeFormatData-NDSDF4E……FreeFormatData-SDSDF4FVMSCIndicationDF49TCI-FlagDF47PPSAreaCodeDF3BIncTkMnemDF32OutTkMnemDF35HSCSDChanRequestedDF46HSCSDChanAllocatedDF45CUGInfoFF44……CUGIndexDF43……CUGInterlockCodeDF42……OAParameterDF41……OASuppressedDF40USSDCodeFF3F……USSDSchemeDF3E……USSDStringDF3DCarrierIdentificationCodeDF3CForwardedAPartyDF4AForwardingBPartyDF4B对于这些新增的字段分别说明如下：Ø部分新增字段是在原有某些字段的后面增加了-SDS或-NDS后缀，如GsmSCFAddress-SDS、ServiceKey-SDS、DefaultCallHandling-SDS、FreeFormatData-SDS、FreeFormatData-NDS、CAMELDestinationNumber-SDS、CAMELDestinationNumber-NDS。SDS：SubscribedDailledServicesNDS：NetworkDailledServices出现这些变化主要是因为LM8版的升版将包括CAMELPHASE3的功能升级，而话单中新增字段的不同后缀主要用来标记区分不同的CAMEL业务触发方式（具体内容可以参阅相关的CAMELP3业务规范）。ØVMSCIndicationVistitedMSCIndication：该字段包含于VMSC产生的TCI话单中，用于区别该TCI话单是由VMSC产生的，还是由GMSC产生的。ØTCI-Flag该字段包含于VMSC产生的MTC话单中，表示在VMSC上除了这张MTC话单外，还产生了一张TCI（TerminatingCAMELInterrogation）话单。ØForwardingBParty该字段包含于呼转情况下（A——>B——>C）产成的C用户MTC话单中， 标示了作呼转用户（即B用户）的号码。1.与LM7版相比，LM8版的DBILL话单还有一个字段（SupplementaryService）的取值（SS-code）有所增加。下表是有效的SS-code取值及其含义，其中粗斜体字段就是新增的SS-code取值：MAPCodeSupplementaryService12Callinglineid.restrict.14Connectedlineid.restrct.21Callfwd.unconditional29Callfwd.onsubscr.busy2ACallfwd.onnoreply2BCallfwd.onnotreachable41Callwaiting42Callhold43CompletionofCallstoBusySubscriber–originatingside44CompletionofCallstoBusySubscriber–destinatingside51Multiparty61CUG71Adviceofcharge-inform.72Adviceofcharge-charging81UsertoUserSignalling-Service3(UUS3)A0PriorityCallinstateofdisasterE0DelayedHotLineE1CallDeflectionF1HotBillingF2NochargeindicationØCCBS（CompletionofCallstoBusySubscriber）这是为了配合LM8新增的遇忙回叫功能而开的SS-code取值，43为主叫端的遇忙回叫，44为被叫端的遇忙回叫。ØNochargeindication这是一个不计费的标记，即如果话单中SupplementaryService字段取值为F2，则这张话单应该不计费而被计费中心过滤掉。2.LM8另外一个变化是六种FreeFormatData（即Leg1和Leg2的FreeFormatData、FreeFormatData-SDS、FreeFormatData-NDS）的取值位长范围增加，由LM7版的1-40bytes增加到了1-160bytes。3.LM8话单的ForwardedAParty字段的长度也有修改，与TRS话单格式文档的描述保持了一致。1）在7.2版的TRS文档中该字段长度定义为8bytes（8.2.43节）ForwardedAParty::=[PRIVATE72]IMPLICITTBCD-STRING(SIZE(8))2）在8版的TRS文档中这个字段长度也定义为8bytes（7.3.49节）ForwardedAParty::=[PRIVATE74]IMPLICITTBCD-STRING(SIZE(8)) 3）但是在实际的LM7.2版话单中，我们发现这个字段长度可能为12bytes（0C），例如：1.Record=============BillingRecord(E1/7E):BillingRecordId*(DF63/08):68FC1BA078683A77RecordType(02/01):00->0->singleTypeACallTransactionType(02/01):02->2->mtcServedIMSI(C6/08):64004032441049F4->460004234401944FServedMSISDN(C7/08):683149241349F4FF->8613944231944FFFChargingTimeData(EE/0F):StartOfChargingDate*(D3/03):030707-07.07.03StartOfChargingTime(F4/05):TimeStamp*(04/03):095540-09:55:40CallDuration(D1/01):0C->12s->00h00"12""TimeQuality(02/01):00->0->certainMSC-ID(CA/04):13900432->0-2-1-4/010COtherParty(C9/0C):91683107341047F8FFFFFFFF->8613704301748FFFFFFFFF->TypeOfNumber:1->International->NumberingPlan:1->E.164BasicServiceTeleService(D5/01):11->TS11,TelephonySupplementaryService(D7/01):21->cfuMSRN*(C5/08):91683109402333F9->8613900432339F->TypeOfNumber:1->International->NumberingPlan:1->E.164NetworkCallReference(DF5F/06):7E01E702F048MSCAddress(DF60/06):916831094023->8613900432->TypeOfNumber:1->International->NumberingPlan:1->E.164Forwarded-A-Party-Number(DF4A/0C):A13195364891F9FFFFFFFFFF->13596384199FFFFFFFFFFF->TypeOfNumber:2->National->NumberingPlan:1->E.164===EndofRecord===这是LM7.2版TRS文档与实际情况的矛盾造成了这个问题； 4）而在LM8版的话单中，这个字段与TRS文档中定义是一致的，确实是8bytes，例如：1.Record=============BillingRecord(E1/86):BillingRecordId*(DF63/08):68FC1E805CED7A75RecordType(02/01):00->0->singleTypeACallTransactionType(02/01):02->2->mtcServedIMSI(C6/08):64004006431132F8->460004603411238FServedMSISDN(C7/08):683148645133F6FF->8613844615336FFFChargingTimeData(EE/0F):StartOfChargingDate*(D3/03):030715-15.07.03StartOfChargingTime(F4/05):TimeStamp*(04/03):095345-09:53:45CallDuration(D1/01):68->104s->00h01"44""TimeQuality(02/01):00->0->certainMSC-ID(CA/04):13900432->0-2-1-4/010COtherParty(C9/0C):91683161961850F1FFFFFFFF->8613166981051FFFFFFFFF->TypeOfNumber:1->International->NumberingPlan:1->E.164BasicServiceTeleService(D5/01):11->TS11,TelephonySupplementaryService(D7/01):21->cfuNetworkCallReference(DF5F/06):8B029D02503DMSCAddress(DF60/06):916831094023->8613900432->TypeOfNumber:1->International->NumberingPlan:1->E.164OutTkMnem(DF35/10):4A494C5F443032202020202020202020->"JIL_D02"Forwarded-A-Party-Number(DF4A/08):A13195268021F8FF->13596208128FFF->TypeOfNumber:2->National->NumberingPlan:1->E.164===EndofRecord=== 附件1.简介话单的人工采集和分拣一、概述在所有话单问题的分析和解决过程中，采集并分拣出相关的话单是最重要的第一步。本文简单介绍了如何从USBS上采集和分拣话单的方法，以供大家参考。二、话单简介Ø话单分类1）目前在我们的计费系统中，将话单分为两大类：üDBILL（DetailedBilling）话单——用于本网手机间的通信计费结算；üDOR（DivisionOfRevenue）话单——用于不同网络间（如移动与联通、移动与公网）的通信计费结算；2）在DBILL话单中又按照不同的通信行为分为若干类型的话单，其中我们主要关心的是MOC（主叫）和MTC（被叫）话单。Ø话单保存1）在USBS计费系统中，话单保存于“/CDB/buffer”目录下，其中“dbill”目录保存DBILL话单，而“dor”目录保存DOR话单；2）每15分钟产生一个话单文件（其中包含了若干张话单），然后计费中心会进行采集，而该文件会在USBS上保存30天或60天，我们正是通过采集和分拣相关的话单文件，来分析解决话单问题。Ø话单标示1）在USBS计费系统中，话单文件是以一定的形式进行标示的：“局名.年.月.日.时间.编号”，例如Lab_10f.2002.08.30.0400.16就是2002年8月30日04:00在Lab_10f产生的话单文件，编号16，包含这天04:00—04:15时间段内产生的所有话单；2）在一个话单文件中有许多张话单，一张话单是以“E1”标示开头和结尾的。三、话单文件的采集以下介绍如何通过FTP的方法从USBS上采集话单文件：1、找到要采集的话单文件：Ø确定要采集话单的类型（DBorDOR），以便到相关目录下（/dbillor/dor）取话单文件；Ø按照相关的时间信息来确定要采集的话单文件，举例来说：如果在Lab_10f局下，通话行为发生并结束于2002年8月30日04:00—04:15时间段内，那么相关的话单就在这天04:00产生的话单文件（Lab_10f.2002.08.30.0400.16）中；Ø如果通信行为比较复杂（如有呼叫转移等），那就需要将相关的几张话单都找出来，才能将问题分析清楚。2、通过FTP采集相关话单文件。仍旧使用前面的这个例子（Lab_10f），介绍一种通过DOS下的FTP命令将相关话单文件从USBS系统上采集到本地终端的方法（当然也可以通过其他FTP方法来操作）：C:>cdtempC:TEMP>ftp202.65.5.74；FTP登陆USBS系统中的备用侧STATION Connectedto202.65.5.74.；连接备用侧STATION的IP220STATION_AFTPserver(DigitalUNIXVersion5.60)ready.User(202.65.5.74:(none)):uce_ins；FTP用户名331Passwordrequiredforuce_ins.Password:；密码是uce_test230Useruce_insloggedin.ftp>cd/CDB/buffer/dbill(/dor)；进入相关的话单目录250CWDcommandsuccessful.ftp>bin；以2进制方式传输200TypesettoI.ftp>getLab_10f.2002.08.30.0400.16；采集相关的话单文件200PORTcommandsuccessful.150OpeningBINARYmodedataconnectionforLab_10f.2002.08.30.0400.16(172.24.46.225,1480)(3547bytes).226Transfercomplete.ftp>bye221Goodbye.注：在USBS上操作要注意大小写的区别。一、话单的分拣现在我们可以通过billrec小工具来分拣话单了（续上例），这是一个DOS下运行的小程序，无需安装，只要通过命令来执行，具体步骤如下：1、将前面采集下来的话单文件复制到billrec程序所在目录下，并更改为“.txt”后缀的短文件名文件，如“Lab_10f.txt”，以便进行分拣；2、在DOS环境下运行billrec程序：billrecLab_10f.txt-d-flm7p2db.for；lm7p2db.for是分拣LM72版DBILL话单的库文件billrecLab_10f.txt-d-flm7tt.for；lm7tt.for是分拣LM7和LM72版DOR话单的库文件运行成功后，会产生后缀为“.brd”的文件，如“Lab_10f.brd”，这就是分拣以后的话单文件（分拣后的话单举例详见附件2）。二、小结通过上面的几步，我们就得到了分拣后的话单文件，然后再根据相关的信息（主/被叫号码，特服功能等），就可以找到我们所要分析的话单了。 附件2.LM72版话单举例1.DetailedBillingRecord=============BillingRecord(E1/7E):BillingRecordId*(DF63/08):50FC1A19253762B3RecordType(02/01):00->0->singleTypeACallTransactionType(02/01):02->2->mtcServedIMSI(C6/08):64003054094061F0->460003459004160FServedMSISDN(C7/08):683109434544F4FF->8613903454444FFFChargingTimeData(EE/0F):StartOfChargingDate*(D3/03):020912-12.09.02StartOfChargingTime(F4/05):TimeStamp*(04/03):105155-10:51:55CallDuration(D1/01):05->5s->00h00"05""TimeQuality(02/01):00->0->certainMSC-ID(CA/04):13900355->0-1-10-5/00D5OtherParty(C9/0C):91683105534544F4FFFFFFFF->8613503554444FFFFFFFFF->TypeOfNumber:1->International->NumberingPlan:1->E.164BasicServiceTeleService(D5/01):11->TS11,TelephonySupplementaryService(D7/01):21->cfuMSRN*(C5/08):91683109305532F3->8613900355233F->TypeOfNumber:1->International->NumberingPlan:1->E.164Network(DF5F/06):27007F02303BMSC(DF60/06):916831093055Forwarded-A-Party-Number(DF4A/0C):A13109534544F4FFFFFFFFFF->13903554444FFFFFFFFFFF->NatureOfAddr:33->BR-ERR:unknown->IncompleteNum.:0->complete->NumberingPlan:3->X.121->PresentationIndicator:0->Allowed->ScreeningIndicator:1->VerficationPassed===EndofRecord=== BR-Result:Translationofonerecordcompleted0warning(s),0error(s)foundinlastrecord-----------------------------------------------------------------2.Record=============BillingRecord(E1/A3):BillingRecordId*(DF63/08):50FC3B38753762B3RecordType(02/01):00->0->singleTypeACallTransactionType(02/01):01->1->mocServedIMSI(C6/08):64005005345283F4->460005504325384FServedMSISDN(C7/08):683109534544F4FF->8613903554444FFFChargingTimeData(EE/0F):StartOfChargingDate*(D3/03):020912-12.09.02StartOfChargingTime(F4/05):TimeStamp*(04/03):105155-10:51:55CallDuration(D1/01):05->5s->00h00"05""TimeQuality(02/01):00->0->certainMSC-ID(CA/04):13900355->0-1-10-5/00D5ConnectedSwitchIDBSC-ID(CB/02):2134->2-0-9-5/084DLocationAreaCode(CC/02):3550CellId(CF/02):714ATransactionIdentifier(CD/01):80OtherParty(C9/0C):813109434544F4FFFFFFFFFF->13903454444FFFFFFFFFFF->TypeOfNumber:0->Unknown->NumberingPlan:1->E.164BasicServiceTeleService(D5/01):11->TS11,TelephonyTransmissionMode(DB/01):03->requested->dual/full-ratepref->alloc->BR-ERR:unknown->transparencyindic->notrelevantMSClassMark(DC/02):1923GSM-SCF(DF5E/06):916831093044Service(DF61/01):03Network(DF5F/06):27007F02303BMSC(DF60/06):916831093055CAMELLegInformation(FF5A/1B):CAMELDestinationNumber(DF59/07):813109434544F4->13903454444F->TypeOfNumber:0->Unknown ->NumberingPlan:1->E.164ChargingTimeData(EE/0F):StartOfChargingDate*(D3/03):020912-12.09.02StartOfChargingTime(F4/05):TimeStamp*(04/03):105155-10:51:55CallDuration(D1/01):05->5s->00h00"05""===EndofRecord===2.DORRecord=============DetailedDORTicket(E1/52):RecordType(02/01):00->0->singleTypeAMSC-ID(C2/04):13900439->0-2-1-6/010EOtherParty(C3/0C):814093857320F8FFFFFFFFFF->04395837028FFFFFFFFFFF->TypeOfNumber:0->Unknown->NumberingPlan:1->E.164SeizureTimeInformation(E4/0E):StartOfSeizureDate*(C5/03):020822-22.08.02StartOfSeizureTime(C6/03):235813-23:58:13SeizureDuration(C7/02):009F->159s->00h02"39""ChargingTimeInformation(E8/0E):StartOfChargingDate*(C9/03):020822-22.08.02StartOfChargingTime(CA/03):235825-23:58:25CallDuration(CB/02):0094->148s->00h02"28""OutTkMnem(CD/10):4241535F445F47575F4D4C5320202020->"BAS_D_GW_MLS"CallingPartyAddress(D1/07):A13126341989F1->13624391981F->TypeOfNumber:2->National->NumberingPlan:1->E.164===EndofRecord=== 附件3.EPM的IP设置与检查一、概述我们计费系统的话单输出和采集功能，是通过交换机的EPM模块以TCP/IP协议联接到USBS系统来实现的，本文简述了在Evolium(TM)MSCALM7/7.2/8交换机中对EPM模块进行IP地址设置并联接到USBS系统以及检查的基本方法，可以作为现场工程师进行相关操作的参考。二、EPM的IP设置和与USBS的联接EPM主要负责传送计费话单至USBS及与USBS交互一些告警及报告信息。USBS通过两个内部的子网与EPM通信:ØSubneta10.0.253.0PrimaryLANØSubnetb10.0.254.0SecondaryLAN而USBS亦有对应的内部网址：ØSTATION_A10.0.253.25410.0.254.254ØSTATION_B10.0.253.25310.0.254.253可以注意到每台USBS分别在253&254网段各有一个IP地址，它的作用是分别与不同的EPM模块通讯。EPM模块可以通过5827（HANDLE-IP-CONF）命令来设置IP地址及对应USBS的STATIONIP地址，同时也可以用该命令察看已设置的IP地址。具体格式如下:CommandReferenceNumber:5827CommandMnemonic:HANDLE-IP-CONFRoutingNumber:19236Dialform-Name:BU23AA03ParameterArgNbrMnemonicValue1LCEID12DISPLAY3MODIFY4OWNADDR45NAMASK46DEFGTW47IPMTU1其中参数6DEFGTW指的是和EPM对应USBSSTATION的IP地址。正确的设置应该是不同的EPM指向不同的USBSSTATIONIP地址。例如：ØEPM1LCEID4860(59A0)OWNADDR(10.0.253.1)DEFGTW(10.0.253.253)NAMASK(255.255.255.0) <5827:1=H"59A0,3,4=10&0&253&1,5=255&255&255&0,6=10&0&253&253.(1=LCEIDofEPM1,3=MODIFY,4=IPaddressofEPM1,6=IPaddressofUSBSSTATION_B)ØEPM2LCEID4870(59B0)OWNADDR(10.0.254.1)DEFGTW(10.0.254.254)NAMASK(255.255.255.0)<5827:1=H"59B0,3,4=10&0&254&1,5=255&255&255&0,6=10&0&254&254.(1=LCEIDofEPM1,3=MODIFY,4=IPaddressofEPM2,6=IPaddressofUSBSSTATION_A)需要注意的是不可同时把所有EPM指向同一个IP地址的USBSstation，否则当该station出问题时，EPM仍会试图传送话单给它而不会传送至正常工作的一侧。将会造成计费传输中断，导致严重的后果。当然，在现场安装工程中，由于可能有很多EPM模块，我们建议使用MACRO通过直接修改相关RELATION的方法来批量设置EPM的IP地址。需要注意的是设置时应该使用最新版本的MACRO。例如，对于10个以内的EPM,请用EPMIPS.TXT设置,对于10个以上的EPM,请用EPMIPL.TXT设置:>:CEIDSC,EPMNA=0004LCE=59A0VP=0050GLSID=>292TDLSID=>1066TCETYPE=EPMDBSNA=0005LCE=59B0VP=0060GLSID=>292TDLSID=>1067TCETYPE=EPMDBSNA=0007LCE=59C0VP=0080GLSID=>292TDLSID=>1068TCETYPE=EPMDBSNA=0014LCE=59D0VP=00F0GLSID=>292TDLSID=>1069TCETYPE=EPMDBSNA=0015LCE=59E0VP=0100GLSID=>292TDLSID=>1070TCETYPE=EPMDBSNA=0024LCE=59F0VP=01B0GLSID=>292TDLSID=>1071TCETYPE=EPMDBSNA=2300LCE=5A00VP=2320GLSID=>292TDLSID=>1072TCETYPE=EPMDBSNA=2301LCE=5A10VP=2330GLSID=>292TDLSID=>1073TCETYPE=EPMDBSNA=2302LCE=5A20VP=2340GLSID=>292TDLSID=>1074TCETYPE=EPMDBSNA=2303LCE=5A30VP=2350GLSID=>292TDLSID=>1075TCETYPE=EPMDBSNA=2304LCE=5A40VP=2360GLSID=>292TDLSID=>1076TCETYPE=EPMDBSNA=2305LCE=5A50VP=2370GLSID=>292TDLSID=>1077TCETYPE=EPMDBSNA=2306LCE=5A60VP=2380GLSID=>292TDLSID=>1078TCETYPE=EPMDBSNA=2307LCE=5A70VP=2390GLSID=>292TDLSID=>1079TCETYPE=EPMDBSENDOFLIST!你可以这样使用MACRO——>:EPMIPS:EPMIPS1,4,59A0:EPMIPS2,5,59B0:EPMIPS3,7,59C0:EPMIPS4,14,59D0:EPMIPS5,15,59E0:EPMIPS6,24,59F0:EPMIPS7,2300,5A00:EPMIPS8,2301,5A10:EPMIPS9,2302,5A20 :EPMIPS10,2303,5A30:EPMIPL11,2304,5A40:EPMIPL12,2305,5A50:EPMIPL13,2306,5A60:EPMIPL14,2307,5A70注：如果你运行MACRO时遇到问题，例如tuple没有找到。请读以下关于EPMrelation设置的文章。设置完EPM的IP地址后，应该用USBS配备的网线将EPM与USBS系统的HUB正确地联接起来。检查MSC上配了多少EPM模块，我们要求每个EPM模块都应有线连接到USBS的HUB上。IP地址为10.0.253.*（1、2、3、……）的EPM必须联接到PrimaryLANHUB，而IP地址为10.0.254.*（1、2、3、……）的EPM必须联接到SecondaryLANHUB。两个HUB面板上的1到11端口都可以用来联接EPM，并且当正确联接后，相关端口上的指示灯会点亮。具体的连接方法也可以询问USBS专家。一、EPM的IP检查设置联接完EPM并非万事大吉，还要记得检查EPM的IP设置的是否正确，话单数据传输是否正常；此外，平时维护中如果发现话单输出有问题或出现相关的告警（如LCHI），也别忘了首先通过以下正确的方法来检查EPM模块的IP设置，以及与USBS系统的联接情况和传输情况。前面提到过，用人机命令5827（HANDLE-IP-CONF）可以察看EPM的IP地址设置，例如我们要察看EPM——LCEID4860(59A0)的IP设置，就用以下命令：<5827:1=H’59A0,2.(1=LCEIDofEPM,2=DISPLAY)那么怎么确定EPM与USBS之间的联接是否正常呢？我们可以通过“PING”命令来检查。我们可以从交换机EPM模块PINGUSBS，当然也可以反过来从USBS来PINGEPM模块。Ø从交换机EPM模块PINGUSBS在IP为10.0.253.*的EPM模块上，用命令“PING”USBS(10.0.253.253和10.0.253.254)；在IP为10.0.254.*的EPM模块上，用命令“PING”USBS(10.0.254.253和10.0.254.254)；应该看到成功报告才说明EPM与USBS之间的联接正常。例：EPM模块数据是否足够（用户量大的交换机都要8块EPM,一般性4块，偏僻地区用户量非常少的2块)2>确保所有的EPM模块都有电缆连接到USBS2）但我发现很多OLEX后新扩的EPMDBS模块里少TUPLE（在运行你的MACRO时出现NOTUPLEFOUND），这个情况在江苏很普遍。我想知道这一堆有关计费的RELATION有没有标准的POP法可遵循，我也好依据CREATE-TUPLE。答：如果缺少TUPLE，必须创建。具体创建内容可以参考正常运行的EPMDBS里的相关relation（R_IP_INIT,R_FLIP_INI,R_WS_FLIST)，直到MACRO(EPMIP)没有错误为止。当前最新版本的MACRO包含了所有有意义的DOMAIN，建议使用最新版本的MACRO。3）有几个局CAE将模块类型POP成EPMBS，这种模块类型能用作计费输出吗？有没有必要修改R_GLSSWCD1将它改成EPMDBS？答：必须修改为EPMDBS。4）江苏EPM模块都配置了4块以上，但EPM电缆都只有2根（少数配了4根以上），我想知道话务量与EPM模块数量之间的关系，达到多少话务量会导致溢出？答：具体话务量与EPM模块数量之间的关系需要与CAE硬件方面联系。不过，我觉得问题还是主要在没有配足电缆的问题引起。5）很多交换机OLEX后，新的EPM模块没有电缆是否要紧？没有电缆的EPM模块就像没有网线的网卡，形同虚设。建议赶快把所有的EPM模块都配置电缆连接到USBS。6)EPM与USBS传输不通，怎么办？如果是新局，可以参见第二节设置EPM数据。如果是运行局，而且之前曾传输通畅的话，排除由于人为因素（如OLEX等）后，请按以下流程操作：-把EPM模块插拔；-确认EPM在传输数据到USBS；-如果还不行，建议更换硬件（板子，线，USBS侧换用另一个网线端口）；7）如果USBS与计费中心断开是否出告警？答：否，但一般计费中心的话单采集程序会出告警。 8）USBS与MSC之间吐话单的通路断开是否有告警？答：有，TAXOUT告警(SACECHRS模块)会立即出现。9）USBS与MSC之间吐话单的通路如果溢出，时间大概为多久？答：话单会暂时存放在各个中继模块内（MRSACE,SACEIN,EISUPTCE,ENTUPTCE)，一般情况下可坚持6小时左右。（具体溢出时间取决于中继模块的数目和当时的时段是否是忙时）如果中继模块内存溢出，会对相应中继模块出NOCHGCELL告警，表示此中继模块无法继续计费同时通话停止。但可运行宏来删除部分话单，以保持通话畅通，直到USBS与MSC之间吐话单的通路恢复。10）如果USBS与MSC之间吐话单的通路很忙，那么USBS吐告警报告能否稍缓？（吐话单的级别最高）答：USBS吐告警报告对通路负荷的占用极小,可以忽略不计.