5i' Recommendation Z.336 TRAFFIC MEASUREMENT ADMINISTRATION 1 General This Recommendation has been developed in accordance to the methodology defined in Recommendations Z.332 and Z.333. The main part of this Recommendation deals with the model of Traffic Measurement Administration and a glossary of the terms used is also included. The list of operator jobs and the list of system functions to be controlled are contained in Annex A. For each system function to be controlled by means of MML, one or more MML functions can be derived and each of them can be described using the metalanguage defined in Recommendation Z.333, in order to detail the relevant information structure. Annex B contains a list of MML functions and information structure diagrams associated to each of them to be used as guide- lines. 2 Introduction Traffic measurement administration functions are related to data production, collection and output. These data are achieved by means of periodic and non-periodic traffic measurements carried out in the telecommunications systems and are output by the systems in a suitable form. The traffic measurement result outputs should contain the measurement results and general information about the measurement itself and about the system which performed the measurement, in order to ease the results analysis. Moreover, they should contain information summarizing the production of output blocks for check- ing purposes. The traffic measurement model in S 4 is based upon a more gen- eral measurement model given in S 3. 3 General measurement model A measurement is identified by three basic elements: time, entities, objects. Time includes all the necessary information to define the start, the duration and periodicity of a certain measurement. Entities describe the quantities for which data collection must be performed with a certain measurement, e.g. traffic flow, number of call attempts, congestion time. Objects are intended as individual items within each object type on which the measurements are performed. Examples of object types are subscriber lines, circuits, circuit groups, elements of switching networks, geographical areas with their corresponding dialled code. The definition of measurements is based on an abstract model which contains the definition of a measurement matrix (see Figure 1/Z.336) in which each row represents one uniquely definable entity, e.g. number of call attempts, and each column represents a uniquely definable object type, e.g. incoming junction group (see Figure 2/Z.336). A certain combination of entities and object types corresponds to certain entries in the measurement matrix and forms a measure- ment type. It is recognized that part of these measurement types may be standardized while the rest of them seem to be system and/or administration dependent. It should be noted that some of the entries in the measurement matrix could be impossible (e.g. call congestion on an incoming trunk) and some others could be more or less meaningless. A single object is defined by its type and/or its individual object identity. In some measurement types, the number of objects is fixed. In other types, one can choose for the actual measurement some or all of the allowed objects by means of MML com- mands. The chosen (selected) objects form an object list. The structure of the division of object types and entities is open-ended, in such a way that any new object type or entity may be added. Figure 1/Z.336, p. Figure 2/Z.336, p. 4 Traffic measurement administration model 4.1 Basic classes of measurements Two basic classes of measurements are envisaged (see Figure 3/Z.336). The first class (A) is measurement of undetermined duration while the second one (B) is intended to be performed only for a predetermined duration. The start of a measurement may be intended as instantaneous or delayed for a defined time duration, t1, from the activation of the measurement. Since the stop time of a measurement of class A is not given when the measurement is activated or created, it has to be given during the measurement unless the measurement is intended to go on forever. Figure 3/Z.336, p. From the deactivation point of time there may be a defined delay of t2before the measurement is stopped. In the creation of a measurement a start time may optionally be provided, in which case for that particular measurement, the activation function is not necessary. Time parameters needed to control a measurement can be divided into three groups: 1) measurement type dependent time parameters [interval parameters of a measurement type, e.g. sampling interval ]; 2) measurement dependent time parameters (e.g. time parameters which define the periodicity of measurement); 3) measurement independent time parameters (e.g. time parameters which are related to the actual start or stop of a certain measurement in activation and deactivation functions). 4.2 Traffic measurement structure A traffic measurement (in the following called measurement) consists of: - measurement set information, - time information, - output routing and scheduling information (output parameters). Measurement set information, time information, output routing and scheduling information may be completely or partially pre-defined (initially provided by the supplier but changeable via MML inputs) or fixed (not changeable via MML inputs). The MML func- tions described for traffic measurements administration are intended to be supported to the extent that there is a need for user manipulation of the identified information items. If some of this information is fixed in a system, the relevant _________________________ Sampling interval, the time interval between two con- secutive samplings. MML functions may not be provided in that system. 4.2.1 Measurement set information Measurement set information consists of one or several selected measurement types with defined objects (object lists) and measurement type dependent parameters (e.g. sampling interval, number of events of a certain category, destination codes, etc.). Note that for traffic measurement administration purposes measurement types are fixed at a given moment in time and they can- not be created, deleted or changed by MML commands; these measure- ment types may be changed only later by supplier releases according to new requirements. It is recognized that administrations may require MML functions to administer measurement types, grouping predefined entities of object types. Such functions should be con- sidered as system extension and upgrade functions and, therefore, they should belong to the system control functional area. However, due to the fact that system control functions will not be inserted in the present Recommendations, they are described hereafter. 4.2.2 Time information Measurements of types A and B may involve continuous recording or recording on predetermined days (recording days). For measurements performing continuous recording only the start data is needed. For recording on predetermined days, these days are determined on a periodical basis (periodicity pattern) in case of measurements of undetermined duration. For measurements of predetermined dura- tion, the recording days are determined on a periodical basis or on a non-periodical basis (dates of recording days). These possibili- ties are summarized in Figure 4/Z.336. Figure 4/Z.336, p. Time data are defined at three main levels, as shown in Figure 5/Z.336. Measurement level | ontains information about either: - dates of recording days (in case of a non-periodical measurement). The start and stop date of the meas- urement are implicitly defined by the dates of the first and the last recording day. No activation function may be needed in this case; - periodicity pattern (in case of periodical meas- urement) of recording and non-recording days. Recording day level | ontains information about the start time and stop time for the recording periods within a recording day (e.g. from 09 to 12 and from 15 to 17). No overlap of recording periods is allowed for the same measurement. Recording period level | ontains information about the periodicity of the data collection based on the result accumulation period. The result accumulation period is the time interval within a recording period during which the required measurement entities are processed and at the end of which results are stored for immediate or later output (e.g. 15 minutes). The result accumulation period can be shorter than the recording period; in that case more than one set of data is collected for each of the recording periods to be routed toward the output media according to the results output schedule. Figure 5/Z.336, p. 5 Additional information 5.1 Measurement output contents and procedures Activation of a traffic measurement causes the output of meas- urement results with the following procedures. The produced output is routed toward the media specified in the output routing list associated to the measurement, e.g. printers, magnetic tapes, data links, system output files, etc. The output is made according to the output schedule. The measurement results output is done according to time data related to the measurement. A measurement results output is made with the following logical blocks: a) a "begin block" which contains measurement data, parameters i.e. measurement types data, time data, output data and data of interest related to the exchange configuration; b) one or more "result blocks", one for each result output period, which contain the measurement results; c) an "end block" which contains a general summary about the performance of the measurement, i.e. number of result blocks, number of interruptions of the measurement and the causes of the deactivation of the measurement (scheduled or forced). If during the performance of the measurement, the measurement is suspended (e.g. due to a system crash) the measurement results output could be continued after the system restart with a new out- put of the begin block. This continuation may be accomplished automatically by the system or by user action. The system should notify the user via an output if the latter case applies. The relationship between time data for the result accumulation period and time data defining the results output schedule is system or even measurement dependent and it is not considered herein. 5.2 Simplification of traffic measurement administration It is recognized that, for particular applications, there may not be an interest in administering the data base of traffic meas- urements. Consequently, the only MML functions needed are activa- tion and deactivation functions. In such cases, in order to ease the operator's work, the asso- ciation between the measurement and the objects may be made when activating the measurement itself, provided that the association is unambiguous. 6 Glossary of used terms Recording Performance of the operations implied by the measurement enti- ties in order to collect the required data. recording day Day when a recording is performed. Several recording periods are allowed within a recording day. No overlap of recording periods is allowed for the same measurement. Each recording period can have a different length. start date Start day for the measurement execution. stop date Stop day for the measurement execution. periodicity pattern A pattern which indicates which days are recording (or results output) days and which are not. The start day positions this time span. Once activated, the execution of the measurements (or of the results output) is performed according to this pattern, until dis- abled by a deactivation command. start time Time for beginning the recording period in a recording day. stop time Time for terminating a recording period in a recording day. recording period A period of recording during a recording day. results accumulation period Time interval within a recording period during which the required measurement entities are processed and at the end of which results are stored for immediate or later output. output parameters Data determining output routing and scheduling. results output routing Data defining the media to which results output is to be directed. results output schedule Data specifying a set of days (or a periodicity pattern) and of times during these days when the output of the results is to be made. ANNEX A (to Recommendation Z.336) List of system functions to be controlled by MML and list of jobs A.1 List of system functions to be controlled by MML 1) Performing traffic measurements. 2) Scheduling traffic measurements execution and results output. 3) Managing measurements' data. 4) Retrieving measurements' data. A.2 List of jobs 1) To create new measurements or measurement com- ponents and to modify old ones, by defining the entities to be measured and the objects and parameters of the measurements them- selves (what and how to measure): - the purpose of this job is to create and/or modify a set of data which is used by the system to perform a meas- urement in a given way; - the system is supposed to record the set of data of the measurement, and to check their static correctness; - the user is supposed to input/change all relevant data. The modification of data may be performed by means of dif- ferent procedures, depending whether or not those data are related to activated measurements; - the complexity of the job could be high depending on the amount of data to be input; - the frequency of the job is low; - the job is supposed to be performed at exchange and/or OMC level. 2) To delete obsolete measurements or measurement components: - the purpose of the job is to delete measurement of no further use or measurement components to release the employed resources; - the system is supposed to delete the data related to a specified measurement if the measurement is not active. The system is supposed to delete a measurement component only if it is not an active measurement component; - the user is supposed to input the identities of measurements or measurement components to be deleted; - the complexity of the job is low; - the frequency of the job is low; - the job is supposed to be performed at exchange and/or OMC level; 3) To define the measurement results output routing and scheduling (where and when the results will be output): - the purpose of the job is to define where the measurement outputs have to be routed to and when they should be output; - the system has to route the measurement outputs toward the recording media or toward other systems specified, according to the results output schedule; - the user has to input the identity of the desti- nation of the output and the results output schedule to be followed by the system; - the complexity of the job is low; - the frequency of the job is medium; - the job may be performed at exchange and/or OMC level. 4) To activate and to deactivate measurements (when to measure): - the purpose of the job is to activate and/or deactivate the performance of the measurements that have been pre- viously defined; - the system is supposed to activate and/or deac- tivate a measurement and to start the production of the results; - the user is supposed to input the date and time of activation and/or deactivation; - the complexity of the job is low; - the frequency of the job is medium; - the job may be performed at exchange and/or OMC level. 5) To retrieve different kinds of information related to traffic measurements: - the purpose of the job is to get information on measurements previously input in the system(s) in order to be aware of the current situation; - the system is supposed to output in suitable for- mats and on the selected device(s) the information requested; - the user is supposed to input the identity of the items to be interrogated and to select retrieving criteria; - the complexity of the job is low; - the frequency of the job is medium; - the job may be performed at exchange and/or OMC level. ANNEX B (to Recommendation Z.336) Guidelines for the list of MML functions and associated information structure diagrams B.1 Introduction This Annex contains guidelines for the list of MML functions and associated information structure diagrams related to the rout- ing administration model defined in Recommendation Z.336, S 4. B.2 List of MML functions This list contains possible MML functions for traffic measure- ment administration. Those functions dealing with information (e.g. measurement set, time data list, etc.) that is fixed in a system are not relevant for that system. This list is not mandatory nor complete, it may vary according to Administration needs, telecommunication network levels, regula- tory needs, etc. These MML functions do not represent the actual command struc- ture of any real implementation of the man-machine interface. Each of the MML functions identified can be implemented by providing one or more separate distinctive commands or several MML functions could be implemented by using a single command. 1) Creation - create a measurement; - create a measurement set; - create an object list; - create a time data list; - create an output routing list; - create a result output schedule. 2) Deletion - delete a measurement; - delete a measurement set; - delete an object list; - delete a time data list; - delete an output routing list; - delete a result output schedule. 3) Activation - activate a measurement. 4) Deactivation - deactivate a measurement. 5) Interrogation - interrogate a measurement; - interrogate a measurement set; - interrogate a mesurement type; - interrogate an object list; - interrogate a time data list; - interrogate an output routing list; - interrogate a result output schedule. 6) Changing - change a measurement; - change a measurement set; - change an object list; - change a time data list; - change an output routing list; - change a result output schedule. 7) Administration of measurement types - create a measurement type; - delete a measurement type; - change a measurement type. B.3 Information structure diagrams The information entities needed for the MML functions previ- ously defined have been identified and are reported in this section by means of diagrams representing each MML function information structure (Figures from B-2/Z.336 to B-41/Z.336). In particular, the information structure diagrams of the measurement outputs are given in Figures from B-42/Z.336 to B-45/Z.336. An overview of the measurement data structure is also given in Figure B-1/Z.336. The metalanguage used is defined in Recommendation Z.333. Blanc Figure B-1/Z.336, p.6 Figure B-2/Z.336, p.7 Figure B-3/Z.336, p.8 Figure B-4/Z.336, p.9 Figure B-5/Z.336, p.10 Figure B-6/Z.336, p.20 Figure B-7/Z.336, p.21 Figure B-8/Z.336, p.22 Figure B-9/Z.336, p.23 Figure B-10/Z.336, p.24 Figure B-11/Z.336, p.25 Figure B-12/Z.336, p.26 Figure B-13/Z.336, p.27 Figure B-14/Z.336, p.28 Figure B-15/Z.336, p.29 Figure B-16/Z.336, p.30 Figure B-17/Z.336, p.31 Figure B-18/Z.336, p.32 Figure B-19/Z.336, p.33 Figure B-20/Z.336, p.34 Figure B-21/Z.336, p.35 Figure B-22/Z.336, p.36 Figure B-23/Z.336, p.37 Figure B-24/Z.336, p.38 Figure B-25/Z.336, p.39 Figure B-26/Z.336, p.40 Figure B-27/Z.336, p.41 Figure B-28/Z.336, p.42 Figure B-29/Z.336, p.43 Figure B-30/Z.336, p.44 Figure B-31/Z.336, p.45 Figure B-32/Z.336 (feuillet 1 sur 2), p.46 Figure B-32/Z.336 (feuillet 2 sur 2), p.47 Figure B-33/Z.336, p.48 Figure B-34/Z.336, p.49 Figure B-35/Z.336, p.50 Figure B-36/Z.336, p.51 Figure B-37/Z.336, p.52 Figure B-38/Z.336, p.53 Figure B-39/Z.336, p.54 Figure B-40/Z.336, p.55 Figure B-41/Z.336, p.56 Figure B-42/Z.336, p.57 Figure B-43/Z.336, p.58 Figure B-44/Z.336, p.59 Figure B-45/Z.336, p.60