MTAS Wholesale Support Management Guide

MTAS

1	Introduction
1.1	Prerequisites
2	Overview
2.1	Subfunctions
2.2	Wholesale Interaction with Other Services
3	Wholesale Configuration
3.1	Wholesale Administrative State Configuration
3.2	Overview Tables and Activation for VTP-Controled Dial Plan
3.3	VTP-Controled Dial Plan Configuration
3.4	Service Data Configuration
3.5	Announcement Configuration
4	Performance Management
5	Fault Management

1 Introduction

This document describes how to configure the Wholesale 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 Wholesale in the MTAS, the Wholesale license must be installed.

For more information about licensing, refer to the following document:MTAS Licenses

1.1.2 Documents

Before any of the procedures in this document are done, the following documents must be read and understood:

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 Wholesale service is the process by which an organization owns and operates a telephony network and sells capacity to other operators which do not own and operate their own networks. Both the organization that owns and operates the network, the Operating Telephony Provider (OTP), and their wholesale customers, the Virtual Telephony Providers (VTP), sell services to end users.

The MTAS supports Wholesale by allowing the OTP to specify a set of VTPs, allowing each VTP to configure almost every aspect of the MTAS service for their users, and determining which VTP a user belongs to.

The main use cases for this function are as follows:

Service use by VTP user
Configure VTP service on node-level

The Wholesale service allows each VTP to configure each MTAS service, and the MTAS applies those values when the service is provided to members of that VTP. This is achieved by having a copy of most of the Managed Object Model (MOM) per-VTP.

The OTP remains in control of which services that are provided by the MTAS, since the OTP administrative state attribute associated with each service takes precedence over the corresponding VTP administrative state attribute. The OTP configuration of a service is the basis for all VTP configurations for that service. If any changes are made to the OTP configuration, the services of the VTPs can be affected.

The following node configuration MOCs are used for common functions within the MTAS and can therefore only be configured in an OTP configuration:

MtasMrf
MtasSip
MtasXdms
MtasShIf
MtasCcm
MtasComDetails
MtasLi
MtasDnm
MtasParlayX
MtasNcc
MtasCsi
MtasSegmentedAnnouncements
MtasCommonData

An operator that is already using MTAS must do a migration of the existing CM data, when becoming an OTP. The reason for this being that the operator must separate the OTP and VTP settings for its existing users.

The OTP controlled per VTP Dial Plan allows the operator to specify all the addresses that can be reached by the end users belonging to each VTP. For more information about the VTP Dial Plan, refer to MTAS Barring and Dial Plan Services Management Guide.

Each VTP can choose, for each service, to use the OTP values for the attributes rather than configure the service itself.

The VTP operator is intended to have read-only access for the OTP MO attribute and read-write access for the own VTP MO attributes. In addition, all the drop back attributes in the MOM are intended to be read-only to the VTP but read-write to the OTP.

Each VTP is associated with a set of domains. A served user is deemed to be a member of a VTP if the host part of its primary Public User Identity (PUI) (the first entry in the Implicit Registration Set (IRS) of the user) is one of the domains associated with that VTP.

Any user not associated with any VTP is treated as a user of the OTP, and the OTP attribute values apply.

2.1 Subfunctions

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

2.1.1 Service Use by VTP User

When a served user, associated with a VTP, is involved in a session, the services it receives are determined by the provisioning data fetched from the Home Subscriber Server (HSS), and the node level service data configured by the VTP.

2.1.1.1 Preconditions

The following preconditions must be fulfilled:

The mtasFunctionVtpAdministrativeState is set to 1 (Unlocked).
There is a valid Wholesale license installed and activated on the MTAS.
The served user belongs to a VTP.
The mtasVtpAdministrativeState is set to 1 (Unlocked) for this VTP

2.1.1.2 Main Scenario

For each service Xxx provisioned for the user, the service behaves according to the values in the attributes of VtasXxx and its subordinate Managed Object Classes (MOCs), rather than the attributes of MtasXxx and its subordinate MOCs, unless the attribute VtasXxxDropBack is set to 1 (use OTP values), in which case the values in the attributes of MtasXxx and its subordinate MOCs apply.

2.1.1.2.1 Administrative State Attributes

The attributes mtasXxxAdminstrativeState, vtasXxxAdministrativeState, mtasYyyAdminState, and vtasYyyAdminState have special treatment.

