Data Inter-Exchange Carrier
| Data Inter-Exchange Carrier (DIXC) |
| Establishing DIXC Reciprocal Data Interexchange |
| Maintenance Of DIXC Reciprocal Data Exchange |
| Timely Receipt of Traffic Data |
| Layout Of DIXC Records |
Data Inter-Exchange Carrier (DIXC)
Data Inter-Exchange Carrier (DIXC) is a process designed to facilitate the reciprocal exchange of voice traffic load data between SWBT and CLECs interconnecting with its network. This reciprocal exchange of data enables SWBT and each CLEC to have a complete view of traffic loads on both ends of two-way trunk groups. The knowledge of call attempt and overflow data counts on both ends of a two-way trunk group enables each company to more accurately estimate the offered load, and thereby better estimate the required quantities of trunks.
When mutually agreeable, SWBT and the CLECs may also elect to exchange traffic data on one-way groups.
Establishing DIXC Reciprocal Data Interexchange
CLECs desiring to establish the DIXC process of reciprocal data exchange with SWBT must make this request through their Account Managers. The Account Managers facilitate coordination between the Trunk Planning And Engineering and the Information Services organizations at SWBT, and their respective counterparts in the CLEC’s organization.
The voice traffic data measurements to be exchanged are:
-
Usage (USG): Total usage, measured in centum call seconds (CCS).
-
Peg Count (PC): Peg count of originating call attempts, including overflow.
-
Overflow (OVF): Peg count of originating call attempts failing to find an idle trunk.
-
Either of the following measurements:
-
Maintenance Usage (MTU): Total maintenance usage, measured in CCS.
-
Maintenance Busy Counts (MBC): Total count of trunks made Maintenance Busy.
-
The frequency of data collection, except when modified by mutual consent of the CLEC and SWBT, is:
- Hourly, on the clock hour.
- 24 hours per day, 0000-2400 recommended; 0800-2400 minimum requirement.
- 7 days per week, including holidays.
- 52 weeks per year.
The following file transfer mechanisms are supported:
- Network Data Mover (NDM).
- File Transfer Protocol (FTP).
Maintenance Of DIXC Reciprocal Data Exchange
When a DIXC reciprocal data exchange process problem arises, CLECs must contact their Account Managers, who facilitate coordination with the responsible internal SWBT organizations.
Timely Receipt of Traffic Data
Timely receipt of traffic data is critical to facilitate the merging of traffic data from the distant end into data processing routines. Receipt of file transfers at the designated SWBT data center by 9:00 A.M. PST each Thursday for the preceding week’s data collection is required.
The CLEC may choose from two different layouts of how DIXC records will look when they arrive at the CLEC’s computer systems. The differences between the two layouts are:
- the header and body records of the file have dates with 2 digit years in layout #1 but have dates with 4 digit years in layout #2
- the TSS-HDR-LOWVAL field in layout #1 was changed to TSS-HDR-ZEROS in layout #2
- the TSS-NBR-COMP, TSS-DATA VALUE and TSS-TRLR-RECORD-COUNT fields are packed decimal in layout #1 and are numeric in layout #2
- the TSS-DATA-COUNT field is binary in layout #1 and is numeric in layout #2
- the TSS-TRLR-ALL-NINES field is 42 bytes in layout #1 and is 47 bytes in layout #2
- the TSS-TRLR-BIN-ONE field and TSS-TRLR-THREE-NINES fields have been deleted
When data is sent to a CLEC’s computer that runs with an EBCDIC character set, the data can be formatted in either layout #1 or layout #2. If, however, the data is sent to a CLEC and their computer uses the ASCII character set, the data can be formatted as described in layout #2 only.
DATA INTEREXCHANGE CARRIER - DIXC
RECORD FIELD DEFINITIONS
| FIELD IDENTIFIERS | FIELD DEFINITION |
|
TSS-HDR-LOWVAL |
A two byte field containing low values (X’0000). |
|
TSS-HDR-CREATE-DATE |
The create date of this file in Gregorian format (MM/DD/YY). |
|
TSS-HDR-CREATE-TIME |
The create time of this file in the format HHMMSS on a 24 hour clock. |
|
TSS-HDR-SYSTEM-ID |
The value ‘ZNT’. |
|
TSS-TRUNK-GRP-ID |
An eight character unique identifier (2 alpha + 6 numeric) for the trunk group. Sometimes called the Trunk Group Serial Number (TGSN) or 2-6 code. The sending company must obtain this identifier from the receiving company so that the receiving company may associate the data with the appropriate trunk group in it’s data base. The first character must be less than 'S' AT&T uses ‘AM’ as the first two characters. |
|
TSS-JUL-SUN-DATE |
The Sunday date of the week during which the data is collected expressed in Julian format. |
|
TSS-CLLI-TU-LOC |
The identifier of the switch terminating the trunk group from which data has been collected expressed in BELLCORE Common Language Location Identifier (CLLI) format. 4 character city code + 2 character state code + 2 character building code + 3 character traffic unit (switch) code. Refer to BELLCORE CLLI Code Assignment Guide Job Aid JA-STS-000018. This document may be obtained direct from BELLCORE by calling 1-800-521-2673. |
|
TSS-CLLI-DCU-DCU |
A three character code identifying the unit collecting the data by type of unit, the number of the unit within the building and an indicator of the type of data collection schedule used for trunking data. The following are examples of standard code conventions for the following switch types: 5ESS 50C 1AESS 10C DMS100 J0C DMS200 K0C DMS100/200 K0C ERICSON X0C 4ESS 405 The following general codes may be used in lieu of the above: A(n)(n) - Accumulated data at Central Off. S(n)(n) - Accumulated at data coll. Machine where (n) is any number 0 - 9 |
|
TSS-HIGHEST-DCD-NBR |
A four numeric indicator of the Data Collection Device (DCD, also referred as to a register) from 0000 - 9999 |
|
TSS-MEASUREMENT-TYPE |
A single numeric value designating the type of measurement. 1 PEG COUNT (PC) (INCLUDES OVF) 2 OVERFLOW (OVF) 3 USAGE (USG) (in 100 Call Seconds) 8 MAINTENANCE USAGE (MTU) (measured in 100 Call Seconds)) 9 MAINTENANCE BUSY COUNTS (MBC) (measured as the number of trunks made busy) |
|
TSS-RECORD-TYPE |
A single numeric value designating the type of data record. 1 HOURLY MEASUREMENTS 2 DETECTOR TEST 3 TOTAL DAY 4 TOTAL WEEK 5 OTHER 6 FALSE BUSY TEST |
|
TSS-TMR-REQ-NBR |
A single number value designating the Traffic Measurement Request (TMR) number - always equal to '1' |
|
TSS-NBR-COMP |
The number of trunks in service for this group. |
|
TSS-CG-AZ-END |
A single alpha character designator as to which end of the circuit the data is collected from. This refers to the position of the office CLLI in the Common Language Circuit Identification (CLCI) code for this trunk group. The 'A' location is the first office identified, the ‘Z' location is the second office identified separated from the first by the pulsing code. |
|
TSS-USER-CD |
A three alpha/numeric character code identifying the company to which the data is being sent (2 numeric) plus a third optional character used by that company for internal sorting purposes. For AT&T use '33A' |
|
TSS-TIME-ZONE |
A CDT OR EST B MDT OR CST C PDT OR MST D YUKON DT OR PST E HAWAIIIAN DT, ALASKAN DT, YUKON F Bering DT HST OR AST G Bering ST I OTHER { NDT OR EDT NST |
|
TSS-DATA-COUNT |
Number of times the next three fields are repeated. This field can be a value from 1 to 168 (7 x 24). |
|
TSS-START-DAY-CODE |
A single numeric code representing the start day of data collection: 1 = Sunday 2 = Monday 3 = Tuesday 4 = Wednesday 5 = Thursday 6 = Friday 7 = Saturday |
|
TSS-START-TIME-CODE |
A two digit numeric code (01 - 96) designating the start time of data collection for this period in quarter hours, i.e. hour 0000 = 01, hour 0100 = 05 |
|
TSS-DATA-VALUE |
A compacted 7 numeric field containing the traffic data value. The following field values provided by some data collection devices are assigned special meaning in the P*B data processing system: 9999990 - PC Out of Range 9999991 - Scan Count out of Range 9999992 - Limited Scan Out of Range 9999993 - Process Interval Not Found 9999994 - Register Grouping Out of Range |
|
TSS-TRLR-ALL-NINES |
A forty two byte character field containing all ‘9’. |
|
TSS-TRLR-BIN-ONE |
A two byte field containing a binary one (X’0001). |
|
TSS-TRLR-THREE-NINES |
A three byte character field containing all ‘9’. |
|
TSS-TRLR-RECORD-COUNT |
A signed numeric field containing the number of records in this file including the header and trailer. |
Pacific will send the Data in one of the two layouts described above. Depending on its computer systems, a CLEC has the flexibility to format the data in many different ways. It is the CLEC’s responsibility to design how the data will be formatted by its systems.
