8 TMN management functions

32.0053G call and event data for the Circuit Switched (CS) domain3GPPCharging managementRelease 1999Telecommunications managementTS

This clause describes the individual TMN management functions (TMN-MFs) required. As described in ITU-T M.3400, each of these TMN-MFs shall be mapped onto one or more OSI System Management Functions (SMFs) defined in the following recommendations:

– Object Management Function (ITU-T X.730 [7]);

– State Management Function (ITU-T X.731 [8]);

– Alarm Reporting Function (ITU-T X.733 [9]);

– Event Reporting Management Function (ITU-T X.734 [10]);

– Log Control Function (ITU-T X.735 [11]).

In the following subclauses, each group of TMN functions is described in terms of the SMFs required. The terms create/ set/ get/ delete/ action/ and notification each refer to the appropriate pass-through service defined in ITU-T X.730 [7]. The object classes on which these operations are performed are described in detail in annex A.

It should be noted that each of the network management operations described may be performed on a particular Network Element (NEF) or "broadcast" to all relevant Network Elements. Both the handling of such "broadcast" operations and the mechanisms required to ensure the consistency of the information distributed are considered to be outside the scope of the present document.

8.1 Tariff administration

The following management functions are provided:

– Tariff class management;

– Tariff period management;

– Day class management;

– Tariff management;

– Tariff system management (change control).

8.1.1 Tariff class management

The purpose of the tariff class management functions is to permit the OS to assign a tariff class to a set of service and distance dependent charging parameters. Distance dependencies are defined in terms of charging origins, charging destinations and charging zones. Service dependencies are defined in terms of customised AoC services. For further details see subclause A.1.1. The table 1 includes some examples of possible tariff classes.

Table 1: Tariff class examples

Tariff class description

Service and distance dependencies

Telephony, class 2 mobiles, calls made within a particular metropolitan area

Service, origin, destination, MS classmark

Telephony, half rate codec, international calls

Service, destination, radio channel used

Short message service, mobile originated

Service only

8.1.1.1 Charging origin functions

This group of functions shall be used to create, set, get, and delete one or more charging origins. A charging origin represents a nominal reference point for the origination of a connection or transaction. Charging origins may be derived from a number of network configuration parameters including originating cell-id., incoming trunk group, MSC id. etc. The derivation of charging origins is a network specific matter and outside the scope of the present document. For the purpose of the present document it is sufficient to know the names and identities of the origins available.

The following system management functions are required:

Create/Set/Get/Delete chargingOrigin

8.1.1.2 Charging destination functions

This group of functions shall be used to create, set, get, and delete one or more charging destinations. A charging destination represents a nominal reference point for the termination of a connection or transaction. Charging destinations may be derived from a number of parameters including the called number, roaming number etc. The derivation of charging destinations is a network specific matter and outside the scope of the present document. For the purpose of the present document, it is sufficient to know the names and identities of the destinations available.

The following system management functions are required:

Create/Set/Get/Delete chargingDestination

8.1.1.3 Charging zone functions

This group of functions shall be used to create, set, get, and delete one or more charging zones. A charging zone provides a nominal measurement of the distance between the point of origination and termination of a connection.

Each charging zone shall consist or one or more origin and destination combinations. Each origin and destination combination shall contain a charging origin and/ or a charging destination. Only those origins and destinations previously created by means of the TMN-MFs functions described above may be referenced by a charging zone.

The following system management functions are required:

Create/Set/Get/Delete chargingZone

8.1.1.4 AoC service functions

This group of functions shall be used to create, set, get, and delete one or more AoC service definitions. An AoC service definition is a grouping of services together with additional charging parameters to provide a customised definition of a service for the purpose of Advice of Charge.

An AoC service definition shall consist of a combination of the following:

– one or more basic services; and/or

– one or more supplementary services; and/or

– one or more network specific services; and/or

– one or more power capability classes (MS classmark); and/or

– the type of radio traffic channel used/ requested;

– the transparency mode of the basic service employed (transparent/non-transparent);

– the type of call or connection (e.g. MOC/ MTC).

This list may also be extended to include additional network specific parameters.

The following system management functions are required:

Create/Set/Get/Delete aocService

8.1.1.5 Tariff class functions

This group of functions shall be used to create, set, get, and delete one or more tariff classes. A tariff class is a grouping of service and distance dependent charging parameters for the purpose of defining the corresponding tariff switching patterns.

