EWSD

IACHASTA

IACHASTA (Inter-administration Charging and Statistics)

Contents
1.0 1.1 2.0 2.1.1 2.1.2 2.1.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 3.0 4.0 Definition Feature in EWSD Registration IACMET Elements IACMET objects IACMET Registration Points IACMET Registration IACMET Registration States Implementation Call Data Traffic Discrimination Schedules Meters OSS Operator Position Displaying Meters Saving the Counter Data Example for calculating meter overflow for non-cyclic meters IACAMA Example for generating IACMET for IACOBJ as Statistical Counters 2 2 3 3 4 5 5 6 7 8 8 9 9 10 11 12 12 13 14

Copy rights reserved. This document is only for internal circulation within DoT/ BSNL

ALTTC/SW-II

1/15

Iachasta-01.07.06

EWSD

IACHASTA

IACHASTA (Inter-administration Charging and Statistics)

1.0 Definition
The feature IACHASTA is a flexible, requirements-oriented procedure used for billing transactions between telecom administrations. IACHASTA can be used for registration on meters (IACMET) and for individual call data recording (IACAMA). This document deals with the IACHASTA metering procedure (IACHASTA Metering). The IACHASTA Metering (IACMET) can be used for billing between telecom administrations and operators located in the same country as well as between telecom administrations and operators located in different countries. Besides call-charge calculation, IACMET can be used for collecting statistical data and for trunk group metering. It should be noted that the dynamic loading of the system can be influenced significantly by using the IACHASTA Metering. IACMET comprises the following steps: Registration of call data for predefined traffic relations Storage of data on meters Output of data to post-processing for generation of bills and/ or for statistical evaluation.

1.1

The Feature in EWSD

Mode of Operation
IACMET is based on the registration of call data for defined traffic relations. Depending on the requirements, the administration can identify the traffic relations for which call data are to be recorded. The IACMET procedure consists of software components in the group processors (GP) of the line/trunk groups (LTG) and in the coordination processor (CP). The IACMET components of the CP software are distributed among the following functional units: Call Processing, Administration, Input/Output Control. In the case of IACMET, the group processors record the relevant call data and transfer the data to the coordination processor. For this purpose, the GP software contains IACMET components in the functional unit LTG Call Processing.

ALTTC/SW-II

2/15

Iachasta-01.07.06

EWSD

IACHASTA When a call is set up, the coordination processor (functional unit Call Processing) determines whether a registration point has been set up for an element involved in the call (see IACMET Elements) and whether the registration is active. If so, the call is monitored in the group processor (GP) of the A-side line/trunk group (LTG) in order to determine the necessary IACMET call data. The B-side LTG of the recording exchange automatically sends the charge pulses received on the B-side to the A-side LTG. The CP stores the registered call data and makes them available by creating a billing file for post-processing, e.g., on a commercial data processing system.The GP of the A-side transmits the call data to the CP at the following times: after the end of the call During long duration calls after a time period administrable with the command MOD TIOUT: TIMER=114, TIMVAL=<h-m-s-ms>. The default value is 30 minutes. In order to set up the database for registration, an object name is assigned to one or more elements . These objects with object names can then be assigned to different registration points. Current meter states and data associated with a billing file can be displayed at the O&M terminal by entering the corresponding MML commands.

2.0

Registration

2.1.1 IACMET Elements The following connection elements can be used as IACMET elements: PBXs Digital line units (DLU) Directory number blocks Trunk groups Announcement trunk groups V5x-interface (V5IF) Destination (DEST), only standard destinations as a result of routing Statistical indices for zone points, (see Fig. 2.1)

ALTTC/SW-II

3/15

Iachasta-01.07.06

EWSD

IACHASTA

2.1.2 IACMET Objects

One or more elements can be assigned to an IACMET object with the command CR IACOBJ . Example: Object OBJECT1 contains: <dlu1>, <dlu2>, <dlu3>, <dlu4> Object OBJECT2 contains: 3100&4100 Object OBJECT3 contains: <tgno1>, <tgno2>, <tgno3>, <tgno4>,<tgno5> Object OBJECT4 contains: <stat50> where: OBJECT x ... Object name <dlu x> ...DLU designation 3100&4100 ... Directory number blocks <tgno x> .Trunk group number <stat50> ..Statistical index 50 which was assigned to a zone point A maximum of 8191 different IACMET objects can be installed.

