delta document for billing changes€¦ · web viewany of these alterations could impact revenue...

Cisco Systems BTS 10200

Billing Changes for Release 5.0

Version 1.0

Corporate HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USAhttp://www.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 526-4100

http://www.cisco.com/

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not installed in accordance with Cisco’s installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation.

You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by the Cisco equipment or one of its peripheral devices. If the equipment causes interference to radio or television reception, try to correct the interference by using one or more of the following measures:

Turn the television or radio antenna until the interference stops.

Move the equipment to one side or the other of the television or radio.

Move the equipment farther away from the television or radio.

Plug the equipment into an outlet that is on a different circuit from the television or radio. (That is, make certain the equipment and the television or radio are on circuits controlled by different circuit breakers or fuses.)

Modifications to this product not authorized by Cisco Systems, Inc. could void the FCC approval and negate your authority to operate the product.

The following third-party software may be included with your product and will be subject to the software license agreement:

CiscoWorks software and documentation are based in part on HP OpenView under license from the Hewlett-Packard Company. HP OpenView is a trademark of the Hewlett-Packard Company. Copyright 1992, 1993 Hewlett-Packard Company.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.

Network Time Protocol (NTP). Copyright 1992, David L. Mills. The University of Delaware makes no representations about the suitability of this software for any purpose.

Point-to-Point Protocol. Copyright 1989, Carnegie-Mellon University. All rights reserved. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission.

The Cisco implementation of TN3270 is an adaptation of the TN3270, curses, and termcap programs developed by the University of California, Berkeley (UCB) as part of the UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright 1981-1988, Regents of the University of California.

Cisco incorporates Fastmac and TrueView software and the RingRunner chip in some Token Ring products. Fastmac software is licensed to Cisco by Madge Networks Limited, and the RingRunner chip is licensed to Cisco by Madge NV. Fastmac, RingRunner, and TrueView are trademarks and in some jurisdictions registered trademarks of Madge Networks Limited. Copyright 1995, Madge Networks Limited. All rights reserved.

Xremote is a trademark of Network Computing Devices, Inc. Copyright 1989, Network Computing Devices, Inc., Mountain View, California. NCD makes no representations about the suitability of this software for any purpose.

The X Window System is a trademark of the X Consortium, Cambridge, Massachusetts. All rights reserved.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PRACTICAL PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

AccessPath, AtmDirector, Browse with Me, CCIP, CCSI, CD-PAC, CiscoLink, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Cisco Unity, Fast Step, Follow Me Browsing, FormShare, FrameShare, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, ScriptBuilder, ScriptShare, SMARTnet, TransPath, Voice LAN, Wavelength Router, and WebViewer, Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, GigaStack, IOS, IP/TV, LightStream, MICA, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are trademarks or registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0110R).

Please refer to http://www.cisco.com/logo/ for the latest information on Cisco logos, branding and trademarks.

INTELLECTUAL PROPERTY RIGHTS:

THIS DOCUMENT CONTAINS VALUABLE TRADE SECRETS AND CONFIDENTIAL INFORMATION OF CISCO SYSTEMS, INC. AND IT’S SUPPLIERS, AND SHALL NOT BE DISCLOSED TO ANY PERSON, ORGANIZATION, OR ENTITY UNLESS SUCH DISCLOSURE IS SUBJECT TO THE PROVISIONS OF A WRITTEN NON-DISCLOSURE AND PROPRIETARY RIGHTS AGREEMENT OR INTELLECTUAL PROPERTY LICENSE AGREEMENT APPROVED BY CISCO SYSTEMS, INC. THE DISTRIBUTION OF THIS DOCUMENT DOES NOT GRANT ANY LICENSE IN OR RIGHTS, IN WHOLE OR IN PART, TO THE CONTENT, THE PRODUCT(S), TECHNOLOGY OF INTELLECTUAL PROPERTY DESCRIBED HEREIN.

Delta document for Billing changesCopyright 2005, Cisco Systems, Inc.All rights reserved.COMMERCIAL IN CONFIDENCE.A PRINTED COPY OF THIS DOCUMENT IS CONSIDERED UNCONTROLLED.

http://www.cisco.com/logo/

iii

Contents

Contents........................................................................................................................................ 3

Revision History........................................................................................................................... 4

Overview....................................................................................................................................... 1

Scope.....................................................................................................................................................1

Strategy.................................................................................................................................................1

Operation Changes......................................................................................................................2

Billing Account Address Command.....................................................................................................2

File Name Convention..........................................................................................................................2

Report Billing Record Command.........................................................................................................3

CDR Field Changes......................................................................................................................4

General field changes...........................................................................................................................4

General field changes.........................................................................................................................16


iv

Revision History

Product: BTS 10200Release: BTS 900-05.00.00Date: December 15, 2006

Table 1 Revision History

Version No. Issue Date Status Reason for Change

1.0 2006-12-15 Draft Initial Draft


5

EDCS-xxxxx

This page intentionally left blank


Overview

The purpose of this paper is to provide high level overview of the changes to the billing interface for the BTS 10200 release 5.0

Scope

The scope of these changes are with respect to the BTS 10200 release 4.5.1 V14 (FSC). There are no modifications to the XML schema in this release.

Strategy

The CDR or Call Detail Records for the BTS 10200 may change from release to release in support of new and different features. These changes may include new fields, removal of old fields or amended definitions for existing fields. Any of these alterations could impact revenue accounting or other mediation devices accessing the BTS 10200.