If mtasXxxAdministrativeState is set to 0 (Locked), then the service Xxx is locked for all users. If mtasXxxAdministrativeState is set to 1 (Unlocked), then the service is available for all users that do not belong to a VTP, and for users that belong to a VTP, the availability of the service depends on the value of vtasXxxAdministrativeState.

Similarly for mtasYyyAdminState and vtasYyyAdminState.

2.1.1.2.2 Drop Back Attributes in Subordinate MOCs

Some services are configured by subtrees of MOCs. Each system-created subordinate MOC VtasXxx below VtasServices contains a vtasXxxDropBack attribute. When vtasXxxDropBack is set to 1 (use OTP values), the values of the attributes in MtasXxx apply. This option applies to all levels of system-created subordinate MOCs below MtasVtp.

User-created subordinate MOCs do not contain a drop back attribute. The drop back attribute of the parent system-created MOC applies to the user-created MOCs.

2.1.2 Determine Owning VTP

This subfunction works out which VTP, if any, the served user belongs to.

2.1.2.1 Preconditions

The following preconditions need to fulfill:

The mtasFunctionVtpAdministrativeState is set to 1 (Unlocked).
A valid Wholesale license is installed and activated.

2.1.2.2 Main Scenario

The MTAS uses the data in mtasVtpDomain to determine which VTP the served user belongs to. The MTAS extracts the host part from the first PUI in the served IRS of the users, and searches the data for the VTP that is mapped to that domain.

The MTAS checks if mtasVtpAdministrativeState is set to 1 (Unlocked) for this VTP.

2.1.3 Provision Service Data

When an O&M operator provisions the service data for a served user associated with a VTP, the values allowed in the service data are constrained to match the node level service data configured by the VTP.

2.1.4 Update Service Data

When a served user, associated with a VTP, provisions its service data, the values allowed in the service data are constrained to match the node level service data configured by the VTP. For example, when a user that is associated with a VTP provisions a diversion, the diverted to number is validated against both OTP and VTP Global blacklists.

2.1.5 Configure VTP Service on Node Level

The O&M operator can configure the OTP MOCs and their per-VTP replication.

2.1.5.1 Main Scenario

The operator can create and delete per-VTP MOCs and read and change attributes in those per-VTP MOCs in the same way that the operator can perform those operations on the OTP MOCs and attributes.

2.1.5.1.1 Drop Back Attributes

When a drop back attribute vtasXxxDropBack in MOC VtasXxx is changed from 1 (use OTP data) to 0 (use own data), the MTAS copies the values from the corresponding attributes mtasXxxAttr in OTP MOC MtasXxx into the attributes VtasXxxAttr, except any attribute containing administrative state. If MtasXxx contains any user-created MO Instances, the MTAS creates copies of those user-created MO Instances in the corresponding user-created MO Instances within VtasXxx.

When a drop back attribute vtasXxxDropBack is changed from 0 (use own data) to 1 (use OTP data), the MTAS deletes any user-created MO Instances contained within VtasXxx.

For more detailed information, refer to Managed Object Model (MOM).

2.1.5.1.2 Restrict Changes

As described in Section 2.1.5.1.1 Drop Back Attributes, when a per-VTP MOC is switched to be used, by setting the drop back attribute to 0 (use own data), all the attributes are overwritten with the values from the corresponding OTP MOC. To avoid an operator wasting time changing data that is discarded, the operator is not allowed to change any attribute in a system-created per-VTP MOC while the drop back attribute is set to 1 (use OTP data), and the operator is not allowed to create any user-created per-VTP MO Instance while the drop back attribute in the nearest system-created parent MOC is set to 1 (use OTP data).

The operator is not allowed to change a drop back attribute vtasXxxDropBack from 0 (use own data) to 1 (use OTP data), if any user created MO instance contained within VtasXxx is used in another MO instance. For example, if the VTP operator has defined a VTP-specific Generic Announcement, and this announcement is used in another VTP-specific MO instance, then it is not possible to set the vtasGaDropBack attribute to 1 for Generic Announcement.

If two VTP MOCs have a dependency including a condition that must be fulfilled, and enabling drop back on one of the MOCs makes this condition untrue, then in this case the operator is not allowed to enable drop back.

2.1.5.1.3 Dependencies

The MTAS imposes dependencies between two attributes when either attribute is changed.

