Contents

1   Introduction

This document describes how to configure the Subscriber Data function in the MTAS.

1.1   Prerequisites

This section describes the prerequisites that must be fulfilled. It is assumed that the user of this document is familiar with the Operation and Maintenance (O&M) area, in general.

1.1.1   Documents

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

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

1.1.2   Conditions

The following condition must apply:

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

2   Overview

This section describes the MTAS Subscriber Data function, the MTAS Subscriber Data Management Function, the Diameter stack, and the Sh interface.

2.1   MTAS Subscriber Data Function

The MTAS Subscriber Data function tracks the following:

• The service data of each subscriber.
• The service data of each MMTel service profile.
• The scheduled conference configuration data, group service data, and service number data, which are used by the MTAS services.

The function retrieves subscriber service data, the service data of MMTel service profile, the scheduled conference configuration data, and group service data from the Home Subscriber Server (HSS) node, and caches the data for performance reasons. Caching contact data is enabled by default. Disabling caching can be performed by setting CM parameter mtasSubsDataCacheContactData to 0.

Notifications are received from the HSS node if the service data has been changed. The service number data, retrieved from the HSS node is cached (if caching is not disabled) and is part of the function Scheduled Conference.

Service data XML instances have either normalized entries, or non-normalized entries with ad-hoc presentation and CDIV digits present.

For information on normalized entries, refer to Managed Object Model (MOM).

Caching contact data is set to enabled during upgrade if mtasSccAdministrativeState is enabled or if mtasFcdAdministrativeState and mtasFcdDistributeToPrimaryUserDevices are enabled, disabling caching can be performed by setting CM parameter mtasSubsDataCacheContactData to 0.

2.2   MTAS Subscriber Data Management Function

The MTAS Subscriber Data management function provides the operator the ability to query and purge subscriber data and scheduled conference data cached in the MTAS and to place the result of the query or purge into a file which can be retrieved by the operator. The file location is defined by the read-only mtasSubsDataMgmtFile attribute.

An option exists for operator to purge the data related to subscribers' ongoing call sessions in MTAS by extending the command syntax described in Section 2.2.2 MTAS, Subscriber Data Management Command Syntax with an optional string "#rmSessionData" at the end. In this case, the session data that the MTAS services have cached for handling ongoing call sessions of related subscribers is deleted besides the subscribers’ cached service data and scheduled conference data. This option is introduced as a workaround in situations where MTAS internal session handling appears to be stuck because of unhandled errors. The operator needs to use this option with care as this can cause external session-related resources in other IMS nodes (such as Charging Server or media resource handler) to be temporarily stuck. The operator must also know that the MTAS does not immediately remove these external resources after an extended purge operation or even after the session has ended.

For the MTAS Subscriber Data Managed Objects (MOs) MtasSubsData and MtasSubsDataMgmt, refer to Managed Object Model (MOM).

2.2.1   MTAS Subscriber Data Management for Unregistered Users

The MTAS subscriber data management function manages the data for unregistered subscribers. MTAS handles all identities in an Implicit Registration Set (IRS) as belonging to the same profile. The MTAS only caches one set of the transparent data (subscriber service data) per IRS. The subscriber data is purged on deregistration timer (mtasSubsDataDeregTimer) expiry after a call is terminated for an unregistered user. The default value is 6 hours. Keep the value of CM Parameter mtasSubsDataDeregTimer such that new subscriber data including IRS changes are downloaded from HSS at least once a day (during night).

2.2.2   MTAS, Subscriber Data Management Command Syntax

Query and purge functionality may be used after an HSS zone reload (purge all), for upgrade (purge all), maintenance (partial query and purge), and dimensioning (partial purge, migrating existing users to a new MTAS). If a purge for all subscribers (or a majority of subscribers) is needed, it is recommended to start the purge operation when the CPU load on the traffic processors is less than 30% (non traffic-intensive period). Compared to when started during a traffic-intensive period (>30%) the operation finishes faster and less of the ongoing traffic is affected.

The query and purge command syntax is shown in Table 1. Several patterns and wildcards can be used.

(1)  Two wildcards "*" cannot be used next to one another.

2.3   Diameter Stack and Sh Interface

The configuration of the Subscriber Data function involves defining Diameter stack attributes, and defining the realm to which the HSS node belongs. Optionally, the configuration involves defining the hostname of the HSS node or the Subscriber Location Function (SLF) node.