2

Operation Changes

This section lists the changes that effect the operational behavior of CDR based billing and/or its configuration.

Billing Account Address Command

This CLI command is modified to support an additional parameter as detailed below.

change billing-acct-addr billing-file-prefix=CALL_DETAIL_DATA_; billing-server-addr=rao.customer.com; billing-server-directory=/export/billing/ftp/inbound; username=customer001; password=test; polling-interval=15; deposit-confirmation-file=y; billing-filename-type=default;

billing-filename-type – this parameter determines which file naming format to use for the CDR files that are created on the system. Any changes to this value only take affect when the BDMS platform is restarted. The value of INSTALLED indicates to use the value that was established at sysetm installation time. The valid choices are: INSTALLED, PACKET-CABLE, and NON-PACKET-CABLE. The default is set to INSTALLED

File Name Convention

The BTS 10200 supports two different billing record file naming conventions. The selection of the convention is done at installation time by setting a new parameter in the platform.cfg file. Including the following statement in the platform.cfg file, will trigger the system to generate files with the alternate naming convention, otherwise the default naming convention is used.

<billing-file-prefix>-<call-agent-id>-(0/1){+/-}HHMMSS-yyyymmdd-hhmmss-<sequence-number>-<state>

where: <billing-file-prefix> is the billing file prefix from the billing-acct-addr

table <call-agent-id> is the call agent id from the call-agent table (0/1): daylight saving time, on = 1, off = 0 {+/-}HHMMSS is the UTC offset time yyyymmdd-hhmmss is the time the file was created <sequence-number> is a monotonically increasing 6 digit number from


3

000001 to 999999 that will roll over to 000001 after the maximum number of 999999 is reached <state> is a letter indicating the state of the file where P indicates primary data (complete file but un-transferred), S indicates secondary data (complete file and transferred), and O indicates open (current open file that is incomplete and un-transferred)

Report Billing Record Command

CDR billing now supports time formates in the milli-second range. start-time – this is a time stamp value in the format of YYYY-MM-DD

HH:MM:SS.mmm. This value indicates the starting time to filter against in the search for when billing records were written to the database. If the milliseconds portion of the time stamp is ommitted, a value of 000 is implied. This is an optional token that has no default value.

stop-time – this is a time stamp value in the format of YYYY-MM-DD HH:MM:SS.mmm. This value indicates the stopping time to filter against in the search for when billing records were written to the database. If the milliseconds portion of the time stamp is ommitted, a value of 000 is implied. This is an optional token that has no default value.

Also, new Term types have been added as well. SESSION_TIMER_REFRESH_TIMEOUT AUDIT_RELEASE

New service types are also added and available in this command. MULTIPLE DIRECTORY NUMBER SIP REPLACE CALL FORWARD REDIRECTION OFF HOOK TRIGGER TERMINATION ATTEMPT TRIGGER


4

CDR Field Changes

This section details the modification to the CDR fields in the BTS 10200 release 5.0.

General field changes

Field Name type Size Potential Values Data Source Description

2 Signal Start Time

Numeric 128 bit unsigned value in total. 64 bit seconds and 64 bit milliseconds in GMT epoch time format – the number of milli-seconds since Jan 01, 1970 0:00:00.000h if the value is NULL – the timestamp is to be ignored

Dynamic run time data from the system clock

Receipt of an MGCP NTFY or SS7 IAM or SIP SETUP for example

3 Signal Stop Time



Upon the last one of the following signaling events: transmission of MGCP DLCX or transmission/receipt of an RLC or transmission/receipt of last signaling message to/from a peer CMS/MGC

4 Interconnect Start Time



Upon commitment of bandwidth between the IP/ATM and PSTN networks – this is at the time of seizure.

5 Interconnect Stop Time

Numeric 128 bit unsigned value in total. 64 bit seconds and 64 bit milliseconds in GMT epoch time format – the number of milli-seconds since Jan 01, 1970 0:00:00.000h if the value is NULL – the timestamp is to be


Upon release of bandwidth between the IP/ATM and PSTN networks


5

ignored

6 Call Connect Time



Upon receipt of an MGCP NTFY indicating off-hook, or SS7 ANS, or answer indication from the media gateway for an operator services trunk

7 Call Answer Time



Upon both parties being off-hook for at least 2 seconds. Currently the BTS does not support Short Supervisory Transitions, so the contents of this field and field #6 will be identical.

8 Call Disconnect Time



Upon receipt of an MGCP NTFY indicating on-hook of the calling party, or expiration of the call-continuation timer, an SS7 REL, or an indication from the media gateway that the operator services trunk has disconnected

9 Database Query Time1



The time the first database query response was received for this call.

10 Service Instance Time1

Numeric 128 bit unsigned value in total. 64 bit seconds and 64 bit milliseconds in GMT epoch time format – the number of milli-seconds since Jan 01 1970:00:00.000h if the value is NULL – the timestamp is to be


The time the instance of Service Type 1 occurred.


6

ignored









13 Service Activation Time 1



The time the activation of Service Type 1 occurred.




The time the activation of Service Type 2 occurred.




The time the activation of Service Type 3 occurred..

16 Service Numeric 128 bit unsigned value Dynamic run time data The time the


7

Deactivation Time 1

in total. 64 bit seconds and 64 bit milliseconds in GMT epoch time format – the number of milli-seconds since Jan 01, 1970 0:00:00.000h if the value is NULL – the timestamp is to be ignored

