MDS ARM RuleSet Specification of BOD to Kenan Arbor for IBM Version 2.0 Draft 0.1

MDS/ARM Rule Set of BOD to Arbor for IBM DOCUMENT VERSION 2.0 DRAFT 0.1

Release 2.0 Rule Set Specification

C o m p t e l C o r p o r a t i o n • w w w . c o m p t e l . c o m • A u s t r a l i a • B r a z i l • C h i n a • F i n l a n d • F r a n c e • G e r m a n y • H o n g K o n g • I n d i a • M a l a y s i a • S p a i n • T a i w a n • U A E • U S A

Abstract The MDS/ARM Rule Set of BOD to Arbor for IBM Release 2.0 Rule Set Specification (Document Version 2.0 Draft 0.1) provides information about MDS/ARM Rule Set Specification functionality for BOD Contact Information If the information you need is not in this document, you can contact our Customer Support Services: Phone: +358 9 694 3256 Fax: +358 9 700 11 206 Email: [email protected] This service is available only to customers who have made a maintenance agreement with Comptel Corporation. Trademarks Comptel, Comptel logo, Comptel EventLink, Comptel InstantLink, Comptel OnlineLink, Comptel PacketLink, Comptel SMSLink and Comptel ServiceLink, Comptel MDS, Comptel MDS/AMD, Comptel MDS/SAS, MDS/SAS Business Service Tool, InstantLink Business Service Tool, MDS/SAS Provisioning Client, InstantLink Provisioning Client, MDS/SAS Developer's License, InstantLink Developer's License, MDS/AMD-DB, EventLink Reporter, MDS/ARC, MDS/ARM, MDS/ARP, MDS/FTM, MDS Browser, EventLink Browser, MDS Correlator, EventLink Correlator, MDS GTP Collector, Comptel GTP Collector, MDS Remote File Agent, EventLink Remote File Agent, EventLink Business Logic Tool, EventLink User Interface, EventLink FTP Distributor, EventLink FTP Collector, EventLink Encapsulated ARM-FR, EventLink Multi-format Encoder, EventLink UDP Distributor, EventLink UDP Collector, MDS/AMD Developer's License, EventLink Developer's License, MDS Alarm Dispatcher, Comptel Alarm Dispatcher, MDS Lookup Server, Comptel Lookup Server, Comptel Rater, MDS Credit Guard, Comptel Partner Account and Comptel Balance Management are trademarks or registered trademarks of Comptel Corporation. All other trademarks and registered trademarks are the property of their respective holders. Copyright © 2005 Comptel Corporation, Lapinrinne 3, FIN-00100 Helsinki, Finland No part of this document may be reproduced, translated, or transmitted in any form or by any means, electronic or mechanical, for any purpose without the express written permission of Comptel Corporation, and then only on the condition that this notice is included in any such reproduction. No information as to the contents of this document may be communicated to any third party without the prior written consent of Comptel Corporation. Information in this document is subject to change without notice and does not represent a commitment on the part of Comptel Corporation. Comptel Corporation is not liable for errors contained in this document or for incidental or consequential damages in connection with furnishing or use of this material. Comptel’s software is protected by copyright laws. Comptel has also sought patent protection for its solutions. Comptel is continuously keeping up with the patenting activities within its field of business. Comptel respects the intellectual property rights of third parties and never wilfully infringes patents owned by third parties. Reader's Comments A reader comment form is provided at the end of this document. Please take a moment and give us feedback on our documentation.

MDS/ARM Rule Set of BOD to Arbor for IBM Release 2.0 Rule Set Specification

iii

Confidential Contents

1 About This Document 6

1.1 Purpose of document 6

1.2 Related documentation 6

1.3 Audience 6

1.4 Typographic conventions 6

1.5 Terms, concepts and abbreviations 7

1.5.1 Abbreviations 7

1.5.2 Terminology 7

2 Overview of MDS/ARM 9

2.1 Environment 9

2.2 Overview of MDS/ARM functionality 10

2.3 File Reader 10

2.4 Logfile Reader 10

2.5 XML Reader 11