Generally, the dependencies for an attribute in a per-VTP MOC are the same as the dependencies for the corresponding OTP attribute, except that the dependencies are primarily with another per-VTP attribute. However, when the related attributes are in different MOCs, and when drop back is considered, the pattern as shown in Figure 1 applies:

Figure 1 Dependencies and Drop Back

Only the checks that are made when an attribute in MOC X is changed, are considered in Figure 1.

The existing dependency from MOC X to MOC Y in the OTP continues to be enforced, as represented by arrow 1 in Figure 1. For example, if MOC X has a timer attribute t1, and MOC Y has a timer attribute t2, and there is a condition that (t1 >= t2) must always be true. This condition is used in the following examples as well. When t1 in MOC X is changed, then t2 in MOC Y is used to verify that the condition is still true.

When the per-VTP instances of both MOCs apply, the dependency MOC X to MOC Y in the VTP is enforced, as represented by arrow 2 in Figure 1. For example, if the VTP named "A" is using VTP-specific configurations for both MOC X (XA) and MOC Y (YA). When t1 in XA is changed then t2 in YA is used to verify that the condition is still true.

When the per-VTP instance of MOC X applies, but MOC Y is dropped back to the OTP, the dependency from MOC X in the VTP to MOC Y in the OTP is enforced, as represented by arrow 3 in Figure 1. For example, if the VTP named "A" is using VTP-specific configurations for MOC X (XA) but the OTP configuration for MOC Y. When t1 in XA is changed, then t2 in Y must be used to verify that the condition is still true.

When MOC X is dropped back to the OTP, but the per-VTP instance of MOC Y applies, the dependency X in the OTP to MOC Y in the VTP is enforced, as represented by arrow 4 in Figure 1. When the attribute in MOC X is changed in the OTP, the MTAS enforces the dependency to the attribute MOC Y in the OTP and the dependency to MOC Y in every VTP where X is dropped back to the OTP. For example, if the VTP named "A" is using the OTP configuration for MOC X but a VTP-specific configuration for MOC Y (YA). When t1 in A is changed the following applies:

t2 in YA must be used to verify that the condition is still true.
t2 in Y must also be used to verify that the condition is still true, owing to the enforced dependency to MOC Y in the OTP.
If, in addition to VTP "A", there also is a VTP named "B" that is using the OTP configuration for MOC X, but a VTP-specific configuration for MOC Y (YB), then the t2 attribute in YB also need to check to verify that the condition is still true.

For more detailed information, refer to Managed Object Model (MOM)

2.2 Wholesale Interaction with Other Services

The Wholesale service has no interaction with other services.

3 Wholesale Configuration

The MO structure of the Wholesale service is illustrated in Figure 2. The MtasVtp MO is the child to the MtasFunction MO. The MtasVtp MO contains attributes that control the Wholesale service. If no valid Wholesale license exists, it is not possible to create or change any per-VTP MOC instances.

Figure 2 Wholesale MO Structure

Each MO instance in the structure is identified by its Distinguished Name (DN). This process makes it possible to separate MOs for different VTPs. For example, an MTAS node is named "MTAS-1" and there is a VTP named "A". This VTP has defined a Generic Announcement named "GA-1". The DN of this announcement is as follows:

VtasGaAnn=GA-1, VtasGA=0, VtasMmt=0, VtasServices=0, MtasVtp=A, applicationName=MtasFunction, nodeName=MTAS-1

3.1 Wholesale Administrative State Configuration

To enable Wholesale on the MTAS, set the following attributes to 1 (Unlocked):

mtasFunctionVtpAdministrativeState in the MtasFunction MO
mtasVtpAdministrativeState in the MtasVtp MO

The mtasFunctionVtpAdministrativeState attribute enables the support for VTPs in the MTAS and the mtasVtpAdministrativeState attribute is used to activate or deactivate a VTP.

3.2 Overview Tables and Activation for VTP-Controled Dial Plan

This section describes the general knowledge needed for handling and activation of tables needed for configuration of the VTP-Controled Dial Plan.

3.2.1 View Selection and Editing Standby Tables

In the CM browser, the MTAS offers one active and one standby view. The same MO attribute is used to display both the active and the standby table. By default the active table is presented.

The view can be changed at any time in the CM browser using the attribute xView, where x is one of mtasDialPlan, mtasDpv, vtasDialPlan, mtasOcbOpBCat, vtasOcbOpBCat, mtasOcbBCat, or vtasOcbBCat, depending on the attribute. This attribute can have values 0 (Active view) or 1 (Standby view).