from the system clock deactivation of Service Type 1 occurred.

17 Service Deactivation Time 2



The time the deactivation of Service Type 2 occurred.

18 Service Deactivation Time 3



The time the deactivation of Service Type 3 occurred.

19 Call Elapsed Time

String 12-17

(dddd):hh:mm:ss.mmm Calculated value The duration that the voice path was established. The days (dddd) portion of this field is optional and variable in length depending on the number of days the calls has been connected. If this field is NULL, then no data was captured for this record.

20 Interconnect Elapsed Time

String 12-17

(dddd):hh:mm:ss.mmm Calculatevalue The duration that bandwidth was established with another carrier. The days (dddd) portion of this field is optional and variable in length depending on the number of days the calls has been


8

connected. If this field is NULL, then no data was captured for this record.

21 Originating QOS Time



Receipt of the MGCP DLCX ACK message. The time the originating side quality of service measurements were collected. This information is collected on a best effort basis and will not be present if the QoS collection timeout is exceeded. If this field is NULL – then the associated Originating QOS parameters are to be ignored.

22 Terminating QOS Time



Receipt of the MGCP DLCX ACK message. The time the terminating side quality of service measurements were collected. This information is collected on a best effort basis and will not be present if the QoS collection timeout is exceeded. If this field is NULL – then the associated Terminating QOS parameters are to be ignored.

23 Originating Number

String 64 DIGITS Subscriber::DN1 or ISDN SETUP or SS7 IAM or SIP INVITE for example

This field contains the calling party number after it has gone through the complete translation process on the BTS including any possible overriding. If the originator is a SIP endpoint, this field will contain the tel-number in the “From” field between the “:” and the “@” characters


9

if the PAI flag is not set, if the PAI is set, this field contains the tel-num from the “P-Asserted-Identity” field between the “:” and the “@” characters. If this field is NULL, then no data was captured for this field.

40 MLH Group String 16 Up to a 16 character group name

Subscriber::MlhgId Identity of the multi-line hunt group that this call is associated with. If this field is NULL, then no data was captured for this record.

81 Present Time



The time the continuation record was created. This field is only populated for long duration calls. If this field contains a value of NULL, then no data was captured for this record.

95 Originating H323 Time Day



The time of day that the called number was dialed for the originating half of the call. This field is only populated for calls over an H.323 network.

104 Terminating H323 Time Day



The time of day that the called number was dialed for the terminating half of the call. This field is only populated for calls over an H.323 network.


Numeric 128 bit unsigned value in total. 64 bit seconds and 64 bit milliseconds in GMT epoch time format – the number of


The time the second database query response was received for


10

milli-seconds since Jan 01, 1970 0:00:00.000h if the value is NULL – the timestamp is to be ignored

this call.




The time the third database query response was received for this call.

132 Fax Indicator

Numeric VOICE-ONLY = 0

VOICE-AND-FAX = 1

Internally generated by call processing

This is an indication of whether or not the call involved any fax transmissions. This field will contain a zero when operating in an mgw to mgw controlled mode. When a fax is sent under mgw control, if an indication of the fax transmission is not sent to the call agent, this field is set to zero. . If this field contains a value of NULL, then no data was captured for this record.

135 Service Interrogation Time 1



Numeric 128 bit unsigned value in total. 64 bit seconds and 64 bit milliseconds in GMT epoch time format – the number of milli-seconds since Jan 01, 1970 0:00:00.000h if the


11

value is NULL – the timestamp is to be ignored



150 Video Codec

Numeric None = 0 (future)

H.261 = 1 (future)

H.263 = 2 (future)

H.264 = 3 (future)

n/a This is the codec that was use to transport the RTP traffic. The value in this field is pulled from the provisioning of the BTS – not from the actual SDP message. This field is always zero in this release.

164 Call Subtype

Numeric TEST-CALL subtypes:NONE = 0

NCT_LINE_TEST = 15

NCT_TRUNK_TEST = 16

NLB_LINE_TEST = 17

NLB_TRUNK_TEST = 18

TEST_ROUTE = 19

EMG subtypes:

AMBULANCE = 2

FIRE = 6

POLICE = 9

INFO subtypes:

AIRLINES = 1

ANALOG = 3

DIGITAL = 4

DYNAMIC = 5

Destination::

CallSubtype

This field further defines the call based on the Call-Type field. In this release, only CallType=TEST-CALL, EMG, or INFO causes this field to be populated. If this field contains a NULL, then it should be ignored.

NCT-LINE-TEST is a Network Continuity Test call on a subscriber line. The calling party number is in the format <test-prefix><DN>

NCT-TRUNK TEST is a Network Continuity Test call on a trunking endpoint. The


12

LB_TEST = 7

NLB_TEST = 8

RAILWAYS = 10

TIME = 11

TRAFFIC = 12

TW(Time&Weather) =13

WEATHER = 14

calling party number is in the format <test-prefix><TG><TM>. The number of digits in the trunk group number and trunk member number is determined based on TEST-TRUNK-GRP-DIGITS and TEST-TRUNK-MEMBER-DIGITS value set in the CA-CONFIG table.

NLB-LINE-TEST is a Network Loopback Test call using a network loop connection on the terminating endpoint. The calling party number is in the format <test-prefix><DN>.

NLB-TRUNK-TEST is a Network Loopback Test call on a trunking endpoint. The calling party number is in the format <test-prefix><TG><TM>. The number of digits in the trunk group number and trunk member number is determined based on TEST-TRUNK-GRP-DIGITS and TEST-