2.6 Conversion and Validation 11

2.7 Event Aggregation 11

2.8 File Writer 11

2.9 XML Writer 11

3 ARM Processing Flow 12

4 Input File Naming Convention 13

5 Input Description 14

5.1 File structure 14

5.2 ER layout 14

5.2.1 BOD Record 14

5.3 Supported ERs 16

6 Filtering Rules 17

7 Validation Rules 18

7.1 ER validation rules 18

Document Version 2.0 Draft 0.1


iv

Confidential Contents 8 Output File Naming Convention 20

9 Output Description and Conversion 21

9.1 File structure 21

9.2 Header record layout 21

9.3 Converted ER layout 22

9.4 Trailer record layout 23

9.5 Sample of Output Record 24

10 Duplicate Checker 25

11 Event Aggregation 26

12 Lookup Tables 27

12.1 Lookup Server tables used 27

12.1.1 BODUSAGE table 28

12.1.2 BODFREQUENCY table 28

13 Customer Specific Parameters and Variables 30

13.1 GRC file parameters and entries 30

14 Customer Specific Files and Modules 31

14.1 Summary log file 31

14.2 DSL modules 32

Document Index 33

Reader’s Comments 34



5

Confidential About This Document Document Version History

Version Changed by Date Description Accepted by

1.0 draft 0.1 Tashi Bodh 10.10.2005 Specification document 1.0 draft 0.2 Manish Minocha 16.01.2006 Reviewed and Updated 2.0 draft 0.1 Manish Minocha 23.02.2007 Updated as per the upgrade Migration



6

Confidential About This Document 1 About This Document

This chapter presents the purpose of the document and lists any related documentation.

1.1 Purpose of document

The purpose of this document is to describe the functionality of the conversion and validation rules of MDS/ARM™ Ruleset for BOD (Bandwidth On Demand) to Kenan Arbor format.

This document describes the IBM/Bharti-specific configuration of the general MDS/ARM product and is not to be seen as a global overview of the MDS/ARM product. The functionality of the general MDS/ARM product is described in MDS/ARM Functional Description.

1.2 Related documentation

# Document Owner Description 1. MDS/ARM Functional Description Comptel Functional description of the

MDS/ARM core module. 2. MDS/ARM Operation and

Maintenance Guide Comptel Describes the operation and

maintenance procedures of MDS/ARM.

3. MDS/ARM Extensions Functional Description

Comptel Functional description of the MDS/ARM Extensions core module.

4. MDS/ARM Extensions Operation and Maintenance Guide

Comptel Describes the operation and maintenance procedures of MDS/ARM Extensions.

5. MDS Lookup Server Functional Description

Comptel Functional description of the MDS Lookup Server core module.

6. MDS Lookup Server Operation and Maintenance Guide

Comptel Describes the operation and maintenance procedures of MDS Lookup Server.

7. Design_Document_Kenan_MPLS_BOD_Version_1.2

TCS Functional Specifications provided by TCS.

1.3 Audience

This document is meant for the technical staff and testers at IBM Global Services India Pvt Ltd and at Comptel participating in the Mediation project and later on for those who are responsible for operating and maintaining the Mediation application. Because the descriptions of the conversions are low level, it is recommended that the reader is familiar with the Mediation concept and MDS/ARM module.

1.4 Typographic conventions

The following text styles identify special information used in the document:



7

Confidential About This Document

Italics Italicised text is used to call attention to cross-references.

Bold

Bold text is used for presenting:

• field names • menu item names • page names

Note Notes are written between two lines to call attention

to important issues.

Courier Courier font is used for presenting:

• user input in, for example, commands, parameters and field values

• messages shown to the user

1.5 Terms, concepts and abbreviations

The following abbreviations, terms and concepts are used in the document:

1.5.1 Abbreviations OSS/BSS Operations and Business Support System ER Event Record EA Event Aggregator

1.5.2 Terminology Term Meaning

Comptel EventLink™ Event mediation software product developed by Comptel. Consists of MDS EventLink and MDS/AMD.

Event Aggregator (EA) A component that combines the ERs belonging to a single event.

