> Appendix 1
> XML Output Formats
> This appendix provides information about the various eXtensible Markup Language (XML) file format definitions in the Bulkstat server. The XML file format definition is based on XML schema. The 3GPP standards are followed to generate XML report files in the XML report generator. These defined file format definitions correspond to each other (except for some minor XML specific optimizations).
> This chapter includes the following topics:
> Supported XML Output Formats
> The following XML output formats are supported:

> • | DTD Based Format: This format is DTD based and it can be enabled/disabled using the configurable parameter, ‘XMLFileFormat’ provided in the configuration file bsserver.cfg in the /<ems_dir>/etc directory.

> • | 3GPP Format: This is the new and default 3GPP recommended format to generate the XML report file. This format reduces the XML file size.

> WEM generates two types of files for the above two formats. These are individual XML files for all subsystems and single XML file for all subsystems which can be configured using the parameter ‘XMLFileType’ in the bsserver.cfg file.
> Refer Appendix B for information on the configurable parameters in the bsserver.cfg file.
> Examples of XML Output Formats
> This section provides the sample outputs for the DTD based and 3GPP XML formats.
> DTD Based Format
> This following output is an example of individual files for all subsystems in DTD based XML format.
> <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
> <!DOCTYPE mdc SYSTEM "MeasurementStat.dtd">
> <?xml-stylesheet type="text/xsl" href="simple_table.xsl" ?>
> <mdc>
> <mfh>
> <ffv>2</ffv>
> <sn>Starent Network Inc.</sn>
> <st>MSC</st>
> <vn>Samsung corp.</vn>
> <cbt>2006-01-03 13:10:00</cbt>
> </mfh>
> <md>
> <neid>
> <neun></neun>
> <nedn></nedn>
> <nesw></nesw>
> </neid>
> <mi>
> <mts>2006-01-03 13:15:00</mts>
> <gp>300</gp>
> <rsf>false</rsf>
> <ms>
> <msn>CardStat</msn>
> <sf>false</sf>
> <es>false</es>
> <mt p="0">card</mt>
> <mt p="1">cpubusy</mt>
> <mt p="2">cpuidle</mt>
> <mt p="3">numproc</mt>
> <mt p="4">memused</mt>
> <mt p="5">memtotal</mt>
> <mv>
> <moid> card=17 </moid>
> <r p="0">6</r>
> <r p="1">0.76</r>
> <r p="2">99.24</r>
> <r p="3">158</r>
> <r p="4">1057704</r>
> <r p="5">4194304</r>
> </mv>
> <mv>
> <moid> card=8 </moid>
> <r p="0">8</r>
> <r p="1">0.45</r>
> <r p="2">99.55</r>
> <r p="3">65</r>
> <r p="4">306512</r>
> <r p="5">1048576</r>
> </mv>
> </ms>
> </mi>
> </md>
> <mff>
> <ts>2006-01-03 13:15:00</ts>
> </mff>
> </mdc>
> This following output is an example of all subsystems in a single file in DTD based XML format.
> <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
> <!DOCTYPE mdc SYSTEM "MeasurementStat.dtd">
> <?xml-stylesheet type="text/xsl" href="simple_table_all.xsl" ?>
> <mdc>
> <mfh>
> <ffv>2</ffv>
> <sn>Starent Network Inc.</sn>
> <st>MSC</st>
> <vn>Samsung corp.</vn>
> <cbt>2006-01-03 13:10:00</cbt>
> </mfh>
> <md>
> <neid>
> <neun></neun>
> <nedn></nedn>
> <nesw></nesw>
> </neid>
> <mi>
> <mts>2006-01-03 13:15:00</mts>
> <gp>300</gp>
> <rsf>false</rsf>
> <ms>
> <msn>CardStat</msn>
> <sf>false</sf>
> <es>false</es>
> <mt p="0">card</mt>
> <mt p="1">cpubusy</mt>
> <mt p="2">cpuidle</mt>
> <mt p="3">numproc</mt>
> <mt p="4">memused</mt>
> <mt p="5">memtotal</mt>
> <mv>
> <moid> card=17 </moid>
> <r p="0">17</r>
> <r p="1">0</r>
> <r p="2">100</r>
> <r p="3">0</r>
> <r p="4">0</r>
> <r p="5">0</r>
> </mv>
> <mv>
> <moid> card=8 </moid>
> <r p="0">8</r>
> <r p="1">0.45</r>
> <r p="2">99.55</r>
> <r p="3">65</r>
> <r p="4">306512</r>
> <r p="5">1048576</r>
> </mv>
> </ms>
> <ms>
> <msn>PortStat</msn>
> <sf>false</sf>
> <es>false</es>
> <mt p="0">card</mt>
> <mt p="1">port</mt>
> <mt p="2">rxbytes</mt>
> <mt p="3">txbytes</mt>
> <mt p="4">ucast_inpackets</mt>
> <mt p="5">ucast_outpackets</mt>
> <mt p="6">mcast_inpackets</mt>
> <mt p="7">mcast_outpackets</mt>
> <mt p="8">bcast_inpackets</mt>
> <mt p="9">bcast_outpackets</mt>
> <mt p="10">rxpackets</mt>
> <mt p="11">txpackets</mt>
> <mt p="12">rxdiscbytes</mt>
> <mt p="13">rxdiscpackets</mt>
> <mt p="14">txdiscbytes</mt>
> <mt p="15">txdiscpackets</mt>
> <mt p="16">maxrate</mt>
> <mt p="17">frag-rcvd</mt>
> <mt p="18">pkt-reassembled</mt>
> <mt p="19">frag-tokernel</mt>
> <mv>
> <moid> card=17,port=1 </moid>
> <r p="0">17</r>
> <r p="1">1</r>
> <r p="2">43346</r>
> <r p="3">1792</r>
> <r p="4">328</r>
> <r p="5">28</r>
> <r p="6">0</r>
> <r p="7">0</r>
> <r p="8">1</r>
> <r p="9">0</r>
> <r p="10">329</r>
> <r p="11">28</r>
> <r p="12">0</r>
> <r p="13">0</r>
> <r p="14">0</r>
> <r p="15">0</r>
> <r p="16">0</r>
> <r p="17">0</r>
> <r p="18">0</r>
> <r p="19">0</r>
> </mv>
> </ms>
> <ms>
> <msn>IPPoolStat</msn>
> <sf>false</sf>
> <es>false</es>
> <mt p="0">vpnname</mt>
> <mt p="1">vpnid</mt>
> <mt p="2">name</mt>
> <mt p="3">used</mt>
> <mt p="4">hold</mt>
> <mt p="5">release</mt>
> <mt p="6">free</mt>
> <mt p="7">type</mt>
> <mt p="8">priority</mt>
> <mt p="9">state</mt>
> <mv>
> <moid> vpnname=network,vpnid=2,name=Pool </moid>
> <r p="0">network</r>
> <r p="1">2</r>
> <r p="2">Pool</r>
> <r p="3">0</r>
> <r p="4">0</r>
> <r p="5">0</r>
> <r p="6">254</r>
> <r p="7">S</r>
> <r p="8">0</r>
> <r p="9">G</r>
> </mv>
> </ms>
> </mi>
> </md>
> <mff>
> <ts>2006-01-03 13:15:00</ts>
> </mff>
> </mdc>
> 3GPP Format
> This following output is an example of individual files for all subsystems in 3GPP XML format.
> <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
> <!--?xml-stylesheet type="text/xsl" href="MeasDataCollection.xsl?"-->
> <measCollecFile xmlns="http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec">
> <fileHeader dnPrefix="Unknown" fileFormatVersion="2" vendorName="Sagar">
> <fileSender elementType="Nikhil" localDn="Same"/>
> <measCollec beginTime="2008-04-25 04:40:00"/>
> </fileHeader>
> <measData>
> <managedElement localDn="Same" swVersion="7.1.19504" userLabel="st16"/>
> <measInfo>
> <job jobId="7381"/>
> <granPeriod duration="PT300S" endTime="2008-04-25 04:45:00"/>
> <msn>CardStat</msn>
> <suspect>false</suspect>
> <measTypes>card cpubusy cpuidle numproc memused memtotal</measTypes>
> <measValue measObjLdn="card=22">
> <measResults>22 0 100 0 0 0</measResults>
> </measValue>
> <measValue measObjLdn="card=24">
> <measResults>24 0 100 0 0 0</measResults>
> </measValue>
> </measInfo>
> </measData>
> <fileFooter>
> <measCollec endTime="2008-04-25 04:45:00"/>
> </fileFooter>
> </measCollecFile>
> This following output is an example of all subsystems in a single file in 3GPP XML format.
> <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
> <!--?xml-stylesheet type="text/xsl" href="MeasDataCollection.xsl?"-->
> <measCollecFile xmlns="http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec">
> <fileHeader dnPrefix="Unknown" fileFormatVersion="2" vendorName="Sagar">
> <fileSender elementType="Nikhil" localDn="Same"/>
> <measCollec beginTime="2008-04-25 04:40:00"/>
> </fileHeader>
> <measData>
> <managedElement localDn="Same" swVersion="7.1.19504" userLabel="st16"/>
> <measInfo>
> <job jobId="7381"/>
> <granPeriod duration="PT300S" endTime="2008-04-25 04:45:00"/>
> <msn>CardStat</msn>
> <suspect>false</suspect>
> <measTypes>card cpubusy cpuidle numproc memused memtotal</measTypes>
> <measValue measObjLdn="card=22">
> <measResults>22 0 100 0 0 0</measResults>
> </measValue>
> <measValue measObjLdn="card=24">
> <measResults>24 0 100 0 0 0</measResults>
> </measValue>
> <msn>PortStat</msn>
> <suspect>false</suspect>
> <measTypes>card port rxbytes txbytes ucast_inpackets ucast_outpackets mcast_inpackets mcast_outpackets bcast_inpackets bcast_outpackets rxpackets txpackets rxdiscbytes rxdiscpackets txdiscbytes txdiscpackets maxrate frag-rcvd pkt-reassembled frag-tokernel</measTypes>
> <measValue measObjLdn="card=22,port=1">
> <measResults>22 1 1236 1024 16 16 0 0 2 0 18 16 0 0 0 0 100000000 0 0 0</measResults>
> </measValue>
> <measValue measObjLdn="card=22,port=2">
> <measResults>22 2 212 0 0 0 0 0 2 0 2 0 0 0 0 0 100000000 0 0 0</measResults>
> </measValue>
> <msn>IPPoolStat</msn>
> <suspect>false</suspect>
> <measTypes>vpnname vpnid name startaddr groupname used hold release free type priority state</measTypes>
> <measValue measObjLdn="vpnname=egress,vpnid=6,name=dynamic,startaddr=17.0.0.1,groupname=">
> <measResults>egress 6 dynamic 17.0.0.1 0 0 0 65534 P 0 G</measResults>
> </measValue>
> <measValue measObjLdn="vpnname=egress,vpnid=6,name=static,startaddr=18.0.0.1,groupname=">
> <measResults>egress 6 static 18.0.0.1 0 0 0 65534 S 0 G</measResults>
> </measValue>
> </measInfo>
> </measData>
> <fileFooter>
> <measCollec endTime="2008-04-25 04:45:00"/>
> </fileFooter>
> </measCollecFile>
> File Naming Conventions
> The naming conventions for the files are as per 3GPP standard. The naming convention is different only for individual subsystem files where we include subsystem names in the file name (for example, “CardStat”, “PortStat”, etc.).
> The following convention will be applied for measurement result file naming:
> <Type><Startdate>.<Starttime>-[<Enddate>.]<Endtime>_[<UniqueId>][:<RC>]