13

TRUNK-MEMBER-DIGITS value set in the CA-CONFIG table.

TEST-ROUTE routes the test call based on <DN>. The calling party number is in the format <test-prefix><TG><TM>. The number of digits in the trunk group number and trunk member number is determined based on TEST-TRUNK-GRP-DIGITS and TEST-TRUNK-MEMBER-DIGITS value set in the CA-CONFIG table.

171 Charging Information

Numeric Number of metered or pulsed charge units or Charge Band number. This is a dual purpose field.

ISUP ITX

messages

The number of metered or pulsed billing units recorded for this call. This is initially only used in conjunction with French ISUP. No value is recorded in this field for calls that are transiting the BTS. If this field is NULL, then no data was captured for this record.

The BTS acts as a CGP node based on the “AOC Enabled” property associated with the outgoing trunk groups. The property’s “enabled” or “disabled” status determines whether the received CRG


14

message in the backward direction should be validated or not.

172 Originating Line Infomation

Numeric 0-99 Subscriber-profile::

OLI SS7 IAM

message

The Originating Line Information value was received in the SS7 IAM. For subscriber originated call, the OLI specified in subscriber-profile record will be put into the billing record.

173 Centrex Group

String 16 Up to a 16 character group name

Subscriber::

CtxgId

Identity of the Centrex group that this call is associated with. If this field is NULL, then no data was captured for this record.

174 Country Code

String 3 Numeric Characters Intl_dial_plan::

Padded_cc

3 numeric characters Automatically generated by ems if not provisioned

If 1 digic cc, pad cc with 2 zeros (2 becomes 002)

If 2 digit cc, pad cc with 1 zero (44 becomes 044).

If 3 digit cc, no padding required, copy as is.

If cc > 3 digits, copy the 1st 3 digits here

175 Feature Data Two 1

String 130 See section 9 for specifics on feature data.

Internal FCP Message sent from the feature server to call processing

The second datum of feature specific data provided by the associated feature server for the Service Type 2 of a given call. If this field is NULL, then no data was captured for this record.




The second datum of feature specific data provided by the associated feature server for the Service Type 2


15

of a given call. If this field is NULL, then no data was captured for this record.




The second datum of feature specific data provided by the associated feature server for the Service Type 2 of a given call. If this field is NULL, then no data was captured for this record.

178 Feature Data Three 1



The third datum of feature specific data provided by the associated feature server for the Service Type 2 of a given call. If this field is NULL, then no data was captured for this record.










16

General field changes

The following are Quality of service parameters that were added and ameded as an overall feature for BTS 10200 release 5.0.

The BTS call detail records as of release 4.5 contain some of the Quality of Service data collected by the various endpoints, but the customers are looking for a more complete view of this data. The following fields are currently collected by the BTS:

OrigQualityOfServicePacketsSent (Remote metrics available) OrigQualityOfServicePacketsReceived OrigQualityOfServiceOctetsSent (Remote metrics available) OrigQualityOfServiceOctetsReceived OrigQualityOfServicePacktesLost (Remote metrics available) OrigQualityOfServiceJitter (Remote metrics available) OrigQualityOfServiceAverageLatency (Remote metrics available) TermQualityOfServicePacketsSent (Remote metrics available) TermQualityOfServicePacketsReceived TermQualityOfServiceOctetsSent (Remote metrics available) TermQualityOfServiceOctetsReceived TermQualityOfServicePacktesLost (Remote metrics available) TermQualityOfServiceJitter (Remote metrics available) TermQualityOfServiceAverageLatency (Remote metrics available)

The metrics are collected via best effort for MGCP/NCS and SIP based media gateways that support the metrics. The collection of metrics from SIP endpoints is a future effort due to the SIP stacks not fully supporting this yet. The collection mechanism occurs post call completion and waits for a pre-determined period of time for a response from both the originating and terminating endpoints where applicable. Currently the BTS does not collect QoS metrics from endpoints used in H323, SIP, SS7, ISDN, or CAS call legs.

The CLI commands that are used to display the contents of individual billing records could produce lengthy output streams if all or most fields are collected in a given call scenario. It is recommended that a paging capability be leveraged to make the output more manageable from a user’s perspective.

The requirement for release 5.0 is to collect both new metrics and additional views of the existing metrics. The set of metrics that the BTS must support the collection of are defined in the corporate baseline specification EDCS-425663. It is possible to indirectly collect metrics from endpoints that are not under direct control of the BTS creating the call detail record for a given call. In a scenario where the originating and terminating endpoints are both controlled via MGCP/NCS and one endpoint is associated with the BTS and another is in a different domain, the metrics for the “remote” endpoint can be transferred to the “local” endpoint via RTCP and collected via the normal mechanism. This capability gives the service provider a way to gather more quality of service


17

metrics then would normally not be possible. Not all metrics are transferred between the two endpoints via RTCP – those that are, the BTS will attempt to collect both the Local and Remote versions of the metrics. The following list describes the complete set of metrics to be collected with red italisized text used for existing metrics that are re-used:

1. QoSCodecType – use the existing CodecType field. This field contains the type of codec used in the associated call.

2. OrigQoSCodecFramesize – This is a new field containing the codec framesize used by the originating endpoint.

3. TermQoSCodecFramesize – This is a new field containing the codec framesize used by the terminating endpoint.