Event Record (ER) A detailed record produced from a service usage event. GRC file A file that includes the configuration information for the

ARM. Input file Accounting data file before any processing has been done on

it. It is usually in the vendor specific format. Invalid file The ERs in the msg api format that do not pass the validation

rules and because of that are not written to the output file. MDS/ARM Accounting Record Modification application, which takes

care of converting the BOD ERs to the Kenan format and validating them. It is also capable of combining long calls.

Msg api format The internal format of the ARM. The ERs are in this format after the File Reader has read them.



8

Confidential About This Document

Term Meaning Output file Resulting accounting data file, which has been produced by

the ARM. IAC ASCII Code BOD Bandwidth On Demand



9

Confidential Overview of MDS/ARM 2 Overview of MDS/ARM

2.1 Environment

The following figure shows how MDS/ARM is positioned within the Comptel Event Mediation system architecture:

Figure 1. MDS System Components



10

Confidential Overview of MDS/ARM

2.2 Overview of MDS/ARM functionality

The following figure shows the basic processes of MDS/ARM:

File Reader/Logfile Reader/

XML Reader

Conversion &Validation + Customer

Specific Modules

File Writer/XML Writer

Input Description/Parser Rule Set

OutputDescription

Conversion &Validation Rules

Output File(s)Raw Input File(s)

InvalidData

Runtime Summary

Logs

InvalidData

InvalidData

Figure 2. Processes in MDS/ARM

2.3 File Reader

The purpose of the File Reader (FR) is to read and decode the input data file. The decoded input data is then split into smaller data packages, i.e. records and data fields. Whenever a complete record for the next step has been collected and decoded all the needed data related to the record is sent to the following processes through the message interface. FR continues until all data has been read or an error occurs. A File Reader error can, for example, be caused by an unexpected raw data format.

2.4 Logfile Reader The Logfile Reader (LR) is designed to parse variable length ASCII data as its input. This data is produced by various network elements especially in IP networks. LR first loads the parser rule set, which it uses to read the raw usage information. While



11

Confidential Overview of MDS/ARM

reading the raw usage information, LR decodes the information and sends it to the following component, Conversion and Validation (CV).

2.5 XML Reader

The XML Reader (XMLR) validates the input file using the rules of well-formed XML. As soon as XML Reader has read the data file and decoded the data, it splits the data into records and data fields and sends the data to the following component, Conversion and Validation (CV).

2.6 Conversion and Validation

Conversion and Validation Module (CV) uses file reader (FR/LR/XMLR) output data as input and generates converted output data using conversion and validation functions.

The conversion and validation functionality (business logic) is implemented using the interpreted S-Lang programming language.

2.7 Event Aggregation

Event aggregation (e.g. long call combining) can also be performed within the Conversion and Validation Module (CV). Aggregation is the process of reducing the amount of output records by creating summary records based on the information from a number of input records.

2.8 File Writer

The File Writer (FW) reads the converted and processed data records, which it receives from the previous ARM modules. It uses an output configuration file for describing the layout of the unified data files to write. Whenever a complete record has been received, FW searches for the corresponding output format and output file from the description file, and writes the output record accordingly. The records can be written in different formats into several output files according to record type.

2.9 XML Writer

When XML Writer (XMLW) receives the converted and validated usage information, it verifies the data structure and writes the output record accordingly. XML Writer can simultaneously write out data in several XML-based formats.



12

Confidential ARM Processing Flow 3 ARM Processing Flow

The below diagram depicts the order of processing phases:

Output FileOutput File

Read in ER Fields

Apply Filtering Rules

UnsupportedERs

FilteredERs

Unsupported ERsare omitted from

furtherprocessing

Filtered ERs areomitted from

furtherprocessing

Supported ERs

Apply Validation Rules

Combine Partials

Invalid ERs

Partial ERs

ERs to be processed

Valid ERs

Single ERs

Apply Conversion Rules

Converted ERs

Write Converted ERs toOutput File(s)

Invalid Data File

Partial ERRepository

Output File

Combined ERs



13

Confidential Input File Naming Convention 4 Input File Naming Convention