Each tariff class shall contain one or more service distance dependencies. Each service distance dependency shall contain a reference to an AoC service definition and may include a reference to a charging zone.

The following system management functions are required:

Create/Set/Get/Delete tariffClass

8.1.2 Tariff period management

These functions permit the OS to create, set, get, and delete the tariff switching patterns and tariff periods defined in the NEs i.e. to manage the time-based tariff dependencies.

Each tariff class shall contain one or more tariff switching patterns, each of which assigns a tariff switching pattern to a particular day class. Each tariff switching pattern in turn shall contain one or more tariff periods.

A tariff period is a period of the day during which a particular tariff is applied e.g. a "peak rate" tariff period from 08:00 to 20:00. A tariff period shall contain a tariff switch-over time and a reference to the tariff to be applied after the switch-over. If the tariff to be applied does not change during the day then a single tariff period shall be defined with a default switching time of "00:00" i.e. Midnight. For further details see subclause A.1.2. The following table includes an example switching pattern for a particular tariff class.

Table 2: Tariff switching patterns for one tariff class

Day Class

Tariff

Switching

Pattern

Tariff Period 1

Tariff Period 2

Tariff Period 3

Working day

00:00 "off-peak"

08:00 "peak"

18:00 "off-peak"

Holiday

00:00 "off-peak"

The following system management functions are required:

Create/Set/Get/Delete tariffSwitchPattern

8.1.3 Day class management

These functions permit the OS to create, set, get, and delete the day classes employed by the charging calendar table in the NEs. A day class groups together a number of days of the year for which the same tariff switch-over pattern applies e.g. Work days, Weekends and Holidays etc.

Each day of the week (Monday, Tuesday, etc.) shall be assigned by the charging calendar to a particular day class. Each day of the year (date) may also be assigned to a day class. The day class defined for a particular date takes priority over the class defined for the day of the week i.e. each day of the year belongs to one and only one day class.

A day class shall first be explicitly created before it can be referenced by a charging calendar. A separate charging calendar shall be created for each year.

The following system management functions are required:

Create/Set/Get/Delete chargingCalendar

Create/Set/Get/Delete dayClass

8.1.4 Tariff management

These functions permit the OS to create, set, get, and delete the tariffs defined in the NEs. In a GSM environment the tariff information takes the form of charge advice information (CAI) parameters as defined in 3GPP TS 22.024 [12].

In addition to the tariffs of the home PLMN, an invariant tariff set shall also be held for each foreign PLMN in order to provide AoC for MTCs to roaming subscribers as defined in 3GPP TS 22.024 [12]. This set also includes the e3 scaling factor required to convert the VPLMN units incurred into the units of the roaming subscribers home PLMN as displayed by the MS.

The following system management functions are required:

Create/Set/Get/Delete tariff

Create/Set/Get/Delete roamerTariff

8.1.5 Tariff system management (change control)

This group of functions controls the changes made to a tariff system as a whole rather than to individual entities. A tariff system is defined as a complete and consistent set of the following: tariffs (including roamer tariffs), tariff periods, tariff switching patterns and tariff classes.

Only one tariff system may be "active" at any given time and the entities contained within the active tariff system shall not be modified.

In addition to the active tariff system, there may be a number of additional tariff systems under development. On creation a tariff system shall assume the "available" state and may be extended or modified by employing any of the tariff class, tariff period or tariff administration functions as required.

In order to minimise the amount of effort required to modify an existing tariff system the "tsCopyTariffSystem" action may be used to create a complete copy of the current tariff system. The new (copied) system may then be modified or extended as required.

On completion of the modifications to a tariff system a check may be performed within the NEF in order to ensure that the set of tariffing parameters is consistent. If required, the check shall be invoked by means of the "tsCheck" action. If the check is successful then the tariff system shall assume the "checked" state.

The activation of a tariff system may either be immediate, or scheduled to take place at some future date and time e.g. Midnight on the 1 January. The activation of a tariff system involves a changeover between the current and the new tariff system. A changeover between tariff systems shall be invoked by means of the "tsChangeover" action. On changeover, the old tariff system shall assume the "standby" state. If, for any reason, the new tariff system causes problems then a second changeover may be performed swapping the current and standby tariff systems and thereby restoring the old configuration.

The change-over function may also include authentication parameters to ensure that the OS user is permitted to carry out the desired changes to the tariff system.