Editing of the tables in active view is not allowed. In standby view, however, the standby tables can be edited without affecting the traffic in any way. The changes take effect when the standby tables are activated.

Activation can be done either with immediate effect, see Section 3.2.2 Set and Monitor Activation State, or by setting a scheduled change time, see Section 3.2.3 Schedule Activation. On activation the active and the standby tables are swapped. The effects of the last activation procedure can be canceled simply by repeating the activation procedure. The new entries become effective in the upcoming new sessions. Before activation, validity checks are executed on the entries.

If a configuration or activation request is rejected because of invalid data, an error with a text pointing out the reason for failure is presented to the user in the CM browser.

3.2.2 Set and Monitor Activation State

The attribute `xActivationState` describes the activation state of the standby dial plan table and can have one of the following values:
0=Idle		This value is the default state. There is no operation in progress.

1=Activate		Activation with immediate effect is requested. When the operator sets this state, the values in the standby table become active unless they are invalid. If there is invalid data, the activation request is rejected.

2=Processing		A table copy operation is in progress. During this time editing the entries, changing the activation state, or entering a scheduled change time (see Section 3.2.3 Schedule Activation) is disabled. When the operation has finished, the state is changed automatically to `0=Idle`.

3=CopyToStandby		Starts an asynchronous operation which copies the entries from the active table to the standby table. The values previously stored in the standby table are overwritten.

An activation with immediate effect can be triggered by setting xActivationState to 1=Activate. While loading the data, incoming traffic requests are queued. The requests are answered when the data is fully loaded. In addition, the MTAS offers a functionality which copies the active entries to the standby table (see state 3=CopyToStandby) as a preparation for changing the currently active entries. This operation does not affect the traffic in any way but it implicitly cancels any scheduled activation.

3.2.3 Schedule Activation

The attribute xChangeTime can be used to define a time point in the future when the standby table is activated. By default xChangeTime is set to empty string, meaning that no change is scheduled.

The format used to specify a valid change time is: YYYY-MM-DDThh:mm:ss (see ISO 8601:2004(E)). For example, the value 2011-07-23T18:15:00 schedules changing the active table at 18:15:00 on 23 of July, 2011.

An activation can be scheduled only in state 0=Idle. The execution time is limited to two weeks. When xChangeTime is set to a valid time in the future and the current standby entries are valid a change is scheduled, otherwise the configuration attempt is rejected.

The scheduled activation is handled similar to setting xActivationState to 1=Activate with the only difference that the standby table does not become effective immediately but later.

A scheduled activation can be canceled by setting xChangeTime to the empty string at any time. Setting xChangeTime to a valid time in the future reschedules the activation.

While the data is loading, the activation state is changed automatically to 2=Processing. Canceling or rescheduling activation is not possible when the loading of the data has started. When the data is fully loaded, xChangeTime is set back to empty string.

3.2.4 Impact of Dropback Attribute on vtasXxx Standby and Active Tables

If the dropback attribute of a vtasXxx table changes from 1 (OTP values) to 0 (VTP values) then both the active and the standby vtpTables are replaced with their otpTable pair. The original values of the vtpTables cannot be restored and the xChangeTime value is replaced. The copy is performed only if it results in a valid state otherwise the dropback attribute cannot be changed.

3.3 VTP-Controled Dial Plan Configuration

This section describes the procedures needed to manage the VTP-Controled Dial Plan.

The VTP-Controled Dial Plan is defined by the following three attributes:

vtasDialPlanAllowed
vtasDialPlanExcepted
vtasDialPlanDomain

The attributes vtasDialPlanAllowed and vtasDialPlanExcepted define the numerical addresses in the VTP. The vtasDialPlanAllowed lists the leftmost part of numbers to be included in the VTP. The vtasDialPlanExcepted lists the leftmost part of numbers to be excluded from the VTP.

The attribute vtasDialPlanDomain defines the non-numerical addresses in the VTP, by listing the domains to be included in the VTP.

3.3.1 Create MtasVtp

Note:: The MTAS stores one active and one standby table for each MO. Both the active and the standby table is accessible at any time. Changing the entries is possible only in the standby table. Changes become effective for new sessions after the standby table is activated.
Refer to Section 3.2 Overview Tables and Activation for VTP-Controled Dial Plan for details on selecting and editing the tables.

