MTAS External Network Configuration for SIP Trunking

MTAS

1	Introduction
1.1	Prerequisites
2	Overview
3	ST AS Interfaces
3.1	Dh Interface
3.2	Sh Interface
3.3	SNM Interface
3.4	Rf Interface
3.5	CDS Interface
3.6	DNS Interface
3.7	Ma Interface (Static Mode Only)
3.8	ISC Interface
3.9	ST AS to IBCF (Static Mode over Ma Only)
3.10	ST AS to Transit Function (Static Mode over Ma Only)
3.11	CAI3G Interface
3.12	Mr Interface
3.13	Mp Interface
4	Static Mode Configuration
4.1	HSS Configuration
4.2	Public Service Identities
5	Dynamic Mode Configuration
5.1	HSS Configuration
5.2	Implicit Registration Set
5.3	CSCF Configuration
5.4	PBX Provisioning
5.5	Subscription and Service Profile Administration in HSS
5.6	Provisioning in MTAS
6	Deployment Dependent Configurations
6.1	Originating AS Chaining
7	Extra ST AS Nodes Installation

1 Introduction

This document describes the high–level configuration of the neighboring IMS nodes needed for correct operation of the SIP Trunking Application Server (ST AS) in 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.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:

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

2 Overview

The ST AS is an application server that provides most core functionality of SIP Trunking in the IMS Network.

ST AS is based on the MTAS architecture and provides interconnection between the IMS network and enterprises PBXs in static and in dynamic mode.

Static mode implies that the IP-PBX does not need to register with IMS. Instead, the IP-PBX has a peering connection with the IMS Network, and the routing paths are defined in provisioning data.

Dynamic mode implies that the IP-PBX registers each of its access routes with the IMS network using the IMS registration procedure.

The ST AS handles management and bundling of accesses (and SIP trunks) and, in addition, the offering of more services (for example, regulatory and supplementary services) to business customers.

For further details on the services provided by the ST AS, refer to MTAS 16B Technical Product Description SIP Trunking AS.

The ST AS also implements supporting functions that can be used by the ST services such as offline charging and Media Resource Function Controller (MRFC).

On the network level, an N+1 redundancy concept is used. It is implemented by using the dynamic allocation concept, and the Sh interface towards the HSS.

3 ST AS Interfaces

This section describes the ST AS external interfaces that are shown in Figure 1.

If the connectivity mode is not stated explicitly in these subsections, the interfaces are applicable to both static and dynamic mode.

Figure 1 ST AS External Interfaces

3.1 Dh Interface

The Dh interface between the MTAS and the Subscriber Location Function (SLF) is used to retrieve the address of the HSS that holds the subscription for a given PBX.

For more information about the Dh interface implementation and how to configure it in the MTAS, refer to MTAS Subscriber Data Management Guide and Sh/Dh Interface.

The Sh interface, which is between the ST AS and the HSS, is used for transferring PBX service information such as PBX identities, Implicit Registration Set (IRS) data, route information, and PBX service information.

For more information about the Sh interface implementation and how to configure it in MTAS, refer to MTAS Subscriber Data Management Guide and Sh/Dh Interface.

3.3 SNM Interface

The interface between the ST AS and the Sub-Network Manager (SNM) is using several protocols for different purposes, as follows:

SNMPv2C and SNMPv3 for fault management
FTP and SFTP for performance management
LDAPv3 and LDAPS for configuration management
Telnet and SSH for configuration management

For information about the ST AS node management procedures, refer to MTAS Node Management Guide.

3.4 Rf Interface

The Rf interface (Diameter Accounting Application) is used between the MTAS and the Charging Data Function (CDF) for transferring the ST AS offline charging information.

For more information about the Rf interface implementation, how to configure it in the MTAS, and configuration of the Diameter layer used by the Rf interface in MTAS, refer to Diameter Management, Diameter Offline Charging in MTAS, and MTAS Charging Management Guide.

3.5 CDS Interface

The Communication Details Server (CDS) interface is based on the Diameter Accounting Application. It is used between the MTAS and the CDS by the ST Malicious Communication Identification (MCID) service to transfer communication details for malicious communication identification purposes.

For more information about the CDS interface implementation, how to configure it in MTAS, and configuration of the Diameter Layer used by the CDS interface in MTAS, refer to Diameter Management, Diameter Communication Details in MTAS, and MTAS Charging Management Guide.

3.6 DNS Interface

The DNS is a client/server system used in TCP/IP networks. The DNS is used to map alphanumeric names to IP addresses.

