MTAS Distinctive Ring Management Guide
MTAS

Contents

1Introduction
1.1Prerequisites

2
Overview
2.1Subfunctions
2.2Interaction with Other Services

3
DR Service Configuration
3.1Distinctive Ring Administrative State Configuration
3.2Service Data Configuration
3.3XML Example

4
Performance Management

5
Fault Management

1   Introduction

This document describes how to configure the Distinctive Ring (DR) service in the MTAS.

1.1   Prerequisites

It is assumed that the user of this document is familiar with the Operation and Maintenance (O&M) area, in general.

1.1.1   Licenses

To enable the DR service, the DR license must be installed.

For more information about the DR license, 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

This document describes the DR service that the MTAS offers to its subscribers.

The DR service is a rule-based terminating service that allows a served user to specify different ringtones for its IP Multimedia Public Identities (IMPUs) that are in the same Implicit Registration Set (IRS).

DR determines to include the appropriate Alert-Info header field in an INVITE request when an incoming call is made to the user by evaluating DR rules.

The rules are built up with mmt-serv:served-identity (called identity of the user if the MTAS is terminating) conditions, and mmt-serv:alert-info actions.

The mmt-serv:served-identity condition is evaluated to true when the Request-URI of the received INVITE matches the value of the served-identity element.

The mmt-serv:alert-info action contains a free text that is used for looking up the Alert-Info header field value from the MtasDrAlertInfo Managed Object (MO).

DR enables the operator to allow its subscribers to use their customized ringtone. If the user customized ringtone is not allowed, subscribers can only configure ringtones predefined by the operator.

The User Equipment (UE) generates the proper ringtone or call waiting tone, based on the call state, and the value of the Alert-Info header populated by the terminating MTAS.

The DR service is provisioned through XDMS over the Customer Administration Interface Third Generation (CAI3G). The configuration of the DR service is done through XDMS on the Ut or CAI3G. The service-specific data is stored as transparent data in Home Subscriber Server (HSS) over the Sh interface. MTAS reads the service data from the HSS on the same interface.

2.1   Subfunctions

The subfunctions included in the DR service are described in this section.

2.1.1   DR Service without User-Defined Ringtone

The DR Service without User-Defined Ringtone subfunction is responsible for adding the appropriate Alert-Info header field to the outgoing INVITE request. Alert-Info header field value is specified in a predefined mapping table (MtasDrAlertInfo MO).

2.1.2   DR Service with User-Defined Ringtone

The DR Service with User-Defined Ringtone subfunction is responsible for adding the appropriate Alert-Info header field to the outgoing INVITE request. Alert-Info header field value is specified in the XML data of the served user.

2.1.3   Manage Subscription Data

The Manage Subscription Data use case describes how the per-subscriber data is created, updated, and deleted. It uses the Get Subscription Data and Update Subscription Data subfunctions. For more details on how to manage the subscription data, refer to MTAS CAI3G Interface.

2.1.4   Configure Service (Node Level)

The Configure Service (node level) use case is the CM part, see Section 3.

2.1.5   Licensing

The MTAS has on and off licensing for the DR Service. If no valid license is available for DR, then the DR service is not executed. No modification is made on the received INVITE request by the DR service, for instance, if the received INVITE request already contains an Alert-Info header field, then it is not changed by the DR service. When the DR license has expired, or when the DR function is turned on and no valid license exists, an alarm is raised. For more detailed information, refer to Diameter Offline Charging in MTAS

2.2   Interaction with Other Services

This section describes how the DR service interacts with other services.

2.2.1   Charging

The use of DR service is reported in charging messages generated during the setup of an MMTel session.

Charging events are also raised when the DR subscriber activates or deactivates the DR Service using the Ut interface.

For details on how the use of DR is reported for offline charging and online charging, refer to the following documents:

2.2.2   Communication Waiting

The UE is responsible for playing the appropriate call waiting tone based on the call state and the value of the received Alert-Info header field present in the INVITE request.

3   DR Service Configuration

The DR service is controlled by the MtasDr MO. An overview of the DR MO structure is shown in Figure 1.

Figure 1   DR MO Structure

For configurable MOs and attributes related to general DR configuration, refer to Managed Object Model (MOM)

3.1   Distinctive Ring Administrative State Configuration

The DR service is enabled by setting the mtasDrAdministrativeState attribute in the MtasDr MO to 1 (Unlocked). If the mtasDrAdministrativeState is set to 0 (Locked), no DR service is provided by the MTAS.