4. OrigQoSPacketSize – This is a new field containing the packet size used by the originating endpoint.

5. TermQoSPacketSize – This is a new field containing the packet size used by the terminating endpoint.

6. OrigQoSConcealmentMethod – This is a new field containing the concealment method used by the originating endpoint.

7. TermQoSConcealmentMethod – This is a new field containing the concealment method used by the terminating endpoint.

8. OrigQoSLocalEndSystemDelay – This is a new field containing the instantaneous end system delay reported by the originating endpoint.

9. OrigQoSRemoteEndSystemDelay – This is a new field containing the instantaneous end system deloay reported by the terminating endpoint via RTCP to the originating endpoint.

10.TermQoSLocalEndSystemDelay – This is a new field containing the instantaneous end system delay reported by the terminating endpoint.

11.TermQoSRemoteEndSystemDelay – This is a new field containing the instantaneous end system deloay reported by the originating endpoint via RTCP to the terminating endpoint.

12.OrigQoSLocalNetworkPacketRoundTripDelay – use the existing field OrigQualityOfServiceAverageLatency. This field contains the instantaneous network packet round trip time reported by the originating endpoint.

13.OrigQoSRemoteNetworkPacketRoundTripDelay – This is a new field containing the instantaneous network packet round trip time reported by the terminating endpoint via RTCP to the originating endpoint.

14.TermQoSLocalNetworkPacketRoundTripDelay – use the existing field TermQualityOfServiceAverageLatency. This field contains the instantaneous network packet round trip time reported by the terminating endpoint.

15.TermQoSRemoteNetworkPacketRoundTripDelay – This is a new field containing the instantaneous network packet round trip time reported by the originating endpoint via RTCP to the terminating endpoint.

16.OrigQoSDeadConnectDetect – This is a new field containing a boolean value specifying if possible dead connection detection in enabled or not on the originating endpoint.

17.TermQoSDeadConnectDetect – This is a new field containing a boolean value specifying if possible dead connection detection in enabled or not on the terminating endpoint.


18

18.OrigQoSLocalPacketsSent – use the existing OrigQualityOfServicePacketsSent field. This field contains the number of packets sent by the originating endpoint.

19.OrigQoSRemotePacketsSent – This is a new field containing the number of packets sent by the terminating endpoint as reported by the terminating endpoint via RTCP to the originating endpoint.

20.TermQoSLocalPacketsSent – use the existing TermQualityOfServicePacketsSent field. This field contains the number of packets sent by the terminating endpoint.

21.TermQoSRemotePacketsSent – This is a new field containing the number of packets sent by the originating endpoint as reported by the originating endpoint via RTCP to the terminating endpoint.

22.OrigQoSLocalPacketsReceived – use the existing OrigQualityOfServicePacketsReceived field. This field contains the number of packets received by the originating endpoint.

23.TermQoSLocalPacketsReceived – use the existing TermQualityOfServicePacketsReceived field. This field contains the number of packets received by the terminating endpoint.

24.OrigQoSLocalOctetsSent – use the existing OrigQualityOfServiceOctetsSent field. This field contains the number of octets sent by the originating endpoint.

25.OrigQoSRemoteOctetsSent – This is a new field containing the number of octets sent by the terminating endpoint as reported by the terminating endpoint via RTCP to the originating endpoint.

26.TermQoSLocalOctetsSent – use the existing TermQualityOfServiceOctetsSent field. This field contains the number of octets sent by the terminating endpoint.

27.TermQoSRemoteOctetsSent – This is a new field containing the number of octets sent by the originating endpoint as reported by the originating endpoint via RTCP to the terminating endpoint.

28.OrigQoSLocalOctetsReceived – use the existing OrigQualityOfServiceOctetsReceived field. This field contains the number of octets received by the originating endpoint.

29.TermQoSLocalOctetsReceived – use the existing TermQualityOfServiceOctetsReceived field. This field contains the number of octets received by the terminating endpoint.

30.OrigQoSLocalPacketLossRate – This is a new field containing the packet loss ratio reported by the originating endpoint.

31.OrigQoSRemotePacketLossRate – This is a new field containing the packet loss ratio experienced by the terminating endpoint as reported by the terminating endpoint via RTCP to the originating endpoint.

32.TermQoSLocalPacketLossRate – This is a new field containing the packet loss ratio reported by the terminating endpoint.

33.TermQoSRemotePacketLossRate – This is a new field containing the packet loss ratio experienced by the originating endpoint as reported by the originating endpoint via RTCP to the terminating endpoint.

34.OrigQoSLocalPacketsLostCount – use the existing OrigQualityOfServicePacketsLost field. This field contains the number of packets lost by the originating endpoint.


19

35.OrigQoSRemotePacketsLostCount – This is a new field containing the number of packets lost by the terminating endpoint as reported by the terminating endpoint via RTCP to the originating endpoint.

36.TermQoSLocalPacketsLostCount – use the existing TermQualityOfServicePacketsLost field. This field contains the number of packets lost by the terminating endpoint.

37.TermQoSRemotePacketsLostCount – This is a new field containing the number of packets lost by the originating endpoint as reported by the originating endpoint via RTCP to the terminating endpoint.

38.OrigQoSLocalTotalPacketDiscardRatio – This is a new field containing the cumulative packet discard ratio reported by the originating endpoint.

39.OrigQoSRemoteTotalPacketDiscardRatio – This is a new field containing the cumulative packet discard ratio reported by the terminating endpoint via RTCP to the originating endpoint.