For information about how to configure the DNS interface in the MTAS, refer to Managed Object Model (MOM).

3.7 Ma Interface (Static Mode Only)

For static mode connect, the ST AS can use the SIP protocol on the Ma interface with the Interrogating Call Session Control Function (I-CSCF).

For more information about the Ma interface implementation in MTAS and how to configure these interfaces, refer to MTAS Interface to CSCF (ISC, Ma, Pw) and MTAS SIP Management Guide.

3.8 ISC Interface

For static and dynamic mode connect, the ST AS can use the SIP protocol on the ISC interface with the S-CSCF.

For more information about the ISC interface implementation in MTAS, and how to configure these interfaces, refer to MTAS Interface to CSCF (ISC, Ma, Pw) and MTAS SIP Management Guide.

3.9 ST AS to IBCF (Static Mode over Ma Only)

For static mode over Ma interface for PBX terminating calls, the interface between the ST AS and the Interconnection Border Control Function (IBCF) contains two routes, one targeting the IBCF and one targeting the PBX.

3.10 ST AS to Transit Function (Static Mode over Ma Only)

For static mode over Ma interface for PBX originating calls, the ST AS inserts a preconfigured route set, and forwards to the Transit Function that works as a routing function. For more information about how to configure the transit function address in the ST AS, refer to MTAS SIP Trunking Management Guide.

For more information about how to configure the I-CSCF to work as a Transit Function, refer to Section 4.1.5.1 Standalone Transit I-CSCF Function (Static Mode over Ma Interface Only).

3.11 CAI3G Interface

The Customer Administration Interface Third Generation (CAI3G) interface is used as provisioning interface between the MTAS and Business Support System (BSS). CAI3G is based on the SOAP standard (XML/HTTP and XML/HTTPS). It can manage complex data models while hiding network complexity. There is support for notification to the business system.

For more information about the CAI3G interface implementation and how to configure these interfaces, refer to MTAS CAI3G Interface for ST AS and MTAS XDMS Management Guide.

3.12 Mr Interface

The Mr interface is used between the MTAS and the MRFC to control media services. When acting as UAC, MTAS supports DNS-based redundancy of the MRFC.

The MtasMrController.mtasMrControllerRoute attribute defines whether the external MRFC is directly routed to the MTAS (value 0), or through the Serving Call Session Control Function (S-CSCF) (value 1). The recommended setting is to use the direct routing to the MTAS, to save S-CSCF resources.

For more information about the Mr interface implementation and configuration in the MTAS, refer to MTAS Interface to MRF (Mr), MTAS Media Control Management Guide, and Managed Object Model (MOM).

3.13 Mp Interface

The Mp interface is used between the integrated MRFC and the Media Resource Function Processor (MRFP) whenever multimedia session manipulation is needed. The Mp interface is H.248-based.

For more information about the Mp interface implementation, configuration in the MTAS, and configuration of the domain Name Server/System (DNS) interface in the MTAS, refer to Configuring SS7, SCTP, MTAS H.248 Support, and MTAS Media Control Management Guide.

4 Static Mode Configuration

This section describes what must be configured when the static mode is applied.

Static mode PBXs can be configured as the static mode over Ma, or, the static mode over the ISC interface.

4.1 HSS Configuration

This section describes how to configure the HSS.

4.1.1 Initial Filter Criteria (Static Mode over ISC Only)

The list of initial Filtering Criteria (iFC) is part of the service profile, see Section 9.1 Subscription and Service Profile Administration in HSS and Section 5.2 in 3GPP TS 23.218 (v8.4.0).

An iFC consists of conditions to be met by the SIP request and the corresponding AS address, where the request is routed to when the conditions are fulfilled.

The mechanism for setting this data varies depending on network configuration and the mechanisms used in the specific network. The subsections describe the recommended iFC configurations for the following MTAS installation:

ST AS with Static Mode

Trigger the ST AS on the SIP port (mtasStSipPort).

When:

Method=INVITE AND SessionCase=Originating_Unregistered
Method=INVITE AND SessionCase=Terminating_Unregistered

4.1.2 Service Indication

This section describes the required Service Indication configuration in the HSS.

The service indication is the identity (name) of the transparent service data container in which the MTAS stores service-specific information.

The names of the listed service indications in the following sections reflect default identities used by the MTAS. If other names have been configured, the same names must be defined in HSS.

4.1.2.1 Referral Data

Repository data with service Indication StReferralConfig holds the main PBX Identity that refers to the PBX service data.

4.1.2.2 PBX Service Data

Repository data with Service Indication StServiceData holds the PBX control and service data.

