MTAS Communication Event Logging Management Guide
MTAS

Contents

1Introduction
1.1Prerequisites

2

Overview
2.1License Control
2.2List of Subfunctions
2.3CEL Interaction with Other Services
2.4Traffic View
2.5Configuration View

3

Operator Service Data Configuration

4

CEL Service Configuration
4.1Configuration Activities
4.2CEL Administrative State Configuration
4.3Wholesale for CEL Configuration
4.4Service Data Management

5

Performance Management

6

Fault Management

7

Example Configuration
7.1CEL Operator Provisioning Examples

1   Introduction

This document describes how to configure Communication Event Logging (CEL) service in the MTAS.

1.1   Prerequisites

It is assumed that the user of this document is familiar with the O&M area, in general.

1.1.1   Licenses

To enable basic services in the MTAS, the MMTel AS Voice Base license must be installed.

For more information about the MTAS licenses, refer to MTAS Licenses.

1.1.2   Documents

Before starting any procedure in this document, ensure that the following documents are available:

1.1.3   Conditions

The following condition must apply:

2   Overview

Communication Event Logging (CEL) is an Rf-based originating MMTel AS service, sending notifications about served user session communication to an external server based on evaluation of operator provisioned service data and CM configurations.

The main use cases of this function are:

CEL service can be activated independent of activation state of Rf offline charging. The function is executed only at the originating MTAS.

Communication events are sent to the external logging server whenever there is a communication attempt from or towards the served user. The event includes information about type of session state event, time, calling party, called party, subscription information, and so on.

Based on the event type provisioned by the operator for the served user and actual call state during a call, the CEL service decides whether an event is to be reported or not. The event type can be unsuccessful-attempt, established, or both.

The operator can provision the CEL service for the served user as follows:

The use case Configure Service is the CM part of CEL, described in Section 4.1 Configuration Activities.

2.1   License Control

There is no license needed to enable the CEL service and to evaluate conditions in operator rules. However, to enable basic services in the MTAS, the MMTel AS Voice Base license must be installed. For more information about the MTAS licenses, refer to MTAS Licenses.

2.2   List of Subfunctions

2.2.1   Manage Subscription Data

This subfunction evaluates the serving operator's CEL provisioning for the served user. It uses the subfunctions Get Subscription Data and Update Subscription Data. For more information, see Section 4.4 Service Data Management.

2.2.2   CEL Provisioning

This is a use case that evaluates the serving operator’s CEL provisioning for the served user.

XML elements:

2.2.3   Configure Service

This subfunction is the CM part of the CEL service. See Section 4.1 Configuration Activities.

2.2.4   Update PM Counter

CEL updates specific PM counters which reflect successful and unsuccessful invocations. Refer to MTAS Performance Measurements.

2.3   CEL Interaction with Other Services

The CEL interaction with other MTAS services is described in this section.

2.3.1   Charging

The CEL service reports events when online or offline charging is enabled for the served user. If no charging is enabled, CEL service does not report the events.

For more information about the Charging service, refer to Diameter Offline Charging in MTAS and Diameter Online Charging in MTAS.

2.3.2   OCT

CEL service does not report OCT retargeting, that is, following redirect from OT.

For more information about the OCT service, refer to MTAS Operator Controlled Transfer Management Guide.

2.3.3   Ad-Hoc Conference

CEL service reports event for only CC Creator, events on CC Participant are not reported.

For more information about the conference service, refer to MTAS Ad-hoc Conference Management Guide.

2.4   Traffic View

CEL performs the following steps:

  1. Service invocation; an event triggers the execution of CEL, for example, an incoming INVITE.
  2. Event Reporting; CEL evaluates the served user’s configured events and CM configurations, and determines if the communication event logging is to be reported or not.

Service invocation is described in Section 4 CEL Service Configuration, Event evaluation in Section 3 Operator Service Data Configuration, and CM configurations in the respective subfunction description and in the detailed description for reporting CEL event.

Traffic view of CEL is shown Figure 1. The different subfunctions of CEL are triggered by the incoming INVITE.

Figure 1   Traffic View from CEL

CEL service fetches the provisioning data from the HSS through Sh, and available CM configurations from OAM and then evaluates the event. It determines if the communication event logging is to be reported or not.

If the event is to be reported, then the configured CEL server name is used for the interaction with the communication Event Server, which is controlled by CEL through the ISC interface.

2.5   Configuration View

Node level configuration is performed by the operator through OAM. This includes locking or unlocking CEL and operator-specific events. For example, by defining the event for "established", which specifies that event to be reported for established calls.

Figure 2   Configuration View of CEL

Operator configurations are managed through XDMS, that provides the CAI3G interface to the operator.

XDMS uses the Sh (Diameter) interface to update the HSS.

3   Operator Service Data Configuration

The operator can activate or deactivate the CEL service subscription for the subscriber by providing or removing the CEL XML structure in the operator's Subscriber Data. This is defined by a schema and follows the structure illustrated in Figure 3.

Figure 3   CEL Operator Event Elements

The top-level CEL element has a Boolean attribute active. If active=true, then the event elements are evaluated.

Operator Service Data with CEL:

If the CEL service is active, then CEL reads the provisioned data and compares the provisioned event value with the actual call state.

If there are no matching event elements, then no event is reported to the Event Server and the call setup continues.

4   CEL Service Configuration

The CEL function of the MTAS is controlled by the MtasCel Managed Object Class (MOC).