3.2   Service Data Configuration

This section describes how to configure the service data.

3.2.1   Operator Subscription Level Service Configuration

The operator can activate or deactivate the DR service subscription for the subscriber, by providing or deleting the DR XML structure in the user subscriber data.

For more information about schema definition, refer to MTAS CAI3G Interface.

3.2.2   Subscriber Subscription Level Service Configuration

The user subscriber data is configured through the Ut interface using the XDMS.

The Ut interface and the XML schema for the Ut interface are described in MTAS Ut Interface and MTAS Ut Structure.

3.3   XML Example

A Sh example is shown in Example 1.

Example 1   Sh Example

	<RepositoryData>
		<ServiceIndication>MmtServiceConfig</ServiceIndication>
		<SequenceNumber>0</SequenceNumber>
		<ServiceData>
			<mmt-data:telephony-service-configuration 
			xmlns:cp="urn:ietf:params:xml:ns:common-policy"
			xmlns:mmt-data="http://schemas.ericsson.com/mmtel/service-data" 
			xmlns:mmt-op="http://schemas.ericsson.com/mmtel/operator-service-data"
			xmlns:mmt-serv="http://schemas.ericsson.com/mmtel/services"
			xmlns:ocp="urn:oma:xml:xdm:common-policy"
			xmlns:ss="http://uri.etsi.org/ngn/params/xml/simservs/xcap">
				<mmt-data:user-configuration>
					<ss:simservs>

						<mmt-serv:distinctive-ring active="true">
							<cp:ruleset>
								<cp:rule id="distinctive-ring-primary-number">
									<cp:conditions>
										<mmt-serv:served-identity>
											<mmt-serv:one id="tel:+36306435420"/>
										</mmt-serv:served-identity>
									</cp:conditions>
									<cp:actions>
										<mmt-serv:alert-info>normalBeep</mmt-serv:alert-info>
									</cp:actions>
								</cp:rule>
								<cp:rule id="distinctive-ring-virtual-number1">
									<cp:conditions>
										<mmt-serv:served-identity>
											<mmt-serv:one id="sip:my-son@ericsson.com"/>
										</mmt-serv:served-identity>
									</cp:conditions>
									<cp:actions>
										<mmt-serv:alert-info>longBeep</mmt-serv:alert-info>
									</cp:actions>
								</cp:rule>
								<cp:rule id="distinctive-ring-virtual-number2">
									<cp:conditions>
										<mmt-serv:served-identity>
											<mmt-serv:one id="sip:my-wife@ericsson.com"/>
										</mmt-serv:served-identity>
									</cp:conditions>
									<cp:actions>
										<mmt-serv:alert-info>shortBeep</mmt-serv:alert-info>
									</cp:actions>
								</cp:rule>
								<cp:rule id="distinctive-ring-virtual-number3">
									<cp:conditions>
										<mmt-serv:served-identity>
											<mmt-serv:one id="tel:+36306435421"/>
										</mmt-serv:served-identity>
									</cp:conditions>
									<cp:actions>
										<mmt-serv:alert-info>dst_ring_4</mmt-serv:alert-info>
									</cp:actions>
								</cp:rule>
								<cp:rule id="distinctive-ring-virtual-number4-customized">
									<cp:conditions>
										<mmt-serv:served-identity>
											<mmt-serv:one id="tel:+36306435422"/>
										</mmt-serv:served-identity>
									</cp:conditions>
									<cp:actions>
										<mmt-serv:alert-info>http://127.0.0.1/nortel/dst_ring_5</mmt-serv:alert-info>
									</cp:actions>
								</cp:rule>	
							</cp:ruleset>
						</mmt-serv:distinctive-ring>

					</ss:simservs>
				</mmt-data:user-configuration>
				<mmt-data:operator-configuration>
					<mmt-data:operator-service-data>
						<mmt-op:operator-distinctive-ring  activated="true"/>
					</mmt-data:operator-service-data>
				</mmt-data:operator-configuration>
			</mmt-data:telephony-service-configuration>
		</ServiceData>
	</RepositoryData>
</Sh-Data>

4   Performance Management

For measurements related to the DR service, refer to Managed Object Model (MOM).

5   Fault Management

For alarms related to the DR service, refer to MTAS Alarm List.



Copyright

© Ericsson AB 2016. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.

    MTAS Distinctive Ring Management Guide         MTAS