The incoming file has the following filename:

<Prefix><DD>.<MM>.<YY>.<HH>.<MM>.<SS>.<Suffix> Example: A040805122412.txt.conv

Input file name Description Prefix ‘A’ DD File creation day format DD MM File creation month in format MM YY File creation year in format YY HH File Creation Hour MM File Creation Time SS File Creation Second Suffix ‘txt.conv’



14

Confidential Input Description 5 Input Description

BOD file is written in ASCII format. The record structure layout is based on the input description file as there is no separate documentation specifying the same. The implementation as well as documentation will be based on this layout.

5.1 File structure The file general layout for input files is ASCII written in a flat file with no defined charging blocks.

5.2 ER layout 5.2.1 BOD Record

The BOD record is variable length record with comma delimited fields. The layout of the BOD input records is illustrated in the below diagram.

Field 23

Field EOL

Field 2

Field 1

Fixed Length ER

Figure 3: Format of the BOD ER record

The field description of the INAMA input ER is described below: -

Field Position Field Name

Field Length

Field Type Field

Mandatory/Optional1 Date Variable ASCII M 2 Time Variable ASCII M 3 Record_Type Variable ASCII M 4 Acct_Session_Id Variable ASCII M



15

Confidential Input Description

5 UserId Variable ASCII M 6 UserName Variable ASCII M 7 LinkId Variable ASCII M 8 Type_Of_Service Variable ASCII M 9 Start_Date Variable ASCII M

10 Start_Time Variable ASCII M 11 End_Date Variable ASCII M 12 End_Time Variable ASCII M 13 Default_Bandwidth Variable ASCII M 14 Default_Status Variable ASCII M 15 Class1_Bandwidth Variable ASCII M 16 Class2_Bandwidth Variable ASCII M 17 Class3_Bandwidth Variable ASCII M 18 Class4_Bandwidth Variable ASCII M 19 Class5_Bandwidth Variable ASCII M 20 Class6_Bandwidth Variable ASCII M 21 Class7_Bandwidth Variable ASCII M 22 Class8_Bandwidth Variable ASCII M 23 Cumulative_Bandwidth Variable ASCII M

Table 1: Overview of collected data packages

Explanation of the used symbols:

Symbol Explanation

(n) n = integer value. This refers to length in bytes.

M Mandatory Field

O Optional Field.



16

Confidential Input Description

5.3 Supported ERs The following ER types are supported for this RuleSet.

ER Block Description Action BOD BOD ERs Processed

Note: Only one input ER format (BOD) is expected and catered for.



17

Confidential Filtering Rules 6 Filtering Rules

Based on the above supported ERs, filtering rules listed below are applied to records in the BOD to Kenan ARM conversion. Filtered records are sent to the invalids file.

The filtering rules are applied in the following order:

# Filter Based on Field / block Action 1. Records other than

BOD records The input description caters to only one record format. – BOD

Records are rejected at the FR level. No logs pertaining to the same are written.



18

Confidential Validation Rules 7 Validation Rules

This chapter describes which validation rules are valid for each input field.

7.1 ER validation rules

The validations are done in the order mentioned in the table below. If one of the validation rules is met, the record is sent to the Invalid Data File and processing continues with the next ER.

# Validation Based on CDR Field(s) Validation rule Action 1. Account Session ID

is Null. Acct_Session_Id Do not process the ER if the

Acct_Session_Id is Null. A Record is written to invalid file with explanation: “|NULL Acct_Session_Id not to be processed|”.

2. Record Type as “Start”.

Record_Type Do not process the ER if the Record_Type is NULL.

A Record is written to invalid file with explanation: “|Record_Type_BoD Start not to be processed|”.

3. Invalid Record Type

Record_Type Do not process the ER if the Record_Type is not a valid value.

A Record is written to invalid file with explanation: “|Record_Type_BoD other than Start/Stop/Interim not to be processed|”.

4. Null Record Type Record_Type Do not process the ER if the Record_Type is Null

A Record is written to invalid file with explanation: “|NULL Record_Type_BoD not to be processed|”.

