Contents
1 Introduction
This document describes how to configure the XML Document Management Server (XDMS) function 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 Documents
Before any of the procedures in this document are done, the following documents must be available:
1.1.2 Conditions
The following conditions must apply:
- An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
- For configuring the CAI3G interface, the user must be familiar with and be entitled to use the services of a trusted Certificate Authority. The user must also know the password for the users required for the different steps described in this document.
For information on the different users and the corresponding roles, restrictions, and privileges, refer to Certificate Management and Security Management for ECLI, NETCONF, and SFTP Users.
2 Overview
The XDMS function supports the CAI3G interface to allow the operator to provision and update the PSTN/ISDN Simulation Services data for subscribers and an Ut interface to allow the subscriber to manipulate their own PSTN/ISDN Simulation Services data. To achieve this, the XDMS function also supports a Sh interface to fetch and update the data in the Home Subscriber Server (HSS). All service data XML instance files have normalized entries, refer to Managed Object Model (MOM).
The configuration of the XDMS 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 MtasXdsm Managed Object (MO) controls the XDMS function for a complete MTAS node.
The configuration of the Diameter stack and the Sh interface of the XDMS function is shared with the subscriber data 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).
3 Configuration
3.1 Diameter Stack Configuration
Several of the MTAS-specific parameter values must be configured in the Diameter stack. To configure the Diameter stack instance for the XDMS function, refer to MTAS Subscriber Data Management Guide.
3.2 Sh Interface Configuration
To route Sh messages correctly, it is necessary to specify which realm the HSS nodes belong to. The Sh configuration attributes of the XDMS function are shared with the subscriber data function.
To configure the Sh parameters, configure the applicable attributes, mtasShIfDestinationRealm, and mtasShIfDestinationHost. For more information, refer to MTAS Subscriber Data Management Guide.
The mtasShIfMmtelServiceInd is set by default during the MTAS installation.
4 Optional XDMS Function Parameters Configuration
The MtasXdmsData MO makes it possible to configure other parameters, than the ones that are described in this document, and which are related to the XDMS function. For a complete description of all parameters relating to the configuration of the XDMS function MO, refer to Managed Object Model (MOM).
If a parameter is changed, it is a delay of 5 seconds until the new value is reflected.
5 Interface Accesses
The XDMS function supports CAI3G and Ut interfaces, which includes the protocol XML Configuration Access Protocol (XCAP).
The XDMS function supports a CAI3G interface to allow the operator to manage subscriber data. The CAI3G interface is a Web Services interface.
To enable the CAI3G interface, it must be unlocked using the mtasXdmsCai3gAdministrativeState parameter on the MtasXdms MO.
It is also necessary to create at least one user account – an instance of MtasXdmsCai3gUser MO with its associated mtasXdmsCai3gUserPassword parameter.
For further details, refer to Managed Object Model (MOM).
Ut, protocols XCAP
The XCAP protocol for MMTel Telephony AS allows the subscriber to manipulate their PSTN/ISDN Simulation Services data, for more information, refer to RFC 4825.
To enable the Ut interface, it must be unlocked using the mtasXdmsUtAdministrativeState parameter on the MtasXdms MO.
For further details, refer to Managed Object Model (MOM).
It requires permission to license "Access of User Service Data through Ut-interface" to use the interface.
5.1 XDMS Setups
The XCAP Root URI does not correspond to an actual resource on an XCAP server. Actual resources are created by appending additional path information to the XCAP Root URI. For more information on XCAP Root, refer to RFC 4825.
The URI for the XCAP Root (interface) on the MMTel AS is as follows:
http://<platform-vip>:8090/mtasxdms
The parameter <platform-vip> is the VIP used to run the XDMS function. If a dedicated VIP address is used for Ut traffic, then use Ut VIP address as hostname.
The URI for the CAI3G interface on the MMTel AS is as follows:
http://<platform-vip>:8095/axis2/services/CAI3G
https://<platform-vip>:8443/axis2/services/CAI3G
http://<platform-vip>:8095/mtasstas
The URI for the CAI3G interface on the ST AS is as follows:
https://<platform-vip>:8443/mtasstas
If there is a dedicated VIP for CAI3G traffic, use CAI3G VIP address cai3g-vip instead of platform-vip. For more information, refer to MTAS SW Installation and Virtual IP Address Management. Ports must be made available in the hardening of the node.
- Note:
- If IPv6 is used, <platform-vip6> must be used. That is, a numeric IPv6 address, the address must be enclosed in brackets (for example: [2000::4:66]).
5.2 XCAP Handling
The PSTN/ISDN Simulation Services application use has an AUID of simservs.ngn.etsi.org. The document name for configuration of an individual subscriber is simservs.xml. This means that the URL to access a document for a particular user has the following form:
http://<platform-vip>:8090/mtasxdms/simservs.ngn.etsi.org/users/<subscriber_uri>/simservs.xml.
The parameter <subscriber_uri> is the URI of the subscriber. All requests on this interface must be valid XCAP requests and must have either the X-3GPP-Asserted-Identity or the X-XCAP-Asserted-Identity header, to prove that the proxy has authenticated them. For information on access at element or attribute granularity requiring an extra node selector, refer to RFC 4825.
This means a URL of the following form:
http://<platform-vip>:8090/mtasxdms/simservs.ngn.etsi.org/users/<subscriber_uri>/simservs.xml/~~/<node_selector>.
The parameter <node_selector> equals the selected extra node selector.
The XDMS function also supports the XCAP server capabilities application use with AUID "‘xcap-caps"’. The URL to access the XCAP server capabilities has the following form:
http://<platform-vip>:8090/mtasxdms/xcap-caps/global/index.
5.3 CAI3G Interface Configuration
The XDMS function supports a secured CAI3G interface to allow the operator to manage subscriber data in an encrypted and authenticated way. The authentication of the MTAS is enabled by a trusted certificate.
The operator has the possibility to perform the following operations on the CAI3G certificate:
- Delete the CAI3G certificate
- Create a new self-signed CAI3G certificate
- Import a trusted certificate
- List stored certificates
- Apply the modified MTAS XDMS Keystore
Without a valid CAI3G certificate, the secured CAI3G interface of the MTAS cannot operate. For further keytool parameters, refer to Keytool - Key and Certificate Management Tool.
5.3.1 Delete the CAI3G Certificate
To delete the CAI3G certificate:
- From an SSH client, log on to the platform-vip:
ssh<emergency user>@<platform-vip>
- Delete the old CAI3G certificate:
sudo /usr/java/latest/bin/keytool -delete -alias CAI3G -keypass xdmspass -storepass xdmspass –keystore /cluster/storage/system/config/mtas/.xdmskeystore
5.3.2 Create a New Self-Signed CAI3G Certificate
If there is a CAI3G certificate already stored in the XDMS keystore, remove it, see Section 5.3.1 Delete the CAI3G Certificate. For listing the available certificates in the XDMS keystore, see Section 5.3.4 List Stored Certificates.
To create a new self-signed CAI3G certificate:
- From an SSH client, log on to the platform-vip:
ssh<emergency user>@<platform-vip>
- Generate a new self-signed CAI3G certificate:
sudo /usr/java/latest/bin/keytool -genkey -alias CAI3G -storepass xdmspass -keypass xdmspass –keystore /cluster/storage/system/config/mtas/.xdmskeystore
- Enter the certificate data.
5.3.3 Import a Trusted Certificate
If there is a CAI3G certificate already stored in the XDMS keystore, remove it, see Section 5.3.1 Delete the CAI3G Certificate. For listing the available certificates in the XDMS keystore, see Section 5.3.4 List Stored Certificates.
To import a trusted certificate:
- Copy the trusted certificate to the cluster:
sftp <emergency user>@<platform-vip>
lcd<local path of the certificate file>
cd /cluster/storage/system/config/mtas
put <cacert file>
exit - From an SSH client, log on to the platform-vip:
ssh<emergency user>@<platform-vip>
- Import the trusted CAI3G certificate:
sudo /usr/java/latest/bin/keytool -import -alias CAI3G -storepass xdmspass -keypass xdmspass –keystore /cluster/storage/system/config/mtas/.xdmskeystore –file /cluster/storage/system/config/mtas/<cacert file>
- Examine certificate data, enter yes if trusted.
5.3.4 List Stored Certificates
To list the stored certificates:
- From an SSH client, log on to the platform-vip:
ssh<emergency user>@<platform-vip>
- List the stored certificate:
/usr/java/latest/bin/keytool -list -v -storepass xdmspass –keystore /cluster/storage/system/config/mtas/.xdmskeystore
5.3.5 Apply the Modified MTAS XDMS Keystore
To restart the MMAS traffic instances:
- Check the DN
of the MMAS instances:
immfind safSg=SG-traffic,safApp=ERIC-MMAS-APP | grep ^safComp
For example:
safComp=ERIC-MMAS-COMP-0,safSu=ERIC-MMAS-SU-0,safSg=SG-traffic,safApp=ERIC-MMAS-APP
safComp=ERIC-MMAS-COMP-0,safSu=ERIC-MMAS-SU-1,safSg=SG-traffic,safApp=ERIC-MMAS-APP
- Restart the instances one by one on each Payload Node,
where N is the number of the corresponding
Payload Node, and DN is the identity of
the MMAS instance, as queried in Step 1.
ssh<emergency user>@PL-[N]
For example:
sshmtasuser01@PL-3
echo ':reload'> /tmp/mmas.txt
cd /opt/mmas/instance
sudo ./run_cli_command -n "[DN]" -f /tmp/mmas.txt -o
For example:
sudo ./run_cli_command -n
safComp=ERIC-MMAS-COMP-0,safSu=ERIC-MMAS-SU-0,safSg=SG-traffic,safApp=ERIC-MMAS-APP" -f /tmp/mmas.txt –o
{
"outcome" => "success",
"result" => undefined
}
- Restart the MTAS software. For further details, refer to MTAS Node Management Guide.
6 Logging
The XDMS logging is described in MTAS Troubleshooting Guideline, for information about how to collect the logs, refer to Data Collection Guideline for MTAS.