If, for any reason, a scheduled changeover is to be prevented, then the "tsCancelChangeover" action shall be employed to remove the scheduled changeover request. Both the currently active tariff system and the next scheduled changeover may be retrieved at any time by means of a "get" on the appropriate attributes.

Modifications and extensions to a tariff system (or the entities contained in it) are only permitted in the "available" state. If, for any reason, a tariff system in the "checked" or "standby" state requires modification then it shall first be explicitly released via the "tsUnfreeze" action.

Any modification in the state of a tariff system shall be reported to the OS by means of the "stateChange" notification.

The following system management functions are required:

Get

tariffAdmin

Action

tsChangeover, tsCancelChangeover, tsCopyTariffSystem

Notification

stateChange

Create/Set/Get/Delete

tariffSystem

Action

tsCheck, tsUnfreeze

Notification

stateChange

8.2 Data collection

The data collection management service component employs both the event report function (ITU-T X.734 [10]) and log control function (ITU-T X.735 [11]). The conceptual model is illustrated in figure 4. The call recording function collects internal telecommunication events within the NEF and formats them into potential call and event records. The record generation control functions determine which of these potential records are actually stored in the local NEF record filestore. The records within the filestore are collected by the OSF via file transfer (FTAM protocol on X.25 or TCP/IP, and FTP or TFTP over TCP/IP). The record classes of the record generation control function also determine which of the records produced are transmitted to the OSF in the form of event reports.

Similarly, the log control function determines which of the potential records are stored locally as log records. Once stored the log records may be individually accessed by the OSF via the appropriate object management functions. Care should be taken in the selection of filter criteria for the call and event record logs to avoid unnecessary overheads.

Finally, the potential call and event records are also passed to the event forwarding discriminators of the event reporting function. The EFDs determine which of the potential records are transmitted to the OSF in the form of event reports. Whereas the record classes are intended to produce event reports on a semi-permanent basis for day to day operation, the EFDs are intended for short term event reporting and with more complex filter constructs.

Figure 4: Data collection model

8.2.1 Data generation control

The following groups of TMN management functions are provided:

– Record generation control;

– Emergency call notification control;

– Observed IMEI ticket control;

– Log control.

8.2.1.1 Record generation control

These TMN management functions control the generation of call and event records within the record filestore of the NEF. The following groups of functions are provided:

– Record type generation control;

– Supplementary service recording control;

– Partial record generation control.

8.2.1.1.1 Record type generation control

This group of functions permit the network operator to enable/disable the generation of each call/event record type and to specify the conditions under which such records will be generated.

Each type of record to be stored locally within the record filestore shall be contained within one or more record classes. The record class shall define the destination(s) to which the records are to be sent. Each destination may be either a particular type of file within the filestore, or another management application to which the record shall be sent in the form of an event report.

Each record class shall contain one or more record type controls. Each record type control shall include the conditions under which the records of this type are to be generated. The records may be created for home subscriber and/ or visiting subscribers. The records may also be created for unsuccessful and/ or successful transactions.

The following system management functions are required:

Create/Set/Get/Delete recordClass

Create/Set/Get/Delete recordTypeControl

See also supplementary service recording control.

8.2.1.1.2 Partial record generation control

This function controls the generation of partial records. Partial records may be generated for any one of the following reasons:

– expiry of the partial record timer;

– change of basic service during a connection;

– change of location (LAC, Cell Id for 2G or SAC for 3G) during a connection;

– change of MS classmark during a connection;

– change of AoC parameters during a call;

– change of radio channel (full/ half rate) during a call;

– change of HSCSD parameters during call;

– change of destination during a call (CAMEL).

This function permits both the selection of the above options and the specification of the partial record interval timer for long hold calls. The timer may take any value within the range 0 to 24 hours, where 0 means no partial records will be generated.

The following system management functions are required:

Set/Get callRecordingFunction

8.2.1.1.3 Supplementary service recording control

These functions control the recording of supplementary service actions. There are two basic kinds of supplementary service action, call-related and non-call related.

Non-call related SS-actions may be recorded in SS-action records as defined in Annex B. Call-related SS-actions (usually "invocation") may either be included in the appropriate call record (MOC/ MTC) or recorded in separate SS-action records.

Functions are provided to enable the OS to define the supplementary services to be recorded via the creation of "supplServiceControl" objects. These objects may be defined for both individual services and for groups of services. A separate set of these objects may be contained within each record class object.