5. Null User Name UserName Do not process the ER if the UserName is Null

A Record is written to invalid file with explanation: “|NULL UserName_BoD not to be processed|”

6. Null User ID UserId Do not process the ER if the UserId is Null.

A Record is written to invalid file with explanation: “|NULL UserId_BoD not to be processed|”

7. Null Link ID LinkId Do not process the ER if the LinkId is Null.

A Record is written to invalid file with explanation: “|NULL LinkId_BoD not to be processed|”

8. Null Start Date Start_Date Do not process the ER if the Start_Date is Null

A Record is written to invalid file with explanation: “|NULL Start_Date_BoD not to be processed|”

9. Null Start_Time Start_Time Do not process the ER if the Start_Time is Null.

A Record is written to invalid file with explanation: “|NULL Start_Time_BoD not to be processed|"

10. Null End Date and Time for a Stop Record Type.

End_Time End_Date

Do not process the ER if the call_type is STOP and End_Date and End_Time is Null.

A Record is written to invalid file with explanation: “|NULL End Date/Time for



19

Confidential Validation Rules # Validation Based on CDR Field(s) Validation rule Action

Stop Record not to be processed|"

11. Null Default Status Default_Status Do not process the ER if Default_Status is Null.

A Record is written to invalid file with explanation:” |NULL Default_Status_BoD not to be processed|"

12. Null Cumulative Bandwidth

Cumulative_Bandwidth Do not process the ER if Cumulative_Bandwidth is Null

A Record is written to invalid file with explanation: "|NULL Cumulative_Bandwidth_BoD not to be processed|"

13. Invalid return value from BODUSAGE lookup.

Cumulative_Bandwidth + DefaultBW(constant)

Do not process the ER if the return value from the lookup table BODUSAGE is 0 or is more than 5 characters long.

A Record is written to invalid file with explanation: "|Usage Type Cannot be allocated|"

14. Incorrect Start Date, Time Format and End Date and Time format.

Start_Date +Start_Time. ____________________ End_Date + End_Time for Record_Type “Stop”

The format of the Date and Time has to be of the format YYYY/MM/DD and hhmmss.

A Record is written to invalid file with explanation “Date is Invalid :< Date >.” Or “Time is invalid: <Time> .”

Note: For fields longer than the specified length in the input description, the fields will be truncated left justified.



20

Confidential Output File Naming Convention 8 Output File Naming Convention

The output file has the following filename:

BODUsage< Execution_date >< execution_id >.<suffix>

Output file name

Description

BODUsage Fixed Text Execution_date Date & time of output file generation execution_id The execution id generated by MDS ARM Suffix ‘Data’

Example:

BODUsage2004071314151113141506.data



21

Confidential Output Description and Conversion 9 Output Description and Conversion

This section describes the meaning, format and value for each field in the output file.

The output files are ASCII files starting with a Header Record and ending with a trailer record with output data records in the body of the file.

The fields of the output file are described in the following tables, wherein the column length and type will have values ‘D’, ‘A’, ‘H’, ‘B’ or ‘V’ and a number. Meaning of these characters is the following:

Type and length Description A9 Alphanumeric field, nine positions, left justified, space filled. D10 Numeric (range 0-9) field, ten positions, right justified, leading zeroes. H10 Hexadecimal (range 0-F) field, ten positions, right justified, leading

zeroes. B1 Binary field, one position. V5 Variable length to a maximum of 5 characters. DV10 Numeric (range 0-9) fields, variable length to a maximum of ten

characters.

9.1 File structure The output file structure is as follows. It contains header records, event records and trailer record.

Header Record Event Record Event Record … Event Record Trailer Record

9.2 Header record layout

# ER Field name Type and length

Related raw ER fields Conversion rule or value description

1. RECORD_TYPE A3 - Fixed: ‘HDR’ 2. CREATE_DATE A14 - Date of file creation

given in format YYYYMMDDHH(24)MISS

3. RECORD_SIZE A4 - Fixed: ‘0000’ 4. NO_OF_RECORD A7 - Fixed: ‘ 0’ 5. APPLICATION A16 - Fixed: '