The MtasSubsData MO controls the Subscriber Data function for a complete MTAS node.

The configuration of the Diameter stack and the Sh interface of the Subscriber Data function is shared with the XML Document Management Server (XDMS) function.

The configuration of the Number Normalization data of the XDMS function is shared with the Subscriber Data function. For more information, refer to Managed Object Model (MOM).

2.4   Sh Query Delay Configuration

The MTAS Subscriber Data function normally fetches and caches user data from HSS when a user initially registers in the IMS network. This can cause high network load when high amounts of registration are performed at the same time, for example, after a network disturbance event. MTAS supports a mechanism to delay this fetching and caching of data until the first call attempt of the subscriber. As call attempts are more evenly distributed in time, this can help distribute HSS load in time. MTAS can be configured both to delay Sh fetching in every case or only delay when HSS is in overloaded state.

To enable Sh query delay, set mtasSubsDataInitRegHSSFetchDelay CM parameter to one of the following values:

• 1 (Delay all queries except ATCF-related queries): This setting is used when Service Centralization and Continuity Application Server (SCC-AS) is used with Single Radio Voice Call Continuity (SRVCC) Release 10 to be compatible with Access Transfer Control Function (ATCF) anchoring procedures. Only the data fetching related to ATCF anchoring are performed during initial registration, other data fetching from HSS are delayed to the subscriber’s first attempt of making or receiving a call.
• 2 (All HSS data fetching delayed, including ATCF-related ones as well): This setting is used to delay all the Sh requests until the first call attempts of the subscriber. This behavior can cause incompatible behavior with ATCF anchoring when used with SRVCC Release 10 procedures.
• 3 (HSS data fetching delayed except ATCF related but fallback to delaying all in HSS overload situation is enabled): This setting is used when request only delayed in HSS overload condition. If this setting is used, then MTAS HSS overload timer must be configured with mtasSubsDataHSSOverloadTimer.

For more details on parameters, refer to Managed Object Model (MOM).

3   Configure Sh Diameter Stack

Some MTAS-specific parameter values must be configured in the Diameter stack. The configuration of the Sh Diameter stack for the Sh and Dh interfaces specifies parameters for the HSS and the SLF respectively. In Figure 1, these nodes are defined within the hss.ericsson.se realm. One SLF node can coexist with one or several HSS nodes.

By convention, if only one HSS resides in the network, then the SLF is not used by MTAS/XDMS and the parameter mtasShIfDestinationHost must be set to the HSS hostname hss1.hss.ericsson.se.

If the mtasShIfDestinationHost parameter is set or an SLF proxy is used, then the network assumption is that only one HSS exists and there is no need for an SLF query. The mtasShIfDestinationHost is always set to the hostname of the HSS, for example, hss1.hss.ericsson.se.

If the mtasShIfDestinationHost parameter is left blank, then the network assumption is that more than one HSS exists and there is a need for an SLF query to find the correct HSS.

One stack instance must be configured for the Subscriber Data function, and another stack instance must be configured for the XDMS function.

The SLF enables the MTAS to discover the HSS hostname by acting as a Diameter Redirect Agent functionality.

The following instruction describes the minimal configuration for configuring the MTAS node, as shown in Figure 1.

Note:  

For information on how to configure the MOs described in this procedure, refer to Managed Object Model (MOM).

To configure the Diameter Stack:

1. Set the own node configuration parameters. Configure the DIA-CFG-OwnNodeConfig MO as described in Table 2.
2. Set the neighbor node configuration parameters. Configure the DIA-CFG-NeighbourNode MO, as described in Table 3. This procedure is repeated for each node in the realm.

   The Diameter Stack must be configured with information about other nodes in the network and information about how to behave when routing messages.

   This information is found in the following MOs:

   • DIA-CFG-Drt
   • DIA-CFG-AuthReqContainer
   • DIA-CFG-AppRouting
3. Set the Realm Routing Table (RRT) configuration parameters. Configure the DIA-CFG-Drt MO. The RRT configuration is described in Table 5.
4. Set the Authorization Application Routing Configuration parameters. Configure the DIA-CFG-AppRouting MO. Perform the Application Routing Configuration, as described in Table 6 .
5. Perform a backup. For more information, refer to Create Backup.