4.1.3 HSS ServiceType

For static mode over Ma, the ST AS must be configured as a service type in HSS. This is done by configuring HSS-ServiceTypeId for "stas". This is done for the service profile of the main PBX PSI.

A capability (value 0-100) must be configured for the service type "stas" through the HSS-ServiceCapabilities attribute.

4.1.4 HSS-Service Trigger

Following configurations are needed:

HSS-TriggerPriority
HSS-IncludeRegisterRequest set to FALSE
HSS-IncludeRegisterResponse set to FALSE
HSS-IsActive set to: TRUE
HSS-DetectionPoint set to: INVITE
HSS-NegatedDetectionPoint
HSS-TriggerType TERMINATING_UNREGISTERED
HSS-ConditionType AND

4.1.5 CSCF Configuration (Static Mode over Ma Interface Only)

The cscfResourceBrokerEntry CSCF CM attribute in the I-CSCF is required to be set to tie the value for the service capability set in Section 4.1.3 HSS ServiceType to the name of the ST AS server.

To let the I-CSCF transit requests, the IcscfTransitEnabled attribute is set to TRUE, and the CscfUnallocatedRoutingEnabled attribute is set to TRUE.

4.1.5.1 Standalone Transit I-CSCF Function (Static Mode over Ma Interface Only)

The I-CSCF can be configured to work as a standalone transit function. This is done by configuring the TcscfBehavior attribute to " enabled for terminating traffic, HSS (LIR) lookups are not performed" (value 1), and the CscfISPBehavior attribute to "standalone I-CSCF" (value 1).

4.1.5.2 Co-located Transit I-CSCF Function (Static Mode over Ma Interface Only)

The I-CSCF can be configured to work as a transit function even when it is not configured as a standalone I-CSCF for transit. In that case, the HSS queries are performed.

4.2 Public Service Identities

The concept of Public Service Identities (PSIs) is used to identify services, service features, and groups, which are hosted by application servers. Each PSI is hosted by an AS, which executes the service logic identified by the PSI. The PSIs are defined in 3GPP TS 23.228 (v8.8.0), as follows:

Statically preconfigured PSIs in the filter information of the users (PSIs only on the originating side).
"PSI-users" configured in the HSS with the following two subcategories:
- Distinct PSIs, when they are specific public identities and there is a specific entry defined in the HSS for it (with its specific profile and assigned S-CSCF)
- Wildcarded PSIs, when the PSI is in a range so that when the received public identity matches the wildcard, it shares the data with the rest of public identities matching with that range. Wildcarded PSIs are not sent through the traffic interfaces. They are defined in the SLF and the HSS that check if a received specific public identity matches with a defined wildcard.
Subdomain-based PSIs where the AS hosting the PSIs are looked up

The PSI can take the form of a SIP URI or TEL URI.

A W-PSI represents a collection of PSIs.

When a terminating I-CSCF receives a W-PSI from the HSS in Location Information Answer, in the P-Profile-Key header AVP, the I-CSCF inserts the wildcarded PSI information in the P-Profile-Key header and forwards the information to an AS (or S-CSCF).

5 Dynamic Mode Configuration

This section describes the configuration that is valid for dynamic connection mode only.

5.1 HSS Configuration

This section describes the HSS configuration.

5.1.1 Initial Filter Criteria

The list of iFC is part of the service profile, see Section 9.1 Subscription and Service Profile Administration in HSS, and Section 5.2 in 3GPP TS 23.218 (v8.4.0).

An iFC consists of conditions to be met by the SIP request and the corresponding AS address where the request is routed to when the conditions are fulfilled.

ST AS with dynamic mode

Trigger the ST AS on the ST AS port (mtasSipStPort).

When:

Method=INVITE AND SessionCase=Originating_Unregistered
Method=INVITE AND SessionCase=Originating_Registered
Method=INVITE AND SessionCase=Terminating_Unregistered
Method=INVITE AND SessionCase=Terminating_Registered
Method=REGISTER with extended body (Request and Response), default handling SESSION_TERMINATE

5.2 Implicit Registration Set

This section describes Implicit Registration Set (IRS).

For each IRS, the following identities must be configured:

The main PBX identity, the default IMS Public Identity (IMPU), which is a distinct IMPU that is used to store a service document in transparent data. The default IMPU must be configured both in SIP and TEL format.
One or more distinct IMPUs used for registration, representing the PBX routes.
One or more wildcard IMPUs. Each wildcard IMPU represents a number series in the PBX.