MDS/ARM’



22

Confidential Output Description and Conversion



6. VERSION A6 - Fixed: ' 4.0' 7. DATA_RECORD_TYPE A3 Blank 8. EXTRA A8 Blank 9. BYTE_ORDER A4 Blank 10. END_OF_RECORD H1 - Fixed: 0x0A

9.3 Converted ER layout

ARM will generate records from input data according to the following conversion rules. The rules are based on both the input description and the output description. They describe how each output field in the record is created using input fields and conversion rules.



1. RECORD_TYPE A3 -

‘BL1’

2. External_Tracking_ID

A32 Acct_Session_Id As it comes in the raw CDR.

3. Type_ID_Usage A5 Cumulative_Bandwidth The value of the Cumulative_Bandwidth is rounded up using the following logic: - while(Cumultive_Bandwidth is not rounded) { Compare Cumultive_Bandwidth to be between 1000(low) and 2000(high) to begin with and their corresponding multiples of 2. Round up to the higher value when Cumultive_Bandwidth is between the two limits }

4. External_ID_Type A2 - Fixed: ‘10' 5. External_ID A48 UserName As the field comes in the raw CDR. 6. A_NUMBER A20 UserId As the field comes in the raw CDR. 7. B_NUMBER A20 - Blank 8. PRIMARY_UNITS A10 Start_Date

Start_Time This field is populated using the default return value from the Lookup Table “BODFREQUENCY” for all record types except “Stop”. For “Stop” record types the value is the mod of the above lookup table return value and the calculated duration.



23

Confidential Output Description and Conversion



9. SECONDARY_UNITS A10 Start_Time Start_Date

This field is populated using the default return value from the Lookup Table “BODFREQUENCY” for all record types except “Stop”. For “Stop” record types the value is the mod of the above lookup table return value and the calculated duration.

10. THIRD_UNITS A10 - Blank 11. AMOUNT A10 - Blank 12. CREATE_DATE A14 Start_Time

Start_Date

This is in the format YYYYMMDDhhmmss

13. TIME_ZONE A3 - Fixed: ‘ 1’ 14. Country_Code A3 - Fixed: ‘ 91’ 15. BILL_CLASS A5 - Fixed: ‘1’ 16. ANNOTATION A20 End_Date

End_Time It’s the concatenated value of the End date and End Time in the raw ER.

17. CUSTOMER_TAG A20 - Blank 18. COMP_STATUS A3 - Fixed: ' 1' 19. CAC_NUMBER A1 - Blank 20. END_OF_RECORD H1 - Fixed: 0x0A

9.4 Trailer record layout



1. RECORD_TYPE A3 - Fixed: ‘TRA’ 2. CREATE_DATE A14 - Date of file creation

given in format YYYYMMDDHH(24)MISS

3. RECORD_SIZE A4 - ‘0000’ 4. NO_OF_RECORD A7 Total number of records

in the output file (excluding header and Trailer)

5. APPLICATION A16 - Fixed: ' MDS/ARM’

6. VERSION A5 - Fixed: ' 4.0' 7. DATA_RECORD_TYPE A3 - Blank 8. EXTRA A8 - Blank 9. BYTE_ORDER A4 - Blank



24

Confidential Output Description and Conversion 9.5 Sample of Output Record

HDR200505021632590000000MDS4.0 BOD 1 01 2005050111382300000000360009866204888 009657204023

GWLA2312 B267 PULSE BSNL,BSNL BOD 2 01 20050501113856000000000300075013468608 09869361634

GWLA2331 NOR PULSE BSNL,BSNL

BOD 3 01 20050501113858000000000100 00491756107679 GWLA2305 A806 PULSE BSNL,BSNL

BOD 4 01 20050501111422000000243800 04055188553 GWLA2317 NOR PULSE BSNL,BSNL

.

.

. BOD 21173 01 2005050123592400000000330009842353581 0097339808996

GWLA2312 A162 PULSE AIRCEL,BSNL BOD 21174 01 200505012357350000000222000447958127949 02612481119

GWLA2331 NOR PULSE BSNL,BSNL