To create a VTP:

Navigate to the MtasFunction MO.
Click New Entry (Edit and then click New).
Remove any preselected classes.
Select MtasVtp from the available classes. Enter the Relative Distinguished Name (RDN), for example, MtasVtp=Vtp_0, and click Add.
Click OK. A new MtasVtp MO is presented in the CM browser.
Set the attributes for the MtasVtp MO, refer to Managed Object Model (MOM).
Click Submit.
Perform a backup, as described in Create Backup.

3.3.2 Modify List of Numbers Included in VTP

Note:: The MTAS stores one active and one standby table for each MO. Both the active and the standby table is accessible at any time. Changing the entries is possible only in the standby table. Changes become effective for new sessions after the standby table is activated.
Refer to Section 3.2 Overview Tables and Activation for VTP-Controled Dial Plan for details on selecting and editing the tables.

To modify the list of numbers included in the VTP:

Navigate to the VtasDialPlan MO.
In the Table Editor window, modify the vtasDialPlanAllowed attributes as required.
To add an entry to vtasDialPlanAllowed, right-click the attribute name and select Add Another Value from the pop-up menu.

This results in another row in the Table Editor, labeled appropriately.

To delete an entry from vtasDialPlanAllowed, right-click the attribute name and select Delete from the pop-up menu.

This results in the selected row being removed from the Table Editor window.

To modify an entry in vtasDialPlanAllowed, select the contents of the field to be changed and type the new value into the field.
Click Submit.

3.3.3 Modify List of Numbers Excluded from VTP

Note:: The MTAS stores one active and one standby table for each MO. Both the active and the standby table is accessible at any time. Changing the entries is possible only in the standby table. Changes become effective for new sessions after the standby table is activated.
Refer to Section 3.2 Overview Tables and Activation for VTP-Controled Dial Plan for details on selecting and editing the tables.

To modify the list of numbers excluded from the VTP:

Navigate to the VtasDialPlan MO.
In the Table Editor window, modify the vtasDialPlanExcepted attributes as required.
To add an entry to vtasDialPlanExcepted, right-click the attribute name and select Add Another Value from the pop-up menu.

This results in another row in the Table Editor, labeled appropriately.

To delete an entry from vtasDialPlanExcepted, right-click the attribute name and select Delete from the pop-up menu.

This results in the selected row being removed from the Table Editor window.

To modify an entry in vtasDialPlanExcepted, select the contents of the field to be changed and type the new value into the field.
Click Submit.

3.3.4 Modify List of Domains Included in VTP

Note:: The MTAS stores one active and one standby table for each MO. Both the active and the standby table is accessible at any time. Changing the entries is possible only in the standby table. Changes become effective for new sessions after the standby table is activated.
Refer to Section 3.2 Overview Tables and Activation for VTP-Controled Dial Plan for details on selecting and editing the tables.

To modify the list of domains included in the VTP:

Navigate to the VtasDialPlan MO.
In the Table Editor window, modify the vtasDialPlanDomain attributes as required.
To add an entry to vtasDialPlanDomain, right-click the attribute name and select Add Another Value from the pop-up menu.

This results in another row in the Table Editor, labeled appropriately.

To delete an entry from vtasDialPlanDomain, right-click the attribute name and select Delete from the pop-up menu.

This results in the selected row being removed from the Table Editor window.

To modify an entry in vtasDialPlanDomain, select the contents of the field to be changed and type the new value into the field.
Click Submit.

3.4 Service Data Configuration

This section describes how to configure the service data.

3.4.1 Operator Subscription Level Service Configuration

No service data for the Wholesale service is configured in the operator part of the subscriber data.

3.4.2 Subscriber Subscription Level Service Configuration

No service data for the Wholesale service is configured in the subscriber part of the subscriber data.

3.5 Announcement Configuration

The Wholesale-related announcements are handled through the Supplementary Service Codes (SSC) service. For more information about announcements through the SSC service, refer to MTAS Supplementary Service Codes Management Guide

4 Performance Management

There are no specific measurements for Wholesale. All existing MTAS counters continue to be updated, even when Wholesale is enabled. There is no mechanism to separate statistics for OTP and VTP users, or for different VTPs.

5 Fault Management

For alarms related to Wholesale, refer to MTAS Alarm List.