See Figure 2 for a browser view example of Diameter stack parameters.

3.1   Parameters

All parameters in Table 2, Table 3, and Table 6 must be set. Do not set the parameter in Table 5 if the mtasShIfDestinationHost attribute is set. The parameters have dependencies to the MTAS, and are to be used together with the general parameter list in the Diameter configuration.

For information on the LDAP identities, refer to Managed Object Model (MOM).

3.1.1   Own Node Configuration for Subscriber Data/XDMS Functions

The values of the DIA-CFG-OwnNodeConfig MO for Subscriber Data/XDMS functions are defined in Table 2 and in Managed Object Model (MOM).

Each node in the realm configures its own DIA-CFG-OwnNodeConfig MO.

Note:  

Because the Subscriber Data/XDMS functions act as clients, the watchdogTimeIdle, maxNumberOfRetries, and maxRequestPendingTime parameters must not be configured on the other peer nodes. However, if they are configured, then they must be configured to the same values as here.

3.1.2   Neighbor Node Data Configuration for Subscriber Data/XDMS Functions

Data for other Diameter Peer Nodes in the network must be configured for Subscriber Data/XDMS functions. This makes it possible for the Subscriber Data/XDMS function to set up communication with those nodes. One DIA-CFG-NeighbourNode object is created for each peer node in the network.

The values of the DIA-CFG-NeighbourNode MO for the Subscriber Data/XDMS functions are defined in Table 3. For more information, refer to Managed Object Model (MOM).

When a neighbor node is added to the stack, it contains one connection labeled conn1 by default. Multiple connections can be added (up to the number of Dicos Traffic Processors in the MTAS) if supported by the peer node (HSS or SLF). Expansion to multiple connections is supported by the Ericsson HSS and SLF, but not necessarily by other vendors since it is not included in the Diameter standard. The value of the DIA-CFG-Conn MO for Subscriber Data/XDMS functions is defined in Table 4.

3.1.3   Realm Routing Table Data Configuration

The settings of the RRT are defined in Table 5 and Table 6. The Realm-related configuration is set through the following MOs:

• DIA-CFG-Drt, see Table 5
• DIA-CFG-AppRouting, see Table 6

For information on how to configure the MOs, refer to Managed Object Model (MOM).

The mandatory entryId field has three parts:

• The realm of the client
• The stack instance to identify the Own Node
• The indication of whether this entry of the RRT is used to route incoming or outgoing requests

In Table 5, the Subscriber Data/XDMS functions are clients and send requests to the SLF and the HSS which act as Diameter servers. The isIncomingRequest indicator is set to FALSE for the Subscriber Data/XDMS functions. The mandatory action field must be set to none, indicating that the Subscriber Data/XDMS functions act as a client.

See Table 6 for information on setting the Authorization Application Routing parameters for Subscriber Data and XDMS functions.

(1)  No action is taken. The Subscriber Data/XDMS functions can only have the value 4 because the entryId attribute's isIncomingRequest is set to false in DIA-CFG-Drt.

4   Configure Sh Interface

To route Sh messages correctly, it is necessary to specify which realm the HSS nodes belong to. The Sh configuration attributes of the Subscriber Data function are shared with the XDMS function.

To associate a realm to an HSS node:

1. Navigate to the MtasShIf MO.
2. Set the mtasShIfDestinationRealm attribute to the HSS realm, for example, hss.ericsson.se.

Note:  

If the mtasSubsDataRegistrationMode is set to 2 (No Register Mode) in the mtasSubsData MO, then step 3 and step 4 are not needed.

3. Use one of the following options for the mtasShIfDestinationHost attribute:
   • If there is more than one HSS present in the network, then leave the mtasShIfDestinationHost attribute empty.
   • Otherwise, set the mtasShIfDestinationHost attribute to the HSS hostname, for example, hss1.hss.ericsson.se.

4. Set the mtasShIfMmtelServiceInd attribute to configure the MMTel service data indication. The attribute value must match the service indication used in the HSS to store the MMTel service data, for example, MmtServiceConfig.