BOD 21175 01 2005050123595600000000020009880011261 0097339138967 GWLA2312 A151 PULSE BSNL,BSNL

TRA200505021633370021175MDS4.0



25

Confidential Duplicate Checker 10 Duplicate Checker

Note Duplicate Checker is a module, which checks whether an incoming ER with the same identification string has already entered the system.

No provision for any duplicate checking is built into this specific rule set. Duplicate may have to be handled externally, if required.



26

Confidential Event Aggregation 11 Event Aggregation

The feature to merge the partial calls (i.e. long calls) in the BOD ERs is NOT required in this case



27

Confidential Lookup Tables 12 Lookup Tables

During data processing done by MDS/ARM rule sets, it is sometimes necessary to enrich event records with external information. This can be done by inserting or updating data in the ER according to a predefined set of keys and their return values. These keys and return values are maintained in a lookup table. Each column specifies a key or a return value and each row are represented by a combination of values for the keys and return values.

MDS Lookup Server provides a mechanism for looking up data from the lookup tables stored in the Oracle database tables or UNIX files and placing them in the memory of a host, where MDS/ARM rule sets can read them. The rule sets can then make lookups to the lookup table data. MDS Lookup Server supports large amounts of data and performs lookups quickly.

Note The customer is responsible for maintaining the contents of Lookup tables.

For more information about the MDS Lookup Server and lookup tables, refer to documents MDS Lookup Server Functional Description and MDS Lookup Server Operation and Maintenance Guide.

12.1 Lookup Server tables used

The conversion module uses the following lookup tables:

Lookup Server table name

Description

BODUSAGE A pre-existing table, used for storing the UsageType identifiers to be mapped against the Cumulative Bandwidth Usage. The corresponding oracle table and view is LKP_BODUSAGE and VW_BODUSAGE respectively.

BODFREQUENCY A pre-existing table, used for storing a initialisation parameter which is used for deriving the output field “PRIMARY_UNITS” and “SECONDARY_UNITS”. The corresponding oracle table and view is LKPBODFREQUENCY and VW_BODFREQUENCY respectively.

Note: All the Oracle views are such that they select record from the respective Oracle Table where ENABLED_FLAG is Y



28

Confidential Lookup Tables

12.1.1 BODUSAGE table

BODUSAGE table is a pre-existing table, used for storing the UsageType identifiers to be mapped against the Cumulative Bandwidth Usage.

The corresponding oracle table and view is LKP_BODUSAGE and VW_BODUSAGE respectively.

Description of the LKP_BODUSAGE table entries:

Column Type Description ENABLED_FLAG VARCHAR2(1) A flag (Y/N) indicating whether this entry

is enabled or not. CUMILATIVE_BANDWIDTH

VARCHAR2(12) The cumulative bandwith used as the key field

USAGE_TYPE VARCHAR2(12) The usage type used as the return value COMMENTS VARCHAR2(100) General comments regarding this entry

The table contains the column CUMILATIVE_BANDWIDTH for key value. The column USAGE_TYPE is used as the return value. The type of the key column is defined as an exact match type.

12.1.2 BODFREQUENCY table

BODFREQUENCY table is a pre-existing table, used for storing a initialisation parameter which is used for deriving the output field “PRIMARY_UNITS” and “SECONDARY_UNITS”.

The corresponding oracle table and view is LKPBODFREQUENCY and VW_BODFREQUENCY respectively.

Description of the LKP_BODFREQUENCY table entries:

Column Type Description ENABLED_FLAG VARCHAR2(1) A flag (Y/N) indicating whether this entry

is enabled or not. PRIMARY_UNITS VARCHAR2(10) The primary units used as the key field DURATION VARCHAR2(10) The duration used as the return value COMMENTS VARCHAR2(100) General comments regarding this entry



29

Confidential Lookup Tables

The table contains the column PRIMARY_UNITS for key value. The column DURATION is used as the return value. The type of the key column is defined as an exact match type.



30

Confidential Customer Specific Parameters and Variables 13 Customer Specific Parameters and Variables