40.TermQoSLocalTotalPacketDiscardRatio – This is a new field containing the cumulative packet discard ratio reported by the terminating endpoint.

41.TermQoSRemoteTotalPacketDiscardRatio – This is a new field containing the cumulative packet discard ratio reported by the originating endpoint via RTCP to the terminating endpoint.

42.OrigQoSLocalTotalPacketDiscardCount – This is a new field containing the cumulative packet discard count reported by the originating endpoint.

43.OrigQoSRemoteTotalPacketDiscardCount – This is a new field containing the cumulative packet discard count reported by the terminating endpoint via RTCP to the originating endpoint.

44.TermQoSLocalTotalPacketDiscardCount – This is a new field containing the cumulative packet discard count reported by the terminating endpoint.

45.TermQoSRemoteTotalPacketDiscardCount – This is a new field containing the cumulative packet discard count reported by the originating endpoint via RTCP to the terminating endpoint.

46.OrigQoSConcealedSeconds – This is a new field containing the concealed seconds value reported by the originating endpoint.

47.TermQoSConcealedSeconds – This is a new field containing the concealed seconds value reported by the terminating endpoint.

48.OrigQoSSevConcealedSeconds – This is a new field containing the severely concealed seconds value reported by the originating endpoint.

49.TermQoSSevConcealedSeconds – This is a new field containing the severely concealed seconds value reported by the terminating endpoint.

50.OrigQoSRtcpXrBurstDensity – This is a new field containing the RTPC XR Burst Density reported by the originating endpoint.

51.TermQoSRtcpXrBurstDensity – This is a new field containing the RTPC XR Burst Density reported by the terminating endpoint.

52.OrigQoSRtcpXrGapDensity – This is a new field containing the RTPC XR Gap Density reported by the originating endpoint.

53.TermQoSRtcpXrGapDensity – This is a new field containing the RTPC XR Gap Density reported by the terminating endpoint.

54.OrigQoSRtcpXrBurstDuration – This is a new field containing the RTPC XR Burst Duration reported by the originating endpoint.

55.TermQoSRtcpXrBurstDuration – This is a new field containing the RTPC XR Burst Duration reported by the terminating endpoint.


20

56.OrigQoSRtcpXrGapDuration – This is a new field containing the RTPC XR Gap Duration reported by the originating endpoint.

57.TermQoSRtcpXrGapDuration – This is a new field containing the RTPC XR Gap Duration reported by the terminating endpoint.

58.OrigQoSLocalInterArrivalJitter – use the existing OrigQualityOfServiceJitter field. This field contains the instantaneous inter-arrival jitter reported by the originating endpoint.

59.OrigQoSRemoteInterArrivalJitter – This is a new field containing the instantaneous inter-arrival jitter experienced by the terminating endpoint as reported by the terminating endpoint via RTCP to the originating endpoint.

60.TermQoSLocalInterArrivalJitter – use the existing TermQualityOfServiceJitter field. This field contains the instantaneous inter-arrival jitter reported by the terminating endpoint.

61.TermQoSRemoteInterArrivalJitter – This is a new field containing the instantaneous inter-arrival jitter experienced by the originating endpoint as reported by the originating endpoint via RTCP to the terminating endpoint.

62.OrigQoSLocalMosR – This is a new field containing the MOS R-factor value reported by the originating endpoint.

63.OrigQoSRemoteMosR – This is a new field containing the MOS R-factor value reported by the terminating endpoint via RTCP to the originating endpoint.

64.TermQoSLocalMosR – This is a new field containing the MOS R-factor value reported by the terminating endpoint.

65.TermQoSRemoteMosR – This is a new field containing the MOS R-factor value reported by the originating endpoint via RTCP to the terminating endpoint.

66.OrigQoSLocalMosLqr – This is a new field containing the MOS LQR value reported by the originating endpoint.

67.OrigQoSRemoteMosLqr – This is a new field containing the MOS LQR value reported by the terminating endpoint via RTCP to the originating endpoint.

68.TermQoSLocalMosLqr – This is a new field containing the MOS LQR value reported by the terminating endpoint.

69.TermQoSRemoteMosLqr – This is a new field containing the MOS LQR value reported by the originating endpoint via RTCP to the terminating endpoint.

70.OrigQoSLocalMosCqr – This is a new field containing the MOS CQR value reported by the originating endpoint.

71.OrigQoSRemoteMosCqr – This is a new field containing the MOS CQR value reported by the terminating endpoint via RTCP to the originating endpoint.

72.TermQoSLocalMosCqr – This is a new field containing the MOS CQR value reported by the terminating endpoint.

73.TermQoSRemoteMosCqr – This is a new field containing the MOS CQR value reported by the originating endpoint via RTCP to the terminating endpoint.

74.OrigQoSLocalMosLqk – This is a new field containing the MOS LQK K-factor value reported by the originating endpoint.


21

75.OrigQoSRemoteMosLqk – This is a new field containing the MOS LQK K-factor value reported by the terminating endpoint via RTCP to the originating endpoint.

76.TermQoSLocalMosLqk – This is a new field containing the MOS LQK K-factor value reported by the terminating endpoint.

77.TermQoSRemoteMosLqk – This is a new field containing the MOS LQK K-factor value reported by the originating endpoint via RTCP to the terminating endpoint.

78.OrigQoSLocalMosLqkAvg – This is a new field containing the average MOS LQK K-factor value reported by the originating endpoint.