2.1.3 IACMET Registration Points

ALTTC/SW-II 4/15 Iachasta-01.07.06

EWSD

IACHASTA

One or more objects are assigned to an IACMET or IACAMA registration point by the command CR IACRGPT. These objects can be defined as both originating and destination objects. For announcement trunk groups and statistical indices, however, only the assignments as destination objects are meaningful. There are anonymous, i.e., unnamed, registration points and named registration points (with names). Only one object and/or object combination is assigned to anonymous registration points (and subsequently also billed individually). Several objects can be registered via a named registration point. This is particularly effective for statistical purposes in the case of meter registration. For anonymous as well as named registration points, there are two types of registration points: Single-sided registration points: One or more originating or destination objects are assigned to these registration points. Double-sided registration points: Combinations of originating and destination objects are assigned to these registration points. An IACMET registration point is also defined by: the schedule according to which the registration takes place, e.g., to adapt to tariff changeovers the output type (meter or AMA). The assignment to a time schedule can be changed with MOD IACRGPT . A maximum of 32767 registration points can be set up, of which a maximum of 8191 can be registration points with different names.

2.2

IACMET Registration
Only one registration can run for a defined combination of output type and registration point. The command to be uised is ACT IACRG Single-sided meter registration (SINGLE) Double-sided meter registration (DOUBLE) Mixed (single-sided and double-sided) meter registration (MIXED) _ Registration of overall traffic (only for IACAMA) Therefore, for meter registrations, a registration point can only appear in a registration. In the case of IACAMA registrations, it can be selected in this exchange whether registration for predefined traffic relations or registration of overall traffic is required. A registration is identified with the following:

ALTTC/SW-II

5/15

Iachasta-01.07.06

EWSD Begin and termination time (BEG/TER) Output type (OUT=AMA/MET) Registration type (Single- or double-sided or mixed) (RGPTTYPE=SINGLE/DOUBLE/MIXED, only for meters) FILEEXT (Optional, only for meters)

IACHASTA

These parameters are specified at the start of the recording with ACT IACRG .

2.3

IACMET Registration States

A registration can be in one of the following registration states: Not available: The registration has not been activated or has already been stopped and billing has been completed. Pending: The registration has been activated, but the start time has not yet been reached. Or, the start time has been reached, but an internal error has occurred. Upon correcting the error, the registration can be restarted with an MML command started or deactivated with an MML command. Otherwise, the system automatically attempts to restart the registration every hour on the hour. Active: The registration is active. It can be deactivated with DACT IACRG. Terminated: The registration has been stopped, but a billing file has not yet been generated. This state is temporary, since a billing file is automatically generated when a meter registration is stopped. If there are problems accessing the fixed disk, the billing process is delayed. If a billing file has been generated, the registration is automatically switched to the "not available" state.

ALTTC/SW-II

6/15

Iachasta-01.07.06

EWSD

IACHASTA

ALTTC/SW-II

7/15

Iachasta-01.07.06

EWSD

IACHASTA

2.5

Call Data The call data that can be recorded include Call duration in seconds Number of calls Number of seizures Holding time before the B subscriber answers Call charges on the A side (A-side LTG of the exchange, optional) Call charges on the B side (B-side LTG of the exchange, optional) As a further option, it can be specified whether unsuccessful calls should also be registered. MML command ENTRCDTDAT can be used to select the optional call data. In each case, the holding time and call duration are measured by the group processors in the line/trunk groups (functional unit LTG Call processing). The holding time before the B subscriber answers is defined as the time interval from the application of the dial tone up to the time at which the B subscriber picks up. In the case of originating traffic and transit traffic, the call duration begins when the B subscriber answers; in the case of terminating traffic, it begins with the throughconnection of the call. For terminating traffic and transit traffic, the call duration ends when the A or B subscriber goes on-hook (outlet monitoring time taken into consideration) or with the release of the line. In the case of operator-assisted calls, the time during which the operator is involved is not included in the call duration. Only the time intervals that are billed to the subscriber are totaled.

2.6