13.1 GRC file parameters and entries This conversion module uses the following customer specific parameters in the in the ARM GRC file.

GRC file section Parameter name Description arm_fr BOD: $(DESCDIR)/INMPLS_in.pm Input description for the BOD rulesets. arm_CV BOD:

$(DESCDIR)/slangcv.sl slangcv file for the BOD rulesets

arm_fw BOD: $(DESCDIR)/ outputDescription.desc

Output description for the BOD rulesets

arm_fw Arbor_Out_File: $(ARMHOME)/output/$(NEID)

Directory for the first output file

Note ARM GRC file refers to ~/.mds.rc

Generic ARM GRC parameters can be found in the document MDS/ARM Functional Description.



31

Confidential Customer Specific Files and Modules 14 Customer Specific Files and Modules

14.1 Summary log file

The following shows a sample summary report generated by MDS/ARM:

Date/Time for processing: Tue Jul 13 14:15:11 2004 EXEC ID for processing: 13141506 -------------------------------- arm_fr --------------------------------- INFILE1: /app/mdsamd/amdprd/amd/arm/input/BOD/A040712000044.txt.conv Number of data blocks read = 1 Number of bytes read = 19596648 Number of records read = 56967 TOTALS: Number of data blocks read = 1 Number of bytes read = 19596648 Number of records read = 56967 -------------------------------- arm_CV --------------------------------- CV Summary Data Total Records in = 56967 BOD Records in = 56967 Total Records Rejected = 32946 Total Records out = 24023 BOD records out = 24021 UNDE file path+filename = /app/mdsamd/amdprd/amd/arm/invalids/BOD/CVInvalidData.13141506 UNDE explanation file path+filename= /app/mdsamd/amdprd/amd/arm/invalids/BOD/CVInvalidExpl.13141506 Total processing real time in seconds : 14 Performance records/second (real) : 4069 -------------------------------- arm_fw --------------------------------- OUTFILE 1: /app/mdsamd/amdprd/amd/arm/output/BOD/BODUsage2004071314151113141506.data Size of file = 5909258 Number of records = 24023 Number of ASN.1 levels = 0 Number of ASN.1 base records = 0 Number of ASN.1 sub records = 0 Total number of output files = 1 Total bytes written = 5909258 Total records written = 24023 Total records rejected to invalid file = 0



32

Confidential Customer Specific Files and Modules 14.2 DSL modules

DSL module is a dynamically loaded library module, which can be used to extend basic CV functionality. This conversion module uses the following customer specific DSL modules.

Module Description

The generic DSL modules are described in MDS/ARM Extensions Functional Description.



33

Confidential Customer Specific Files and Modules Document Index

C

Conversion and Validation Module · 11

F

File Reader · 10 File Writer · 11 Filtering rules · 17

I

Input File Naming Convention · 13

L

Logfile Reader · 10

M

MDS/ARM basic processes · 10 overview · 9

T

terms · 7

V

validation rules · 18

X

XML Reader · 11 XML Writer · 11



34

Confidential

Reader’s Comments

Comptel Corporation welcomes your comments and suggestions on this manual. Your input will help us to write documentation that meets your needs. Please insert your comments to the form below and send your comments via email to the following address: [email protected] Please rate this document: Excellent Good Fair Poor Accuracy (software works as manual says) [ ] [ ] [ ] [ ] Completeness (enough information) [ ] [ ] [ ] [ ] Clarity (easy to understand) [ ] [ ] [ ] [ ] Organisation (structure of subject matter) [ ] [ ] [ ] [ ] Figures, if any (useful) [ ] [ ] [ ] [ ] Examples, if any (useful) [ ] [ ] [ ] [ ] Index, if any (ability to find topics) [ ] [ ] [ ] [ ] Usability (ability to access information fast) [ ] [ ] [ ] [ ] Please list errors that you have found in this document: Page Description Additional comments and suggestions to improve this document: What version of the software described by this document are you using? Name/Title

Dept.

Company Date Mailing address Email Phone


Documents

MDS ARM RuleSet Specification of BOD to Kenan Arbor for IBM Version 2.0 Draft 0.1