> Field Name | Description
> Type | Indicates if the file contains measurement results for single or multiple NEs and/or granularity periods, where:
> • | “A” indicates single NE, single granularity period;
> • | “B” indicates multiple NEs, single granularity period;
> • | “C” indicates single NE, multiple granularity periods;
> • | “D” indicates multiple NEs, multiple granularity periods.
> Startdate | Indicates the date when the granularity period began if the Type field is set to “A” or “B”. If the Type field is either “C” or “D” then, Startdate contains the date when the first granularity period of the measurement results contained in the file started. The Startdate field is of the form YYYYMMDD, where:
> • | YYYY is the year in four digit notation;
> • | MM is the month in two digit notation (01-12);
> • | DD is the day in two digit notation (01-31).
> Starttime | Indicates the time when the granularity period began if the Type field is set to A or B. If the Type field is either “C” or “D” then, Starttime contains the time when the first granularity period of the measurement results contained in the file began. The Starttime field is of the form HHMMshhmm, where:
> • | HH is the two digit hour of the day (local time), based on 24 hour clock (00-23);
> • | MM is the two digit minute of the hour (local time), possible values are 00, 05, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55;
> • | s is the sign of the local time differential from UTC (+ or -), in case the time differential to UTC is 0 then the sign may be arbitrarily set to “+” or “-”;
> • | hh is the two digit number of hours of the local time differential from UTC (00-23);
> • | mm is the two digit number of minutes of the local time differential from UTC (00-59).
> Enddate | This field will only be included if the Type field is set to “C” or “D”, that is, measurement results for multiple granularity periods are contained in the file. It identifies the date when the last granularity period of these measurements ended, and its structure corresponds to the Startdate field.
> Endtime | Indicates the time when the granularity period ended if the Type field is set to A or B. If the Type field is either “C” or “D” then, Endtime contains the time when the last granularity period of the measurement results contained in the file ended. Its structure corresponds to the Starttime field, however, the allowed values for the minute of the hour are 05, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, and 00.
> UniqueId | This is the name of the NE, EM or domain (for example, a distinguishedName). The field may be omitted only if the distinguishedName is not available from the CM applications.
> RC | This parameter is a running count, starting with the value of “1”, and will be appended only if the filename is not unanimous, that is, more than one file is generated and all other parameters of the file name are identical. Therefore, it may only be used by the Network Element Manager (EM), since the described situation can not occur with Network Element (NE) generated files.

