Contents

1   Introduction

This document describes how to configure the service profile data 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 the MMTel Service Profile service, the Service Profile license must be installed.

For more information about the Service Profile license, refer to MTAS Licenses.

1.1.2   Documents

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

• Ericsson Command-Line Interface User Guide
• Managed Object Model (MOM)

1.1.3   Conditions

The following condition must apply:

An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.

2   Overview

The MMTel Service Profile service allows the operator to define different service profiles. A service profile is a template that lists a specific set of Supplementary Services that can be assigned to a group of subscribers. It is possible to define subscription packages for end users, for example: Gold, Silver, and Bronze, and then define the Supplementary Services included in each package as a service profile.

Each service profile is assigned with a Supplementary Service set that can be provisioned to a specific subscriber type. When a user activates a service, only the user-specific configuration information needs to be stored as transparent data in the Home Subscriber Server (HSS) for each subscriber. The overall service profile is still common for the subscription package.

The service profile data is obtained from the HSS when a user registers to the IMS system, and there is a service profile included in the subscriber data. That service profile is not already stored.

Notification of changes to a service profile is sent to the MTAS from the HSS.

The service information in a service profile is encoded according to a set of XML schemas similar to the XML schemas used for service data, except a reference to a service profile is not allowed in a service profile.

The MMTel service profile information consists of the transparent data (service data) which contains configuration for telephony services that can be shared by many subscribers.

The MTAS manages the service data for service profiles. When the first subscriber, that has an association to a service profile in the user data, is registered, the MTAS caches this service profile data and subscribes to notification of changes for this service profile.

The ordinary way of provisioning service to users in MTAS is by the User Documents (UD). The User Documents are XML documents containing service configuration for a single user. To make large scale provisioning easier and more efficient, the Service Profiles (SP) service is introduced. With the SP service, the provisioning of services can be done in one source, in the Service Profile. It is then possible to link to the user’s User Documents to get parts of their service provisioning from the Service Profile. The user gets a combination of the services provisioned in User Document and the Service Profile.

The user can have one or more user-specific services activated or deactivated in the User Document. Both the User Document and the Service Profile Document include two parts: User Part (UP) and the Operator Part (OP) as shown in Figure 1.

The User Part (UP) can be handled by both the user and the operator, but the Operator Part (OP) can only be handled by the operator. The arrow indicates that the User Document is linked to the Service Profile Document. The link in the User Document to the Service Profile can be removed or changed to another Service Profile.

2.1   Subfunctions

This section describes the subfunctions and examples of provisioning information included in the MMTel Service Profiles service.

2.1.1   Provisioning

Over the CAI3G interface, the User Document and the Service Profiles Document can be requested. The merged result is not possible to request. For more information on the result of a request, see Section 2.1.4 Overview of Setting Services in User Document or Service Profile.

2.1.1.1   Provisioning a Specific Service against a User

If a user wants a service which is not part of the Service Profile, the service can be added, activated, enabled, or disabled in the User Document.

Preconditions

The following preconditions apply:

• Active Service Profile license
• A CAI3G session exists.
• A link to service profile identity is included in the existing User Document.

  Contents of the User Document and Service Profile Document are shown in Figure 2.

  Note:  

  There are overlapping between the documents as the CDIV service is configured in the User Part of both documents. The chosen services represent only an example and the same scenario could be achieved with different service combinations.

  
  

Main Scenario

If a user wants a service which is not part of the Service Profile, the service can be added, activated, enabled, or disabled in the User Document as shown in Figure 3.

The user-specific service is merged into the resulting Effective Service Set shown in Figure 4. The Calling Name Identity Presentation (CNIP) service is originating from the User Document.

2.1.1.2   Provisioning in User Document Takes Precedence

In all cases, the services in the User Document (both User Part and Operator Part) have precedence over the same services in the Service Profile Document.

Preconditions

The following preconditions apply:

• Active Service Profile license
• A CAI3G session exists.
• A link to service profile identity is included in the existing User Document.

  Contents of the User Document and Service Profile Document are shown in Figure 5.

  Note:  

  There are overlapping between the documents as the Communication Diversion (CDIV) service is configured in the User Part of both documents.

  
  

  The Terminating Identity Restriction (TIR) service is configured in the Operator Part of both documents. Chosen services represent only the example and the same scenario could be achieved with different service combinations.