Traffic Discrimination
For IACMET, traffic can be discriminated on the basis of transmission medium or connection type. If registration for a registration point (one-way or two-way) is to be differentiated on the basis of transmission medium, then there is no differentiation based on connection type, and vice versa. However, it is possible, for example, to differentiate the one-way registration points on the basis of transmission medium and, at the same time, differentiate the two-way registration points on the basis of connection type, and vice versa. Combinations of transmission media independent of connection type, and combinations of connection types independent of transmission medium, represent a traffic group in each case. A maximum of 4 traffic groups for transmission media and 3 traffic groups for connection types can be set up.

ALTTC/SW-II

8/15

Iachasta-01.07.06

EWSD

IACHASTA The call data are recorded separately for each traffic group. Furthermore, it must be specified whether these traffic groups pertain to one-way or two-way registration points. The following 4 transmission media can be registered: 3.1 kHz audio Voice 64 kbit/s 64 Kbit/s with fallback capability (Kbit64FB). For the registration of transmission media, IACMET uses the messages of the signaling system set up on the incoming trunk groups (ISUP and TUP+) or the trunk group identifiers of the incoming trunk group itself. All other signaling systems (e.g., MFC) use the default value 3.1 kHz audio. For ISDN subscribers set up via the A side, the transmission medium is determined on the basis of the service used. Based on this differentiation, the administration can also bill for calls depending on the quality of transmission. The following 3 connection types can also be registered: Coin box telephone Normal subscriber Service handset To register these connection types, IACMET uses the data of the A -subscribers provided they are connected to the own exchange. All other registrations use the default value "normal subscriber".

2.7

Schedules
Through the use of schedules, call data can be categorized based on the time of day and the day of the week (weekday, weekend, holiday, etc.) and thus assigned to various time groups. A time group is the designation given to one or more definable time intervals having a start time and end time. A maximum of 16 schedules can be set up. For each schedule, up to 6 time groups can be set up; it is possible to switch from one time group to another arbitrarily at 15-minute intervals.

2.8

Meters
The size of the IACMET meter records depends on the maximum number of time groups plus the maximum number of traffic groups. It is defined via MML commands and is identical for all registration points with meters. A meter is made up of a number of individual counters. It has the following structure:

ALTTC/SW-II

9/15

Iachasta-01.07.06

EWSD

IACHASTA

A-side charge pulses B-side charge pulses Number of calls Call duration Number of seizures Holding time before B-subscriber answers Checksum Each of these counters is assigned to a time group and/or a traffic group. The number of counters can be expanded to 65535, the number of registration points (which combine a corresponding number of counters) to 32767. However, depending on the selected splitting criteria, i.e., the time groups and traffic groups, and the resulting meter records, there are certain restrictions with respect to the number of registration points. For example, if the call data are differentiated into 4 traffic groups and 2 time groups, 8 counters must be made available for a registration point. If the database is only set up for a maximum of 10000 counters, then in this example only 1250 registration points can be set with counters (1250x8).

2.9

OSS Operator Positions

Calls handled via OSS operator positions are not recorded separately from normal traffic. An operator can only be a part of an IACMET object (directory number or DLU interface). If an operator, for example, connects a subscriber to a recorded announcement and then disconnects the subscriber from the announcement in order to reestablish the connection between the operator himself and the subscriber, this (OSS) connection is not registered! Only the connection from the Asubscriber to the B subscriber is registered, if it is part of an active registration (object in a registration point). Interruptions caused by operators in calls are not registered. As with normal traffic, only the overall call duration is registered.

2.10 Displaying Meters

When the APS is started, a file CA.IC.UCHA is set up automatically. The current state of meters since the last accounting and the contents of the file CA.IC.UCHA are displayed with command DISP MET. The parameter TYPE has to ALTTC/SW-II 10/15 Iachasta-01.07.06

EWSD

IACHASTA be given as IACMET. In case of a named registration point, the name (RGPT) is specified and, for an anonymous registration point, the origin (OBJORIG) and/or the destination (OBJDEST) has to be specified in the above command.