> A few examples describing the file naming convention are as follows:

> • | File name: A20000626.2315+0200-2330+0200_NodeBId;

> Meaning: File produced by NodeB <NodeBId> on June 26, 2000, granularity period 15 minutes from 23:15 local to 23:30 local, with a time differential of +2 hours against UTC.

> • | File name: B20021224.1700-1130-1705-1130_EMId,

> Meaning: File containing results for multiple NEs, produced by EM <EMId> on December 24, 2002, granularity period 5 minutes from 17:00 local to 17:05 local, with a time differential of –11:30 hours against UTC.

> • | File name: D20050907.1030+0000-20050909.1500+0000_DomainId:2,

> Meaning: File containing results for NEs belonging to domain <DomainId>, start of first granularity period 07 September 2005, 10:30 local, end of last granularity period 09 September 2005, 15:00 local, with a time differential of 0 against UTC. This file is produced by the EM managing the domain, and it is the second file for this domain/granularity periods combination.
> Supported Standards
> WEM complies with the following 3rd Generation Partnership Project (3GPP) standards for generation of XML report files in DTD based format and 3GPP format respectively.

> • | 3GPP TS 32.401 V4.1.0 (2001-12): “Concept and Requirements”

> • | 3GPP TS 32.435 V6.2.0 (2006-03): “Performance measurement: eXtensible Markup Language (XML) file format definition”

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883