79.OrigQoSRemoteMosLqkAvg – This is a new field containing the average MOS LQK K-factor value reported by the terminating endpoint via RTCP to the originating endpoint.

80.TermQoSLocalMosLqkAvg – This is a new field containing the average MOS LQK K-factor value reported by the terminating endpoint.

81.TermQoSRemoteMosLqkAvg – This is a new field containing the average MOS LQK K-factor value reported by the originating endpoint via RTCP to the terminating endpoint.

82.OrigQoSLocalRcvInstSpeechLevel – This is a new field containing the received instantaneous speech level reported by the originating endpoint.

83.OrigQoSRemoteRcvInstSpeechLevel – This is a new field containing the received instantaneous speech level reported by the terminating endpoint via RTCP to the originating endpoint.

84.TermQoSLocalRcvInstSpeechLevel – This is a new field containing the received instantaneous speech level reported by the terminating endpoint.

85.TermQoSRemoteRcvInstSpeechLevel – This is a new field containing the received instantaneous speech level reported by the originating endpoint via RTCP to the terminating endpoint.

86.OrigQoSTransmitInstSpeechLevel – This is a new field containing the transmitted instantaneous speech level reported by the originating endpoint.

87.TermQoSTransmitInstSpeechLevel – This is a new field containing the transmitted instantaneous speech level reported by the terminating endpoint.

88.OrigQoSLocalRcvInstSilenceLevel – This is a new field containing the received instantaneous silence level reported by the originating endpoint.

89.OrigQoSRemoteRcvInstSilenceLevel – This is a new field containing the received instantaneous silence level reported by the terminating endpoint via RTCP to the originating endpoint.

90.TermQoSLocalRcvInstSilenceLevel – This is a new field containing the received instantaneous silence level reported by the terminating endpoint.

91.TermQoSRemoteRcvInstSilenceLevel – This is a new field containing the received instantaneous silence level reported by the originating endpoint via RTCP to the terminating endpoint.

92.OrigQoSTransmitInstSilenceLevel – This is a new field containing the transmitted instantaneous silence level reported by the originating endpoint.

93.TermQoSTransmitInstSilenceLevel – This is a new field containing the transmitted instantaneous silence level reported by the terminating endpoint.


22

94.OrigQoSLocalJitterBufferDelayNom – This is a new field containing the nominal jitter buffer delay reported by the originating endpoint.

95.OrigQoSRemoteJitterBufferDelayNom – This is a new field containing the nominal jitter buffer delay reported by the terminating endpoint via RTCP to the originating endpoint.

96.TermQoSLocalJitterBufferDelayNom – This is a new field containing the nominal jitter buffer delay reported by the terminating endpoint.

97.TermQoSRemoteJitterBufferDelayNom – This is a new field containing the nominal jitter buffer delay reported by the originating endpoint via RTCP to the terminating endpoint.

98.OrigQoSLocalJitterBufferDelayAbs – This is a new field containing the absolute jitter buffer delay reported by the originating endpoint.

99.OrigQoSRemoteJitterBufferDelayAbs – This is a new field containing the absolute jitter buffer delay reported by the terminating endpoint via RTCP to the originating endpoint.

100. TermQoSLocalJitterBufferDelayAbs – This is a new field containing the absolute jitter buffer delay reported by the terminating endpoint.

101. TermQoSRemoteJitterBufferDelayAbs – This is a new field containing the absolute jitter buffer delay reported by the originating endpoint via RTCP to the terminating endpoint.

102. OrigQoSLocalJitterBufferDelayMaxAdp – This is a new field containing the maximum adaptive jitter buffer delay reported by the originating endpoint.

103. OrigQoSRemoteJitterBufferDelayMaxAdp – This is a new field containing the maximum adaptive jitter buffer delay reported by the terminating endpoint via RTCP to the originating endpoint.

104. TermQoSLocalJitterBufferDelayMaxAdp – This is a new field containing the maximum adaptive jitter buffer delay reported by the terminating endpoint.

105. TermQoSRemoteJitterBufferDelayMaxAdp – This is a new field containing the maximum adaptive jitter buffer delay reported by the originating endpoint via RTCP to the terminating endpoint.

106. OrigQoSLocalJitterBufferDelayMin – This is a new field containing the minimum jitter buffer delay reported by the originating endpoint.

107. OrigQoSRemoteJitterBufferDelayMin – This is a new field containing the minimum jitter buffer delay reported by the terminating endpoint via RTCP to the originating endpoint.

108. TermQoSLocalJitterBufferDelayMin – This is a new field containing the minimum jitter buffer delay reported by the terminating endpoint.

109. TermQoSRemoteJitterBufferDelayMin – This is a new field containing the minimum jitter buffer delay reported by the originating endpoint via RTCP to the terminating endpoint.

110. OrigQoSLocalJitterBufferDelayAvg – This is a new field containing the average jitter buffer delay reported by the originating endpoint.

111. OrigQoSRemoteJitterBufferDelayAvg – This is a new field containing the average jitter buffer delay reported by the terminating endpoint via RTCP to the originating endpoint.

112. TermQoSLocalJitterBufferDelayAvg – This is a new field containing the average jitter buffer delay reported by the terminating endpoint.


23

113. TermQoSRemoteJitterBufferDelayAvg – This is a new field containing the average jitter buffer delay reported by the originating endpoint via RTCP to the terminating endpoint.