CA.IR.rnnns.fffff file : IACMET accounting is done by transferring the IACHASTA data from the file CA.IC.UCHA in the account file CA.IR.rnnns.fffff. The account file is then available for post processing. Accounting is done at the following times: At the end of each registration (end time reached or DACT IACRG) Automatically on the first day of every month at midnight After invoking an intermediate backup with the MML command EDIT MET: TYPE=IACMET; The registration job continues. The post-processing file is created during the accounting. It is located on both disks. The file name CA.IR.rnnns.fffff is composed as follows: r= S indicates single-sided registration D indicates double-sided registration M indicates mixed registration nnn = the day of the year e.g.1 to 366 s = 0 to 9 fffff = file extension, optionally entered with ACT IACRG, at the announcement of the registration. After the IACMET data have been transferred from the file CA.IC.UCHA to the account file, the counters are reset to zero, if they were created as non-cyclic counters (default). If the data of an account file CA.IR.rnnns.fffff is to be displayed with DISP MET there is the option either to display only a registration point or to display the data of the entire file. The name of the desired account file must, of course, be specified.

2.11 Saving the Counter Data

When the APS is started, a file CA.IC.UCHA is set up automatically. During an IACMET registration, the counter contents are automatically added to the counters of this save file (CA.IC.UCHA) once every hour. If, during a counter registration, a call extends beyond a time group changeover, the call data are added in the counters which are valid at the end of the call. If automatic saving should not be possible due to problems involving access to the fixed disk, the data are saved at

ALTTC/SW-II

11/15

Iachasta-01.07.06

EWSD

IACHASTA the top of the next hour. A corresponding error message is displayed on the screen. After an APS generation fallback, an APS change or ODAGEN extension, the counter save file is stored under the following name: CA.IC.UCHA.dddhhs, where: ddd = day number, based on 1 year (1...366) hh = hours s = consecutive number (0...9). Generation of a call billing file from such a closed save file is also possible via MML input. For the new APS, a completely new save file (CA.IC.UCHA) is created.

2.12 Example for calculating the meter overflow for non-cyclic counters
The registration counters in the meter file CA.IC.UCHA are designed so that they generally do not overflow in any given month. The registration counters for the seizure times and call duration and call charges are 30-bit counters, which means that it does not over-flow until after 1,073,741,823 seconds or pulses. Example: The meter can record the time for the uninterrupted use of 400 trunk groups for 31 consecutive days without overflowing (400 trunk groups x 31 days x 24 hours x3600 seconds = 1,071,360,000 seconds). The registration counters for the number of calls and number of seizures are 3-byte counters, which means that it does not overflow until after 16,777,215 seizures. Example: 500 trunk groups permanently in use with an average call duration of 90 seconds over a 31-day period do not cause an overflow (500 trunk groups x 31 days x 24 hours x 40 seizures = 14,880,000 seizures). If the overflow of certain registration counters is anticipated in spite of this, their current status can be displayed with DISP MET. An additional account file can be created with EDIT MET before overflow occurs. Afterwards, however, the registration meter is reset to zero. This account file is then available for postprocessing as soon as the file has been copied to tape. If an overflow occurs anyway, the counters retain their maximum value.

3.0

IACAMA
For IACAMA, the transmission medium requirement (not the line category, however) is indicated in each ticket. Therefore, there is no traffic differentiation for this registration. The differentiation of the traffic in time groups also does not apply

ALTTC/SW-II

12/15

Iachasta-01.07.06

EWSD