Each "supplServiceControl" object shall contain one or more "ssActionControl" objects which define the supplementary service action (registration, erasure, etc.) to be recorded; how the action is to be recorded (in MOC/ MTC records or in SS-action records); and for which class of subscribers the actions are to be recorded (own/ visiting/ all subscribers).

The following system management functions are required:

Create/Set/Get/Delete supplServiceControl

Create/Set/Get/Delete ssActionControl

8.2.1.2 Emergency call notification control

This function permits the OS to enable/ disable the generation of the emergency call notification. It also permits the OS to define the destinations (management application entities) to which the notification is to be sent.

The following system management functions are required:

Set/Get callRecordingFunction

8.2.1.3 Observed IMEI ticket control

This function permits the OS to enable/ disable the generation of observed IMEI tickets. If the generation of these tickets is enabled then they shall be stored in the appropriate file type ("observed IMEI ticket") within the local record filestore.

This function also permits the definition of one or more destinations (management application entities) to which the tickets may be sent in the form of event reports.

The following system management functions are required:

Set/Get callRecordingFunction

8.2.1.4 Log control

This function permits the record notifications described above to be stored and retrieved from logs within the NEF. The logging of these records is performed in accordance with the log control function specified in ITU-T X.735 [11] and no additional management functions are required.

8.2.2 Data transfer control

This service component contains the following groups of TMN management functions:

– Event reporting;

– Bulk record transfer;

– Log access.

8.2.2.1 Event reporting

These TMN functions control the generation and transmission of notifications from the NEF to the OSF.

8.2.2.1.1 Event forwarding discriminators

In addition to the notification control functions outlined in subclause 8.2.1, for short-term recording of specific events and for more complicated filter conditions the event forwarding discriminator construct defined in ITU-T X.734 [10] and ITU-T X.721 [5] shall be employed.

The event forwarding discriminator construct is extremely flexible permitting the combination of a number of fields and logical operations with a wide variety of scheduling options. The EFD also controls the destinations to which the event reports are sent. Several such filters may be defined and scheduled for operation at different times and for different time periods.

The following system management functions are required:

Create/Set/Get/Delete eventForwardingDiscriminator

8.2.2.1.2 Call event record reporting

This function permits the NEF to transmit a call or event record for a particular call attempt or event to the OSF. In general the record shall be sent on completion of the call or event. This function is controlled by means of the management functions described in subclause 8.2.1.1.

The following system management functions are required:

Notification callEventRecordReport

8.2.2.1.3 Emergency call reporting

This function permits the NEF to send a notification to an application entity within the OS whenever an emergency call is made within the network. The notification includes the IMEI (if available), the IMSI (if available) and the identity of the cell from which the call is made. This notification shall be sent during the emergency call set-up. The generation of this notification is controlled by means of the functions described in subclause 8.2.1.2.

The following system management functions are required:

Notification emergencyCallIndication

8.2.2.1.4 Observed IMEI ticket reporting

This function permits the NEF to send a notification to an application entity within the OS whenever an observed IMEI ticket is generated. The generation of this notification is controlled by means of the functions described in subclause 8.2.1.3.

The following system management functions are required:

Notification observedIMEITicketReport

8.2.2.2 Bulk record transfer

This group of TMN functions is concerned with the bulk transfer of call and event records from the NEF record filestore to the NEF.

The call and event records shall be transferred from the NEF to the OSF by the use of FTAM protocol on X.25 or TCP/IP, and FTP or TFTP over TCP/IP. For further details of the use of FTAM see GSM 12.01 [19] and of the use of FTP see [27] and TFTP see [28].

In addition to the simple file transfer services provided by FTAM, peer-to-peer application process communication may be also be supported. The use of CMIS services for the uploading of files from the NEF to the OSF is specified in GSM 12.00 [18].

8.2.2.3 Log access

This TMN function control the access to the log described in subclause 8.2.1.4. Each log defined may contain one or more log entries. Each log entry contains a single call/ event record, emergency call indication report or observed IMEI ticket report.

NOTE: The term log entry has been used instead of the term log record to avoid confusion between the records contained within the local filestore and the records stored within logs.

For further details concerning the use of logs see ITU-T X.735 [11].

The following system management functions are required:

Get/Delete callEventLogEntry

Get/Delete emergencyCallIndicationLogRecord

Get/Delete observedIEMITicketReportLogEntry

Annex A (normative):
Information model