5. Set the mtasShIfMmtelGroupServiceInd attribute to configure the MMTel group service data indication. The attribute value must match the service indication used in the HSS to store the MMTel group service data, for example, MmtGroupServiceConfig.
6. Set the mtasShIfMmtelServiceProfileInd attribute to configure the MMTel Service Profile data indication. The attribute value must match the service indication used in the HSS to store the MMTel Service Profile data, for example MmtServiceProfileConfig.
7. If the function Scheduled Conference is going to be used, continue with step 8, else continue with step 10.
8. Set the mtasShIfMmtelServiceNumberInd attribute to configure the MMTel service number data indication. The attribute value must match the service indication used in the HSS to store the MMTel service number data, for example, MmtServiceNumberConfig.
9. Set the mtasShIfMmtelSchedConfInd attribute to configure the MMTel Scheduled Conference data indication. The attribute value must match the service indication used in the HSS to store the MMTel Scheduled Conference data, for example, MmtSchedConfConfig.
10. If the SIP Trunking function is to be used, set the mtasShIfStReferralServiceInd attribute to configure the SIP Trunking Referral data indication. The attribute value must match the service indication used in the HSS to store the SIP Trunking referral data, for example, StReferralConfig.
11. If the SIP Trunking function is to be used, set the mtasShIfStServiceDataInd attribute to configure the SIP Trunking Service Data indication. The attribute value must match the service indication used in the HSS to store the SIP Trunking Service Data, for example, StServiceConfig.
12. If the Sh interface efficiency function is to be used, set the mtasShIfEfficiency attribute to 1. If the mtasShIfEfficiency is set, there is the possibility to change the default behavior of the feature with two additional attributes. The default values of these attributes are set to standard mode. The Notif-Eff capability is always propagated in all Sh messages.

    The mtasShIfEffDiscoveryMode attribute specifies how the MTAS propagates its Update-Eff capability in the Sh messages sent towards the HSS. The mtasShIfEffDiscoveryMode can be set to standard or intensive mode.

    The mtasShIfEffMandatoryBitSetting attribute specifies how the MTAS sets the Mandatory bit (M bit) in the Supported-Features AVP header of the Sh messages. The mtasShIfEffMandatoryBitSetting attribute can be set to standard or informative mode.

13. Click Submit.
14. Perform a backup. For more information, refer to Create Backup.

See Figure 3 for a browser view example of Sh configuration attributes.

5   Configure Caching Contact Data and UE Terminal Type Classification

Caching contact data is enabled by setting mtasSubsDataCacheContactData attribute to 1.

Caching contact data is set to enabled by default. Disable it if not needed, to avoid redundant traffic and increase performance.

When CM attribute mtasSubsDataCachePani is enabled, P-Access-Network-Info (PANI) from SIP REGISTER/INVITE/180/183/200(INVITE) is also saved in the Contact Data. CM attribute mtasSubsDataCacheContactData must be enabled before enabling mtasSubsDataCachePani.

Caching contact data is required specifically by IMS Centralized Services (ICS) on SCC-AS and Flexible Communication Distribution (FCD) to Primary User’s Devices. For more information about the ICS on SCC-AS, refer to MTAS IMS Centralized Services Management Guide. For more information about the FCD to Primary User’s Devices, refer to MTAS Flexible Communication Distribution Management Guide.

Subscriber Data function caches registered contacts information, parsed from the body of third-party REGISTER message from S-CSCF (SIP REGISTER).

For this purpose, the iFC in HSS is configured to trigger initial registration, re-registration, and deregistration to the MTAS and to include the user REGISTER request and 200 OK response in the "message/sip" body of the third-party registration.

If caching is enabled, but the Contact Data cannot be fetched from the body of third-party REGISTER for some reason (for example, the body or a part of it is missing or broken), MTAS behaves differently, depending on deployment configuration.

• MMTel AS standalone tries to retrieve the Contact Data from S-CSCF using one time reg-event subscription.
• SCC-AS (standalone or collocated with MMTel AS) rejects the third-party REGISTER with a SIP 400 Bad Request response with the Warning header set to 399: “MIME body message/sip content not sufficient”.

For more information about the MMTel AS registration procedures, refer to MTAS External Network Configuration.

If caching is enabled, but the Contact Data is not locally cached on MTAS when a call establishment is made (when originating or terminating initial INVITE is received), for example in failover scenarios, Contact Data is fetched from S-CSCF with explicit one-time reg-event subscription and cached.