The services in the User Part of the Service Profile Document can be enabled or disabled to give the same settings to all users. In this case, all users with a link to the Service Profile have the CNIP service enabled.

Main Scenario

There are different scenarios where User Document and Service Profile Document are merged into Effective Service Set on service level. It happens in XDMS during provisioning activities and also in Subscriber Data subsystem for traffic use cases. However, in all cases the services in the User Document (both User Part and Operator Part) have precedence over same services in the Service Profile Document.

Fine grain merging is not supported, which means that all information in the User Part or Operator Part is taken from either the User Document or Service Profile. This means that the entire cdiv-user-configuration is taken from the User Document. No part of the cdiv-user-configuration from the Service Profile document is placed into the Effective Service Set. There is an exception in Common Data, where some elements are merged, refer to MTAS CAI3G Interface for more information.

The resulting Effective Service Set is shown in Figure 6.

The CNIP service is from the Service Profile Document and the TIR and Supplementary Service Codes (SSC) services are from the User Document. The CDIV in the Operator Part is from the Service Profile Document, but the CDIV in the User Part is from the User Document. It takes precedence over Service Profile Document settings.

2.1.1.3   Deactivate Service for a User

A service can be removed for a specific user by deactivating a service in the User Document. The User Configuration can be kept, but must be disabled. It is not possible to enable a service when the service is deactivated in the Operator Part of the User Document.

Preconditions

The following preconditions apply:

• Active Service Profile license
• A CAI3G session exists.
• A link to service profile identity is included in the existing User Document.

  Contents of User Document and Service Profile Document are shown in Figure 7.

  Note:  

  There are overlapping between the documents as the CDIV service is configured in the User Part of both documents and the CNIP service is activated and enabled in the Service Profiles Document.

  
  

Main Scenario

The CNIP service is deactivated in the User Document as shown in Figure 8.

The User Document takes precedence and the CNIP service is deactivated for the user as shown in Figure 9.

2.1.1.4   Reactivate Service to a User

A service can be reactivated for a specific user by removal of the deactivation of a service in the User Document.

Preconditions

The following preconditions apply:

• Active Service Profile license
• A CAI3G session exists.
• A link to service profile identity is included in the existing User Document.

  Contents of User Document and Service Profile Document are shown in Figure 10.

  Note:  

  There are overlapping between the documents as the CDIV service is configured in the User Part of both documents and the CNIP service is deactivated in the User Document and activated and enabled in the Service Profiles Document.

  
  

Main Scenario

The CNIP service is removed from the Operator Part in the User Document as shown in Figure 11.

The CNIP service is activated again for the user as shown in Figure 12.

2.1.1.5   Retain User Configuration for Service in User Document

If the operator wants to retain service data in the User Part of the User Document, it must be set to disabled. This means, that it is possible to reuse the User Configuration again if the service is activated later.

Preconditions

The following preconditions apply:

• Active Service Profile license
• A CAI3G session exists.
• A link to service profile identity is included in the existing User Document.

  Contents of User Document and Service Profile Document are shown in Figure 13.

  Note:  

  There are overlapping between the documents as CDIV service is configured in the User Part of both documents.

  
  

Main Scenario

The CDIV is disabled in the User Part and deactivated in the Operator Part of the User Document as shown in Figure 14.

The CDIV service is deactivated for the user as shown in Figure 15.

If the user wants the service again, the operator can remove the deactivation in the Operator Part and then enable CDIV again in the User part. For the result of these operations, see Figure 13.

2.1.2   Self-Administration

The user can enable and disable settings for services, which have User Part, over Ut and with SSC. The User Document is updated and stored in HSS and is specific for that user.

The following are described in this section:

• Self-administration over Ut
• Self-administration by SSC

2.1.2.1   Self-Administration over Ut

The user can handle the services that have the User Part in the User Document.

The following methods are supported over Ut:

• XCAP GET
• XCAP PUT

  Note:  

  XCAP PUT is supported per service. For example, a CDIV ruleset (a set of rules) can be updated, but not a specific rule. If a CDIV rule is requested to be updated, the request is rejected.

  
  
• XCAP DELETE

  Note:  

  XCAP DELETE is supported per service. For example, a CDIV ruleset (a set of rules) can be removed, but not a specific rule. If a CDIV rule is requested to be removed, the request is rejected.

  
  

When an XCAP GET or XCAP PUT is received, the User Document is fetched and if it is a link to a Service Profile, the Service Profile Document is fetched as well. They are merged into the Effective Service Set and the result of the User Part is responded.