The structure of CEL MOC is shown in Figure 4.

Figure 4   Communication Event Logging MOC

For configurable Managed Objects (MOs) attributes related to the CEL service, refer to Managed Object Model (MOM).

4.1   Configuration Activities

Configuration activities are listed in Table 1.

Table 1    Configuration Activities

Activity

Attribute

Comment

Defining when a PUBLISH is to be sent for an established or failed call based on SSID

mtasCelReportingFilterList

If the filter list is empty, it reports all events.

Defining SIP header with regex pattern to report communication event for the served user if its configured header matches INVITE

mtasCelReportingHeaderFilter

If header filter is empty, it reports all events and no header filtering.

Defining the PUBLISH R-URI with the URI of the Event ServerI

mtasCelEventServerName

 

4.2   CEL Administrative State Configuration

The CEL service is enabled by setting the mtasCelAdministrativeState attribute in the MtasCel MO to 1 (UNLOCKED). If the mtasCelAdministrativeState is set to 0 (LOCKED), no CEL service is provided by the MTAS.

4.3   Wholesale for CEL Configuration

The CEL service supports Wholesale. CEL is configurable on Virtual Telephony Provider level.

Wholesale for CEL is activated when the following attributes are set to 1 (UNLOCKED):

For more information about the Wholesale service, refer to MTAS Wholesale Support Management Guide.

4.4   Service Data Management

This section describes how to configure the service data.

4.4.1   Operator Subscription Level Service Configuration

The operator can activate or deactivate the CEL service subscription for the subscriber by providing or removing the CEL XML structure in the operator’s Subscriber Data.

For more information about the CAI3G protocol and XML Schema Definition, refer to MTAS CAI3G Interface.

4.4.2   Subscriber Subscription Level Service Configuration

There is no subscriber subscription level service configuration (Ut interface) defined for the CEL service.

5   Performance Management

For performance measurements related to the CEL service, refer to MTAS Performance Measurements.

6   Fault Management

The CEL service has no alarms.

7   Example Configuration

7.1   CEL Operator Provisioning Examples

This section provides some examples to illustrate provisioning of events.

To guarantee its uniqueness, a namespace is often a long unwieldy string. XML allows a namespace to be mapped to a short string (a prefix), which makes XML documents more readable. Table 2 shows the mapping between each namespace and its assigned prefix as used in this section.

Table 2    Namespace Prefix Mapping

Prefix

Namespace

Purpose

mmt-op

http://schemas.ericsson.com/mmtel/operator-service-data

Operator Part of the MMTel document

7.1.1   Report PUBLISH with XML Based on Type of Events Configured

The following example is for an originating call, when the operator has provisioned the served user with the "established" event type and the call is established successfully. The event type is evaluated by CEL with current call state established. As a match is found, PUBLISH with a call-event-info header and XML is sent to communication event server.

<mmt-data:operator-configuration>
   <mmt-data:operator-service-data>
      <mmt-op:operator-communication-event-logging activated='true'>
         <mmt-op:events>
            <mmt-op:unsuccessful-attempt />
            <mmt-op:established />
         </mmt-op:events>
      </mmt-op:operator-communication-event-logging>
   </mmt-data:operator-service-data>
</mmt-data:operator-configuration>

Publish with XML:

   

PUBLISH sip:igw.abc.com SIP/2.0 
Via: SIP/2.0/TCP 192.168.83.100:5082;branch=z9hG4bK3492325595-787322098 
Max-Forwards: 70 
Allow: INVITE, BYE, CANCEL, ACK, INFO, PRACK, COMET, OPTIONS, SUBSCRIBE, NOTIFY, ⇒
 MESSAGE, REFER, REGISTER, UPDATE 
From: tel:+19169032537;tag=p65537t1542622597m320973c291s1_3492323235-216465919 
To: sip:igw.abc.com 
Call-ID: p65537t1542622597m320973c291s2 
CSeq: 1 PUBLISH 
Contact: <sip:p65537t1542622597m320973c291s1@192.168.83.100:5082;transport=udp> 
Expires: 0 
Event: call-event-info 
Content-Type: application/call-event-info+xml 
User-Agent: Ericsson MTAS - CXP2010134/1 R88X01 
Content-Length: 987
<?xml version="1.0" encoding="UTF-8"?> 
<communication-event-info xmlns="urn:ericsson:params:xml:ns:call-event-info"> 
   <Session-State-Event>ESTABLISHED</Session-State-Event> 
   <IMS-Charging-Identifier>1391809860</IMS-Charging-Identifier> 
   <SIP-Request-Timestamp>20181119T101637718</SIP-Request-Timestamp> 
   <SIP-Response-Timestamp>20181119T101640889</SIP-Response-Timestamp> 
   <Called-Party-Address>tel:+42312005755</Called-Party-Address> 
   <Calling-Party-Address>tel:+19169032537</Calling-Party-Address> 
   <Analyzed-Call-Type>local</Analyzed-Call-Type> 
   <Role-Of-Node>outgoing</Role-Of-Node> 
   <Subscription-Id-Group> 
      <Subscription-Id-Data>46123456</Subscription-Id-Data> 
      <Subscription-Id-Type>E164</Subscription-Id-Type> 
   </Subscription-Id-Group> 
   <Supplementary-Service-Identity-List> 
      <Supplementary-Service-Identity>5400</Supplementary-Service-Identity> 
   </Supplementary-Service-Identity-List> 
</communication-event-info>