When contact data is being retrieved from S-CSCF with explicit one time reg-event subscription, mtasSubsDataRegEventResponseTimer setting defines the time that MTAS waits for a response to SUBSCRIBE sent to the S-CSCF to obtain a served user's registration status. The same setting also defines the time that MTAS waits for a NOTIFY after receipt of a 2xx response to the SUBSCRIBE.

If IMPI has not been parsed from the reg-event NOTIFY and is not stored in MTAS, like in 3GPP R9, the IMPI is updated based on the P-Com.PrivateUserID header, if available. For the originating session case P-Com.PrivateUserID header from the INVITE is used, and for terminating session case P-Com.PrivateUserID header from 200 OK response to INVITE is used.

Contact data remains in cache until expiry of registration timer, which set in mtasSubsDataDefaultRegTimer CM attribute. The default value of the registration timer is 21600 minutes.

UE terminal type classification (mobile/VoLTE or fixed) during 3rd-party registration and processing of reg-event notification for caching Contact Data purpose can be based on either registered contact’s feature tags or PANI header. Feature tags, being basis for device mobility classification as mobile/VoLTE, are configurable by attribute mtasSubsDataMobileClassification. If it contains at least one entry, the classification is based on feature tags listed in this CM attribute only, without taking P-Access-Network-Info header into account. Otherwise, if this setting is empty (default value), a device is classified as “mobile” based on the P-Access-Network-Info header indicating 3GPP GERAN, 3GPP UTRAN or 3GPP E-UTRAN access, and if P-Access-Network-Info header is absent - based on presence of +g.3gpp.ics=”server” or +g.3gpp.accesstype=”cellular” feature tag. If none of the above conditions is fulfilled, a device is classified as “fixed” by default.

6   Wholesale for Subscriber Data Configuration

The MTAS Subscriber Data only partially supports Wholesale. The MtasSubsData MO is the only one of the MOs that control the Subscriber Data function that supports Wholesale. The MO is configurable on Virtual Telephony Provider (VTP) level, that is the VTP operators can have their own configuration in the corresponding VtasSubsData MO instances.

Note:  

The functions to purge and query subscriber data do not support Wholesale.

To configure Wholesale for the MTAS Subscriber Data function, attributes in the VtasSubsData MO must be configured and the vtasSubsDataDropBack attribute must be set to 0 (use own VTP values).

For more information about the attributes in the VtasSubsData MO, refer to Managed Object Model (MOM).

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

7   Query or Purge File Retrieval

The files produced for the query or purge operations for administration analysis are retrieved using the File Transfer Utility (FTU) configuration to clean up the files created during the query or purge operations.

Specific reference is to be made to the User Guide for the FTU, for more information, refer to File Management.

8   Examples, Subscriber Data Management

This section describes some subscriber data and some query or purge examples.

8.1   Subscriber Data

A subscriber has a main identity and can have up to seven extra alias identities defined. The subscriber data is kept in the HSS for the main identity and the same data is used for the alias identities.

The query or purge examples in Table 7 are based on the PUI data defined in Table 1.

8.2   Scheduled Conference Data

There are two types of scheduled conference-related data cached in MTAS:

ServiceNumber Data

Holds information about service numbers (SNs). SN information elements are keyed by SN URIs (typically E.164 telephone numbers).

Conference Configuration Data

Holds information about conferences. Information elements here are keyed by conference owners' PUIs.

For more information on Scheduled Conference data and concepts, check the MTAS Scheduled Conference Management Guide.

The query or purge examples in chapters Section 8.3.7 Query or Purge Using Wildcard (Scheduled Conference Data) and Section 8.3.8 Query or Purge All Using Wildcard (Scheduled Conference Data) are based on the ServiceNumber and Conference Configuration data defined in Example 1 and Example 2.

Table 8 Scheduled Conference Data, Example ServiceNumber data:

ServiceNumber: 
tel:+4485110000
tel:+4485220000

ConferenceConfigData: 
sip:+46123456789@someplace.com
sip:+46987654321@someplace.org

In case of querying or purging scheduled conference data, currently only operations started with wildcarded command syntaxes are taken into account. The MMTel- and Scheduled Conference AS-s are typically not co-located so there will either be MMTel Subscriber Data- or Scheduled Conference Data keys in the query/purge result file. The scheduled conference data-related lines in the result file are prefixed with 'ServiceNumber:' or 'ConferenceConfigData:' depending on what type of data they are representing.