For more information about how the Effective Service Set is created, see Section 2.1.1 Provisioning.

The Effective Service Set result depends on the User Document and the Service Profile Document, for more information, see Section 2.1.4 Overview of Setting Services in User Document or Service Profile.

2.1.2.2   Self-Administration by Supplementary Service Codes

The user can handle the services that have User Part in the User Document.

For more information about SSCs, refer to MTAS Supplementary Service Codes Management Guide.

For more information about how the Effective Service Set is created, see Section 2.1.1 Provisioning.

The Effective Service Set result depends on the User Document and the Service Profile Document, for more information, see Section 2.1.4 Overview of Setting Services in User Document or Service Profile.

2.1.3   Traffic Handling

Traffic handling and the behavior of the system in mutual exclusion are described and mutual dependencies are listed in User Configuration and Operator Configuration.

In traffic, the User Document and Service Profile Document are merged and the result, Effective Service Set, is used.

For more information about how the Effective Service Set is created, see Section 2.1.1 Provisioning.

The Effective Service Set result depends on the User Document and the Service Profile Document, for more information, see Section 2.1.4 Overview of Setting Services in User Document or Service Profile.

For more information about the Supplementary Service Codes (SSC), refer to MTAS Subscriber Data Management Guide.

When the Service Profile Document is updated and there are users linked to that Service Profile, several mutual exclusions in the User and Operator Configuration and mutual dependency can occur. For more information on mutual exclusion, see Section 2.1.3.1 Mutually Exclusive User Configuration and Section 2.1.3.2 Mutually Exclusive Operator Configuration.

2.1.3.1   Mutually Exclusive User Configuration

The mutual exclusion in User Configuration can happen after adding a User Part template to or modifying a User Part template in the Service Profile.

In Table 1, the first column represents what is stored in the User Configuration in the User document, the second column represents what is set in the User Configuration in the Service Profile Document, and the third column displays the result when someone calls the user.

2.1.3.2   Mutually Exclusive Operator Configuration

The mutual exclusion in Operator Configuration can happen after adding a service to Service Profile.

In Table 2, the first column represents what is stored in the Operator Configuration in the User document, the second column represents what is set in the Operator Configuration in the Service Profile Document, and the third column displays the result when someone calls the user.

(1)  The response depends upon the calling user, if the calling user does not answer, the result is CD with incomplete session.

2.1.3.3   Mutual Dependency Not Met

Lack of mutual dependency can happen after removing a service from the Service Profile.

In Table 3, the first column represents what is stored in the Operator Configuration in the User document, the second column represents what is set in the Operator Configuration in the Service Profile Document, and the third column displays the result when someone calls the user.

(1)  Provisioning is not possible.

2.1.4   Overview of Setting Services in User Document or Service Profile

Table 4 describes the result in the MTAS, when the User Document or Service Profile Document request is received:

• The UD includes a link to the Service Profile.
• The cells with text in Italic mean that the setting is not allowed and is rejected.
• When "(AC)" is stated, it means autocorrection, for more information, see Section 2.1.5 Autocorrection.

2.1.5   Autocorrection

When the Service Profiles are updated, the link in the User Document is changed or removed. This can generate a conflict in the User Document that is autocorrected when next CAI3G or Ut request is received.

Autocorrection compares the User Part of the User Document with the Operator Parts of the Service Profiles Document and User Document.

• If it detects user settings without corresponding Operator Part, then it is auto corrected. The autocorrection is done on service level which means that the service is deactivated in User Part of User Document.
• If it detects the same User Part in both Service Profiles Document and User Document, then it is auto corrected. The autocorrection means that the User Part is removed from User Document.

The User Document is autocorrected and then stored in HSS again.

2.2   Interaction with Other Services

The MMTel Service Profile service has no interaction with other services.

3   MMTel Service Profiles Configuration

The MMTel Service Profile service is triggered when the first subscriber who is associated to a specific service profile register in the IMS network. The service profile data is then fetched. The registered subscriber call case is determined by the port on which the SIP messages are received over the ISC interface. The main scenario can be broken down to the following four phases:

In the HSS the following must be done:

• The identity of the Service Profile must be added as a Public User Identity.
• The service profile indication ID (ServiceIndicationId) in LDAP must be added or the HSS rejects the CAI3G provisioning, see Example 1

HSS-ServiceIndicationId=MmtServiceProfileConfig, 
HSS-ServiceIndicationContainerName=HSS-ServiceIndication,
HSS-ConfigurationContainerName=HSS-ConfigurationContainer,
applicationName=HSS,nodeName=jambala

For more information about service profile administration in the HSS, refer to MTAS External Network Configuration.

3.1   Create Service Profiles

The following is an example of how to create a service profile named "silver" with two services provisioned:

<soap-env:Envelope>
	<soap-env:Header>
		<cai3g:SessionId>S1</cai3g:SessionId>
		<cai3g:TransactionId>1</cai3g:TransactionId>
		<cai3g:SequenceId>100</cai3g:SequenceId>
	</soap-env:Header>
	<soap-env:Body> 
		<cai3g:Create>
			<cai3g:MOType>MMTelProfile@http://schemas.ericsson.com/mtas/mmtel/cai3g</cai3g:MOType>
			<cai3g:MOId>
				<mc:publicId>sip:silver@telco.com</mc:publicId>
			</cai3g:MOId>
			<cai3g:MOAttributes>
				<mc:createMMTelProfile publicId="sip:silver@telco.com">
					<mc:publicId>sip:silver@telco.com</mc:publicId>
										
					<mc:conference>
						<mc:conf-operator-configuration>
							<mc:activated>true</mc:activated>
							<mc:max-number-of-parties>16</mc:max-number-of-parties>
						</mc:conf-operator-configuration>
					</mc:conference>
					
					<mc:terminating-identity-presentation-restriction>
						<mc:tir-operator-configuration>
							<mc:activated>true</mc:activated>
							<mc:mode>temporary</mc:mode>
						</mc:tir-operator-configuration>
						<mc:tir-user-configuration>
							<mc:active>true</mc:active>
							<mc:default-behaviour>presentation-restricted</mc:default-behaviour>
						</mc:tir-user-configuration>
					</mc:terminating-identity-presentation-restriction>
					
				</mc:createMMTelProfile>		
			</cai3g:MOAttributes>			
		</cai3g:Create>
	</soap-env:Body>
</soap-env:Envelope>

3.2   Set User to Use Service Profiles

The following is an example of how to set a user to use a service profile named "silver":

<soapenv:Envelope>
   <soapenv:Header>
      <cai3g:SessionId>A192D168D83D100Z1333097024S21P65537</cai3g:SessionId>
      <cai3g:TransactionId>111111</cai3g:TransactionId>
      <cai3g:SequenceId>2044962558</cai3g:SequenceId>
   </soapenv:Header>
   <soapenv:Body>
      <cai3g:Set>
         <cai3g:MOType>MMTel@http://schemas.ericsson.com/mtas/mmtel/cai3g</cai3g:MOType>
         <cai3g:MOId><mc:publicId>sip:user@ericsson.com</mc:publicId></cai3g:MOId>
         <cai3g:MOAttributes>
         <mc:setMMTel publicId="sip:user@ericsson.com">
            <mc:concurrency-control>1</mc:concurrency-control>

            <mc:common-data>
               <mc:service-profile-identity>sip:silver@telco.com</mc:service-profile-identity>
            </mc:common-data>

         </mc:setMMTel>
         </cai3g:MOAttributes>
      </cai3g:Set>
   </soapenv:Body>
</soapenv:Envelope>

3.3   Service Data Configuration

This section describes how to configure the service data.

3.3.1   Operator Subscription Level Service Configuration

The function implemented is subscriber data management for a service profile. Each service profile has a single identity. MTAS caches one set of transparent data per service profile. For Normal Registration Mode, the MTAS fetches and caches the service profile transparent data (service profile data) when the first user that is associated to that service profile is registered.

In the Service Profile configuration data for a subscriber the operator indicates whether the subscriber is allowed to initiate Service Profile through the CAI3G protocol, refer to MTAS CAI3G Interfacefor more information.

3.3.2   Subscriber Subscription Level Service Configuration

No service data for the MMTel Service Profile service is configured in the subscriber part of the subscriber data.

4   Performance Management

The MMTel Service Profile service has no separate measurements. However, counters connected to the MtasShInterface MO can be stepped.

For measurements related to the MtasShInterface MO, refer to Managed Object Model (MOM).

5   Fault Management

For alarms related to the MMTel Service Profile service, refer to MTAS Alarm List.