114. OrigQoSLocalJitterBufferDelayMax – This is a new field containing the maximum jitter buffer delay reported by the originating endpoint.

115. OrigQoSRemoteJitterBufferDelayMax – This is a new field containing the maximum jitter buffer delay reported by the terminating endpoint via RTCP to the originating endpoint.

116. TermQoSLocalJitterBufferDelayMax – This is a new field containing the maximum jitter buffer delay reported by the terminating endpoint.

117. TermQoSRemoteJitterBufferDelayMax – This is a new field containing the maximum jitter buffer delay reported by the originating endpoint via RTCP to the terminating endpoint.

118. OrigQoSEchoReturnLoss – This is a new field containing the echo return loss reported by the originating endpoint.

119. TermQoSEchoReturnLoss – This is a new field containing the echo return loss reported by the terminating endpoint.

120. OrigQoSLocalEchoReturnLossEnh – This is a new field containing the enhanced echo return loss reported by the originating endpoint.

121. OrigQoSReturnEchoReturnLossEnh – This is a new field containing the enhanced echo return loss reported by the terminating endpoint via RTCP to the originating endpoint.

122. TermQoSLocalEchoReturnLossEnh – This is a new field containing the enhanced echo return loss reported by the terminating endpoint.

123. TermQoSReturnEchoReturnLossEnh – This is a new field containing the enhanced echo return loss reported by the originating endpoint via RTCP to the terminating endpoint.

124. OrigQoSLocalResEchoReturnLossEnh – This is a new field containing the residual enhanced echo return loss reported by the originating endpoint.

125. OrigQoSReturnResEchoReturnLossEnh – This is a new field containing the residual enhanced echo return loss reported by the terminating endpoint via RTCP to the originating endpoint.

126. TermQoSLocalResEchoReturnLossEnh – This is a new field containing the residual enhanced echo return loss reported by the terminating endpoint.

127. TermQoSReturnResEchoReturnLossEnh – This is a new field containing the residual enhanced echo return loss reported by the originating endpoint via RTCP to the terminating endpoint.

128. OrigQoSNlpSigStrengthReduction – This is a new field containing the non-linear processor signal strength reduction reported by the originating endpoint.

129. TermQoSNlpSigStrengthReduction – This is a new field containing the non-linear processor signal strength reduction reported by the terminating endpoint.

130. OrigQoSRcvSnrShort – This is a new field containing the short term received signal to noise ratio reported by the originating endpoint.

131. TermQoSRcvSnrShort – This is a new field containing the short term received signal to noise ratio reported by the terminating endpoint.


24

132. OrigQoSTransmitSnrShort – This is a new field containing the short term transmitted signal to noise ratio reported by the originating endpoint.

133. TermQoSTransmitSnrShort – This is a new field containing the short term transmitted signal to noise ratio reported by the terminating endpoint.

134. OrigQoSRcvSnrLong – This is a new field containing the long term received signal to noise ratio reported by the originating endpoint.

135. TermQoSRcvSnrLong – This is a new field containing the long term received signal to noise ratio reported by the terminating endpoint.

136. OrigQoSTransmitSnrLong – This is a new field containing the long term transmitted signal to noise ratio reported by the originating endpoint.

137. TermQoSTransmitSnrLong – This is a new field containing the long term transmitted signal to noise ratio reported by the terminating endpoint.

Whenever a specific metric is not or cannot be collected for a given call, a value of NULL must be placed in the corresponding QoS metric field(s) in the call detail record. This ensure that a real value of zero is not mistaken for an indication that the metric was not collected.

Typically the only metrics that are exchanged over RTCP between peer endpoints are ones that are not negotiated at call setup.

There were several metrics taken out of the list in the PRD for this requirement tag due to the fact that Cisco corporate baselines are not going to support them, and some of those aren’t even defined with Cisco’s endpoints. We are also avoiding carrying any information in the CDRs that is derivable post call by the customer’s back office infrastructure. The actual mapping of these QoS metrics fields within the CDRs to their respective fields in the NCS/MGCP messages is identified in the BTS Billing Specification.


25

Corporate HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USAwww.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 526-4100

European HeadquartersCisco Systems Europe11 Rue Camille Desmoulins92782 Issy-Les-Moulineaux Cedex 9Francewww-europe.cisco.comTel: 33 1 58 04 60 00Fax: 33 1 58 04 61 00

Americas HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USAwww.cisco.comTel: 408 526-7660Fax: 408 527-0883

Asia Pacific HeadquartersCisco Systems Australia, Pty., LtdLevel 9, 80 Pacific HighwayP.O. Box 469North Sydney NSW 2060 Australiawww.cisco.comTel: +61 2 8448 7100Fax: +61 2 9957 4350

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the

Cisco Web site at www.cisco.com/go/offices.

Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China • Colombia • Costa Rica • Croatia • Czech Republic Denmark • Dubai, UAE Finland • France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland • Israel • Italy • Japan • Korea • Luxembourg • Malaysia • MexicoThe Netherlands • New Zealand • Norway • Peru • Philippines • Poland • Portugal • Puerto Rico • Romania • Russia • Saudi Arabia • Singapore • Slovakia • Slovenia South Africa • Spain • Sweden • Switzerland • Taiwan • Thailand • Turkey • Ukraine • United Kingdom • United States • Venezuela • Vietnam • Zimbabwe


http://www.cisco.com/go/offices

delta document for billing changes€¦ · web viewany of these alterations could impact revenue...

Documents