The ST AS expects the first IMPU in the received IRS to be the default one, that is the main PBX identity and it has to be a SIP URI. This IMPU is used as key for later HSS transactions on the service profile. The other identities are IMPUs representing the PBX routes.

5.2.1 Service Indication

This section describes the required Service Indication configuration in HSS.

The service indication is the identity (name) of the transparent service data container in which MTAS stores service-specific information.

The names of the listed service indications in the following sections reflect default identities used by MTAS. If other names have been configured, the same names must be defined in HSS.

5.2.1.1 PBX Service Data

Repository data with Service Indication StServiceData holds the PBX control and service data

5.3 CSCF Configuration

The CSCF CM attribute ScscfwImpuEnabled must be enabled (set to TRUE) to enable CSCF to support IP-PBX registrations.

The ScscfNwProvidedInstanceIdEnabled CM attribute is used to enable and disable the Network Provided Terminal Identity feature in S-CSCF. This attribute must be set to TRUE, to enable the S-CSCF to provide the ST AS a network generated sip instance feature tag to be used as terminal identity, if the sip instance is not provided by the UE.

5.4 PBX Provisioning

This section describes the PBX provisioning.

5.5 Subscription and Service Profile Administration in HSS

The 3GPP user profile is described in 3GPP TS 29.228 (v8.6.0).

For details on configuration within the MTAS, refer to MTAS Subscriber Data Management Guide.

In general, without referring to any specific HSS, the following sections describe the data that must be configured for a PBX.

5.5.1 IMS Subscription Administration

The Charging Node Addresses attribute is provisioned for a PBX.

This attribute identifies the primary and secondary CDFs nodes that perform the charging for the PBX.

Note:: The mtasChargingDefaultCdfAddress CM attribute defines the CDF address to be used by the ST AS for offline charging purposes in the absence of charging function address information from the S-CSCF. For more information about the attribute, refer to Managed Object Model (MOM).

5.5.2 Service Profile Administration

The service profile administration configures the public identities, MSISDNs, and the IFC associated with an IMS subscription.

The following attributes are provisioned for a service profile:

PUI
This attribute is used by any other user requesting communication with other user.
MSISDN
Note:
This attribute is not supported by the ST AS.
IFC
This attribute defines the service Trigger points and their relations to application servers, see Section 4.1 HSS Configuration.
IRS
This attribute identifies the PBXs Implicit Registration Set that the public identity belongs to.
Is Default Indicator
This attribute indicates if the public identity is the default one of its IRS.

Note:
The ST AS expects the first public identity in the received IRS to be the default one, and it must be a SIP URI. This PUI is used as key for later HSS transactions on the Service Profile.
Maximum Simultaneous Session
This attribute indicates the number of SIP sessions allowed at the same time.

Note:
This attribute is not supported by the ST AS.

The ST Call Admission Control supplementary service enables the operator to further restrict the number of sessions a served user or a group of users involved in. For more information, refer to ST AS Call Admission Control Management Guide.

5.6 Provisioning in MTAS

The PBX provisioning in the ST AS is supported through the CAI3G interface, see Section 3.11 CAI3G Interface.

CAI3G is a synchronous, request, or response-based provisioning interface. The interface is defined in XML, and it uses Simple Object Access Protocol (SOAP) to format the interface into message. The SOAP message are carried by HTTP methods.

The Sh interface is used to access storage on the HSS. The MTAS PBX subscription data is stored as "transparent data" on the HSS. This means that the HSS is unaware of the structure of the data except that it must be formed XML. For details on the Sh interface, see Section 3.2 Sh Interface.

6 Deployment Dependent Configurations

The following sections describe the network configurations of the MTAS services that depend on deployment that is on the capabilities and configuration of other nodes in the IMS network.

6.1 Originating AS Chaining

ST AS can be configured to support Originating AS chaining, this means, to support external triggering of originating services in one or more AS after call has been retargeted.

For more information about Originating AS chaining in ST AS, refer to MTAS SIP Management Guide and MTAS Interface to CSCF (ISC, Ma, Pw).

When an S-CSCF is configured to trigger originating services after retargeting (the Originating CDIV session case), an IFC trigger is set per user, the user is then allocated to an MTAS that has this behavior enabled.

For more information about the Originating CDIV session case, refer to 3GPP TS 29.228 (v8.6.0).

7 Extra ST AS Nodes Installation

When installation of extra ST AS nodes for capacity or redundancy reasons, the following external configuration activities are needed:

Configure the interfaces to the new ST AS node in the neighboring nodes, that is, in MRFP, CSCF, and so on.
Configure firewalls, if needed
Configure iFCs in the HSS, if needed.