IACHASTA since the begin and end time of each call is stored in a separate ticket. The evaluation of the call duration occurs during post-processing. With the command DISP CHAREC the IACHASTA data records can be displayed. IACAMA Backup Tickets are backed up according to the usual AMA methods. IACAMA Post-processing When activating IACAMA with ACT IAFEAT, the disk file IA.ICIAR (IA.ICIAR1 and IA.ICIAR2) is automatically created. The creation of the disk files IA.ICIAR1 and IA.ICIAR2 can be controlled in the command ACT IAFEAT, parameter NUMFILES. Consequently, the IACAMA data is written into two disk files (IA.ICIAR1 and IA.ICIAR2). Before these files are written, each file is checked to see which has the most free storage, and the one with the most is selected. Because it is possible to read out both files in parallel, recovery situations and intermediate FTAM transfers can be avoided to a great extent with this procedure. During the IACAMA registration, the data is stored in the CP buffer. The writing of the buffer contents into the file IA.ICIAR (or IA.ICIAR1 and IA.ICIAR2) occurs at the following times: Entering the command: TRANS BUFFER: TYPE=IARA; Automatically when the buffer is full In principal the same commands apply as for AMA The contents of the disk file can be written to tape or magneto-optical disk: TRANS FILE: FILE=IA.ICIAR, VSNR=Tape/MO -ID, COPMOD=POST; After the tape file has been created, the cyclic disk file is released for overwriting: REL CYCFILE: FILE=IA.ICIAR; MML Commands for IACAMA -Activating the System Feature: ACT IAFEAT: TYPE=IARA, NUMFILES= ..., SIZE= ; -Creating IACHASTA Objects: CR IACOBJ: OBJ= <object name>, TGNO=<tgno> ; -Creating Anonymous Registration Points: CR IACRGPT: OBJORIG= ... and/or OBJDEST= ... , OUT= AMA; -Creating Named Registration Points: CR IACRGPT: RGPT=<registration point name>, OBJORIG= ... and/or OBJDEST= ...... , OUT=AMA; NOTE: If IACMET is also required in addition to IACAMA, then both AMA & MET should be given against OUT. -Activating the Recording with IACAMA Database: ACT IACRG: OUT= AMA, BEG= ... , TER= ... , ALLTRAFF=NO;

ALTTC/SW-II

13/15

Iachasta-01.07.06

EWSD -Activating the Recording without IACHASTA Database: ACT IACRG: OUT= AMA, BEG= ... , TER= ... , ALLTRAFF=YES; -Writing the Buffer Contents of the IACAMA File into the Disk File: TRANS BUFFER: TYPE=IARA; -Display IACAMA records: DISP CHAREC: TYPE = IACAMA;

IACHASTA

Note: For further details on IACMET/ IACAMA, please refer to OMN: EXCH-TA

4.0

EXAMPLE (for generating IACMET for IACOBJ as Statistical Counter)

The following commands should be entered in the given sequence: 1) Enter the maximum no of time groups to be used. ENTRIACSET: TIMGRPMAX= , TRAGRPMX= ,CYCLCNTR= NO/YES; Administration of the counter type is optional. The default is non-cyclic counters. Cyclic counters restart from 0 when their maximum value is reached. 2) Create the objects for which the metering is to be done CRIACOBJ: OBJ= <name>, STAT= < statistic counter > ; This statistic counter STAT should already be entered in the ZOPT for which statistic metering is to be done. 3) If statistic metering is to be done based on time schedules, the following command is to be used. Here the schedule is defined where different time groups are entered for different days of the week. MODIACSCHED: SCHED= < 1..16 the SCHED no. is entered>, TIMGRP= < 1..6>, TIME= ., WDCAT= ; e.g. If it is required that charges between 8:00AM and 7:00 PM should be displayed separately in time group 2 and the other charges separately in time group1 on all working days then the command is entered as MODIACSCHED: SCHED= 1, TIMGRP= 2, TIME=8-00 &&19-00 , WDCAT=WO;

ALTTC/SW-II

14/15

Iachasta-01.07.06

EWSD

IACHASTA 4) Create the registration point. This links the IACOBJ and the IACSCHED. CRIACRGPT: OBJDEST= <name as entered in CRIACOBJ>, OUT= MET, SCHED =1, RGPT=<NAME OF THE RGPT>; The IACHASTA observation is now ready to start the observation. The output of this observation contains the following fields by default Call Duration , No. of successful calls, Seizure time for B side answer and No. of seizures. Additionally the following fields may also be measured Call Charges on A side, Charges received from B side over trunks, Unsuccessful calls. The following command must be entered to get the additional fields. ENTRCDTDAT: REC= IACMET, EXTNSD= <value = CHARGE > The IACHASTA recordings may now be started The following command is necessary ACT IACRG: OUT =MET, RGPTTYPE = MIXED; The output of the IACHASTA meters can be seen using DISPMET: TYPE= IACMET, OBJDEST= .< name of IACOBJ>;

ALTTC/SW-II

15/15

Iachasta-01.07.06