8.3   Query or Purge Examples

This section describes some query or purge examples.

8.3.1   Query or Purge Using Single PUI

An example of a query using Single PUI, sip:+46123456789@someplace.com or tel:+46123456789, is shown in Example 3.

1. Navigate to the MtasSubsDataMgmt MO.
2. Set the status to 3 (query) for the mtasSubsDataMgmtStatus attribute.
3. Set the value sip:+46123456789@someplace.com to the mtasSubsDataMgmtPui attribute.
4. Click Submit.

Results

The output file contains the following information:

8.3.2   Query or Purge Using Wildcard

An example of doing a query or purge using wildcard sip:*xxxxxx or tel:*xxxxxx, is shown in Example 4.

1. Navigate to the MtasSubsDataMgmt MO.
2. Set the status to 3 (query) or 4 (purge) for the mtasSubsDataMgmtStatus attribute.
3. Set the value sip:*xxxxxx or tel:*xxxxxx to the mtasSubsDataMgmtPui attribute.
4. Click Submit.

Results

The output files contain the following information:

8.3.3   Query or Purge All Using Wildcard

An example of doing a query or purge all using wildcard *, is shown in Example 5.

1. Navigate to the MtasSubsDataMgmt MO.
2. Set the status to 3 (query) or 4 (purge) for the mtasSubsDataMgmtStatus attribute.
3. Set the value * to the mtasSubsDataMgmtPui attribute.
4. Click Submit.

Results

The output file contains the following information:

8.3.4   Query or Purge sip:* or tel:* Using Wildcard

An example of doing a query or purge using wildcard sip:* or tel:*, is shown in Example 6.

1. Navigate to the MtasSubsDataMgmt MO.
2. Set the status to 3 (query) or 4 (purge) for the mtasSubsDataMgmtStatus attribute.
3. Set the value sip:* or tel:* to the mtasSubsDataMgmtPui attribute.
4. Click Submit.

Results for a sip:* Query or Purge

The output file contains the following information:

Results for a tel:* Query or Purge

The output file contains the following information:

8.3.5   Query or Purge Using Two Wildcards

An example of doing a query or purge using two wildcards is shown in Example 7.

1. Navigate to the MtasSubsDataMgmt MO.
2. Set the status to 3 (query) or 4 (purge) for the mtasSubsDataMgmtStatus attribute.
3. Set the value sip:*xxx* or tel:*xxx* to the mtasSubsDataMgmtPui attribute.
4. Click Submit.

Results for a sip:*xxx* or tel:*xxx* Query or Purge

The output file contains the following information:

8.3.6   Query or Purge Using Multiple Wildcards

An example of doing a query or purge using Query/Purge using multiple wildcards is shown in Example 8.

1. Navigate to the MtasSubsDataMgmt MO.
2. Set the status to 3 (query) or 4 (purge) for the mtasSubsDataMgmtStatus attribute.
3. Set the value sip:*xxx*xxx* or tel:*xxx*xxx* to the mtasSubsDataMgmtPui attribute.
4. Click Submit.

Results for sip:*xxx*xxx* or tel:*xxx*xxx*

The output file contains the following information:

8.3.7   Query or Purge Using Wildcard (Scheduled Conference Data)

An example of doing a query or purge using wildcard sip:* for query and tel:* for purge is shown in Example 9.

1. Navigate to the MtasSubsDataMgmt MO.
2. Set the status to 3 (query) or 4 (purge) for the mtasSubsDataMgmtStatus attribute.
3. Set the value sip:* or tel:* to the mtasSubsDataMgmtPui attribute.
4. Click Submit.

Results for a sip:* Query

The output file contains the following information:

Results for a tel:* Purge

The output file contains the following information:

8.3.8   Query or Purge All Using Wildcard (Scheduled Conference Data)

An example of doing a query or purge all using wildcard * is shown in Example 10.

1. Navigate to the MtasSubsDataMgmt MO.
2. Set the status to 3 (query) or 4 (purge) for the mtasSubsDataMgmtStatus attribute.
3. 3. Set the value * or * to the mtasSubsDataMgmtPui attribute.
4. Click Submit.

Results for a a* Query

The output file contains the following information:

Results for a a* Purge

The output file contains the following information: