MTAS External Network Configuration
MTAS

Contents

1Introduction
1.1Prerequisites

2
Overview

3
MTAS Interfaces
3.1Dh Interface
3.2Sh Interface
3.3CNS Interface
3.4SNM Interface
3.5Rf Interface
3.6Ro Interface
3.7CDS Interface
3.8DNS Interface
3.9ISC, Ma, and Pw Interfaces
3.10Ut Interface
3.11CAI3G Interface
3.12CAT Interface
3.13Mr Interface
3.14Mp Interface
3.15CAPv2 Interface
3.16ETSI MAP Interface
3.17Parlay X Interface

4
Session Border Gateway
4.1Call Pull with Replaces Header

5
HSS Configuration
5.1Initial Filtering Criteria
5.2Implicit Registration Set
5.3Service Indication

6
Public Service Identities
6.1Settings for Ad-hoc Conferencing Service
6.2Settings for 3PTY Service
6.3Settings for Group Call Admission Control
6.4Settings for Single Radio Voice Call Continuity Release 10

7
Dynamic Allocation Configuration
7.1DNS Configuration
7.2Dynamic Allocation with AS Instance Caching

8
DNS Based Redundancy and Load Sharing of External Server Nodes
8.1SRV Records
8.2A/AAAA Records
8.3Actual IP Address List of an External Server

9
Configuration of Differentiated Services (DiffServ)

10
User Provisioning
10.1Subscription and Service Profile Administration in HSS
10.2Provisioning in MTAS

11
Deployment Dependent Configurations
11.1AS Controlled Forking
11.2Originating AS Chaining
11.3MTAS Services Suppression Based on the INVITE Method

12
Parameter Value Selection for Deployment Dependent CM Attributes

13
Installation of Additional MTAS Nodes

1   Introduction

This document describes the high-level configuration of the neighboring IMS nodes needed for correct operation of the MTAS. In addition, it describes the configuration needed for using the specific capabilities of 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

Not Applicable.

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:

2   Overview

The MTAS is an Application Server (AS) on the IMS Service Control (ISC) interface in an IMS network. The MTAS can fulfill several different functional roles in a Multimedia Telephony (MMTel) solution. These roles are MMTel Telephony AS, Network AS, and Service Centralization and Continuity (SCC) AS.

As an MMTel Telephony AS, the purpose of the MTAS is to provide real time (real time to be understood as opposed to store-and-forward), and peer-to-peer communication services, including basic communication services as well as MMTel-specific supplementary services.

As a Network AS, the MTAS provides communication interworking SIP signaling between entities with missing precondition capability support. Currently, MTAS supports QoS precondition SIP signaling for the terminating UEs which does not support QoS preconditions.

As an SCC AS, the MTAS provides the possibility to offer IMS Centralized Services (ICS) and Single Radio Voice Call Continuity (SRVCC) according to the following standards which are key components for a Voice over LTE (VoLTE) solution:

The MTAS also implements supporting functions that can be used by the communication service, such as charging and a built-in Multimedia Resource Function Control (MRFC) function.
This is all implemented by the underlying platform.
On network level, an N+1 redundancy concept is used. It is implemented by using the so-called dynamic allocation concept, and the Sh interface towards the HSS.
The MTAS can be used in mobile, fixed, or FMC type of networks. In that sense, it is access agnostic.

3   MTAS Interfaces

The MTAS external interfaces are shown in Figure 1.

Figure 1   MTAS 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 which holds the subscription for a given user.

For more information about the Dh interface implementation and how to configure it in the MTAS, refer to the following documents:

3.2   Sh Interface

The Sh interface, which is between the MTAS and the HSS, is used for transferring user profile information such as user service-related information, user identities, or charging function addresses.

The messages on the Sh interface can be routed by two different routing mechanisms:

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

3.3   CNS Interface

The interface between the MTAS and the Calling Name Server (CNS) is used for obtaining calling name information using two different protocols as follows:

For more information about the CNS interface implementation and how to configure it in the MTAS, refer to MTAS Calling Name Identity Presentation Management Guide and NameDb.

3.4   SNM Interface

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

For information about the MTAS Node Management procedures, refer to MTAS Node Management Guide.

3.5   Rf Interface

The Rf interface (Diameter Accounting Application) is used between the MTAS and the Charging Data Function (CDF) for transferring MMTel 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 the following documents:

3.6   Ro Interface

The Ro interface (Diameter Credit Control Application) is used between the MTAS and the Online Charging Function (OCF) for transferring MMTel online charging information. The Ro interface is also used by the Advice of Charge (AoC) Supplementary Service for accessing the AoC information related to a communication to be provided to the served user.

For more information about the Ro interface implementation, how to configure it in the MTAS, and configuration of the Diameter layer used by the Ro interface in MTAS, refer to the following documents:

3.7   CDS Interface

The Communication Details Servers (CDS) interface is based on the Diameter Accounting Application. It is used between the MTAS and the CDS by the Malicious Communication Identification (MCID) service to transfer communication details for Malicious Communication Identification purposes. It is also used by other Supplementary Services that allow the user to request actions that are based on earlier calls (that is, Dynamic Black List).

For more information about the CDS interface implementation, how to configure it in the MTAS, and configuration of the Diameter layer used by the CDS interface in MTAS, refer to the following documents:

3.8   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.9   ISC, Ma, and Pw Interfaces

The ISC interface is the interface between the MTAS and the Serving Call Session Control Function (S-CSCF). The ISC interface is implemented using the SIP protocol. The MTAS also uses the SIP protocol on the Ma interface with the Interrogating Call Session Control Function (I-CSCF) and the Pw interface to the Presence Server. From an MTAS perspective, the Ma and Pw interfaces are functionally equivalent to the ISC interface with one exception; when acting as User Agent Client (UAC), MTAS supports DNS-based redundancy of the I-CSCF.

For more information about the ISC, Ma, and Pw interface implementation in MTAS and how to configure these interfaces, refer to the following documents:

3.10   Ut Interface

The OMA XDM-3 interface is used between the User Equipment (UE) and the AS to configure and manage groups, user access policies, URI lists, presence lists, and presence access policies. The 3GPP uses the name Ut for this interface, refer to ETSI TS 183 023.

The protocol used on the Ut interface is XML Configuration Access Protocol (XCAP). XCAP is a set of XML rules that conforms an XML document. This document is transported through HTTP.

The MTAS implementation is using the Ut interface. Ut interface requires that the messages from UE have already been authenticated before sending them to MTAS. The Aggregation Proxy (AP) node, see Figure 1, implements the authentication of Ut interface messages for MTAS.

For more information about the Ut interface, the implementation and configuration of the interface in the MTAS, refer to the following documents:

3.11   CAI3G Interface

The Customer Administration Interface Third Generation (CAI3G) interface is used as a 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 in the MTAS and how to configure these interfaces, refer to the following documents:

3.12   CAT Interface

The Customized Alerting Tones Server (CAT-S) is a dedicated external MRF resource used for generating CAT signal. The CAT signal is music or an announcement played for the caller on terminating calls to the served user.

The MTAS supports DNS-based redundancy of the CAT-S.

For more information about the CAT interface implementation and configuration in the MTAS, refer to MTAS Interface to CAT-S (CAT).

3.13   Mr Interface

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

The attribute mtasMrControllerRoute defines whether the External MRFC is directly routed to the MTAS (value 0), or through the S-CSCF (value 1). In rare cases, for example for Completion of Communication to Busy Subscriber (CCBS) recall announcement, the information about the S-CSCF is not available and the announcement request is routed directly. The recommended setting is to use 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 the following documents:

3.14   Mp Interface

The Mp interface is used between the integrated MRFC and the Multimedia 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 and configuration in the MTAS, and configuration of the Domain Name Server/System (DNS) interface in the MTAS, refer to the following documents:

3.15   CAPv2 Interface

The CAMEL Application Protocol version 2 (CAPv2) interface is used to enable Intelligent Network (IN) interaction in the MMTel Telephony AS, and to allocate the IMS Routing Number (IMRN) for IMS Centralized Services (ICS) users. For CAMEL interaction, the MMTel calls are influenced and controlled by the services in the IN layer. The CAP operations are carried over SIGTRAN (SS7 over SCTP).

For more information about the CAPv2 interface implementation and configuration in the MTAS, refer to MTAS CAPv2 Management Guide, MTAS IMS Centralized Services Management Guide, and MTAS SS7 Management Guide.

3.16   ETSI MAP Interface

The ETSI Mobile Application Part (MAP) interface is used between SCC AS (acting as Gateway Mobile Switching Center (GMSC)) and Home Location Register (HLR) or visited Mobile Switching Center (vMSC). SCC AS can use the ETSI MAP interface to query the HLR for a Mobile Station Roaming Number (MSRN) to route the call to the Circuit Switched domain. SCC AS can also receive resume call handling request from vMSC when the served user’s mobile moves to another vMSC after the MSRN is allocated.

MAP is a Transaction Capabilities Application Part (TCAP) user and the operations are carried over SIGTRAN.

For more information about the ETSI MAP interface configuration in the MTAS, refer to MTAS IMS Centralized Services Management Guide and MTAS SS7 Management Guide.

3.17   Parlay X Interface

The MTAS can interact with Parlay X enabled applications deployed on application servers. This interaction can be with the MTAS in client or server role, or both. MTAS supports DNS-based redundancy of the Parlay X enabled applications taking server role.

For more information about the Parlay X interface implementation and configuration in the MTAS, and configuration of the Parlay X interface in the MTAS, refer to the following documents:

4   Session Border Gateway

This chapter describes how to use SIP Message Manipulation (SMM) rules in Session Border Gateway (SBG).

4.1   Call Pull with Replaces Header

For Call Pull with replaces header service in MMTel AS to be able to interwork with the Ericsson SBG, two SMM rules need to be created and applied to SBG to prevent SBG from modifying the replaces header.

Two rulesets are to be applied as part of SBG incoming and part of SBG core outgoing SMM filter as follows:

Ruleset "For_SBG_access_incoming"

  If
    is_request and
    SIP:cseq.method == "INVITE" and
    SIP:replaces exists and
    not SIP:replaces;from-tag ~= '^h7g4Esbg_(.*)' and
    not SIP:replaces;to-tag ~= '^h7g4Esbg_(.*)'
  Do
    SIP:replaces;to-tag := "remove_" + SIP:replaces;to-tag
  End
End

Ruleset "For_SBG_core_outgoing"

  If
     is_request and
     SIP:cseq.method == "INVITE" and
     SIP:replaces exists and
     SIP:replaces;to-tag ~= '^h7g4Esbg_remove_(.*)'
  Do
     SIP:replaces;to-tag := $1.1
  End
End

5   HSS Configuration

This section describes how to configure the HSS.

5.1   Initial Filtering Criteria

The list of Initial Filtering Criteria (IFC) is part of the service profile, see Section 10.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 upon network configuration and the mechanisms used in the specific network. The subsections describe the recommended IFC configurations for the following MTAS installations:

The configuration of the attributes used at determining the Session Case is described in MTAS SIP Management Guide.

The examples in the following sections assume that the Session Case is determined by the MTAS port. The logic is similar, when the Session Case is determined by the attributes of the P-Served-User header.

Note:  
The MMTel Telephony AS is not to be included in the triggers for the Originating_CDIV session case, since the MMTel Telephony AS does not use the triggers for the Originating_CDIV session case.
If Originating AS Chaining is used, the Originating_CDIV session case does not apply, so inserting the MMTel Telephony AS in the triggers for the Originating_CDIV session case has no effect.

If Originating AS Chaining is not used, inserting the MMTel Telephony AS in the triggers for the Originating_CDIV session results in double execution of the originating services.


5.1.1   Base MMTel Settings

The following HSS pseudo configuration is recommended when base MMTel features are used:

  1. Trigger the MTAS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method="INVITE" AND SessionCase="Originating"

  2. Trigger the MTAS on the originating unregistered port (mtasSipTrafficOrigUnregIpPort)

    when:

    Method="INVITE" AND SessionCase="Originating_Unregistered"

  3. Trigger the MTAS on the terminating port (mtasSipTrafficTerminatingIpPort)

    when:

    Method="INVITE" AND SessionCase="Terminating_Registered"

  4. Trigger the MTAS on the terminating unregistered port (mtasSipTrafficTermUnregIpPort)

    when:

    Method="INVITE" AND SessionCase="Terminating_Unregistered"

  5. Trigger the MTAS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method="REGISTER" AND (RegistrationType="Initial" OR
    RegistrationType="De-registration")

Note:  
The MTAS must not be triggered on periodic re-registration.

If MTAS is configured for caching contact data (mtasSubsDataCacheContactData=1), then IFC must be configured to include the original REGISTER request and the 200 OK response in every 3rd-party REGISTER request sent to MTAS; see Section 5.1.11 Settings for Flexible Communication Distribution to Primary User's Devices. If caching contact data by MTAS is not needed, that is, Flexible Communication Distribution to Primary User’s Devices is not used (mtasFcdDistributeToPrimaryUserDevices=0), then caching is to be disabled on MTAS instead (mtasSubsDataCacheContactData=0), to avoid superfluous SUBSCRIBEs for "reg" event.


For more information about the triggered ports described in this section, refer to Managed Object Model (MOM).

5.1.2   Settings for Base MMTel Features and Communication Completion Service

The following HSS pseudo configuration is needed when the Communication Completion optional feature is used:

  1. Trigger the MTAS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method=”"INVITE" AND SessionCase="Originating" AND NOT
    RequestURI=".*noifc=orig.*"

  2. Trigger the MTAS on the originating unregistered port (mtasSipTrafficOrigUnregIpPort)

    when:

    Method="INVITE" AND SessionCase="Originating_Unregistered"

  3. Trigger the MTAS on the terminating port (mtasSipTrafficTerminatingIpPort)

    when:

    Method="INVITE" AND SessionCase="Terminating_Registered"
    AND NOT RequestURI=".*noifc=term.*"

  4. Trigger the MTAS on the terminating unregistered port (mtasSipTrafficTermUnregIpPort)

    when:

    Method="INVITE" AND SessionCase="Terminating_Unregistered"
    AND NOT RequestURI=".*noifc=term.*"

  5. Trigger the MTAS on the terminating port (mtasSipTrafficTerminatingIpPort)

    when:

    Method="SUBSCRIBE" AND NOT SessionCase="Originating"
    AND (header="Event" Content="call-completion")

  6. Trigger the MTAS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method="REGISTER" AND (RegistrationType="Initial"
    OR RegistrationType="De-registration")

Note:  
The MTAS must not be triggered on periodic re-registration.

If MTAS is configured for caching contact data (mtasSubsDataCacheContactData=1), then IFC must be configured to include the original REGISTER request and the 200 OK response in every 3rd-party REGISTER request sent to MTAS; see Section 5.1.11 Settings for Flexible Communication Distribution to Primary User's Devices. If caching contact data by MTAS is not needed, that is, Flexible Communication Distribution to Primary User’s Devices is not used (mtasFcdDistributeToPrimaryUserDevices=0), then caching is to be disabled on MTAS instead (mtasSubsDataCacheContactData=0), to avoid superfluous SUBSCRIBEs for "reg" event.


For more information about the triggered ports described in this section, refer to Managed Object Model (MOM).

5.1.3   Settings for Base MMTel Features and Ad-hoc Conferencing Service

The following HSS pseudo configuration is needed when the Ad-hoc Conferencing optional feature is used and the mtasSipCallOutOfBlueRouting CM attribute is set to 1 (I-CSCF):

Note:  
The settings for the Communication Completion optional feature include the listed configuration for the Ad-hoc Conferencing optional feature.

  1. Trigger the MTAS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method="INVITE" AND SessionCase="Originating"
    AND NOT RequestURI=".*noifc=orig.*"

  2. Trigger the MTAS on the originating unregistered port (mtasSipTrafficOrigUnregIpPort)

    when:

    Method="INVITE" AND SessionCase="Originating_Unregistered"

  3. Trigger the MTAS on the terminating port (mtasSipTrafficTerminatingIpPort)

    when:

    Method="INVITE" AND SessionCase="Terminating_Registered"

  4. Trigger the MTAS on the terminating port (mtasSipTrafficTermUnregIpPort)

    when:

    Method="INVITE" AND SessionCase="Terminating_Unregistered"

  5. Trigger the MTAS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method="REGISTER" AND (RegistrationType="Initial"
    OR RegistrationType="De-registration")

Note:  
The MTAS must not be triggered on periodic re-registration.

If MTAS is configured for caching contact data (mtasSubsDataCacheContactData=1), then IFC must be configured to include the original REGISTER request and the 200 OK response in every 3rd-party REGISTER request sent to MTAS; see Section 5.1.11 Settings for Flexible Communication Distribution to Primary User's Devices. If caching contact data by MTAS is not needed, that is, Flexible Communication Distribution to Primary User’s Devices is not used (mtasFcdDistributeToPrimaryUserDevices=0), then caching is to be disabled on MTAS instead (mtasSubsDataCacheContactData=0), to avoid superfluous SUBSCRIBEs for "reg" event.


For more information about the CM attributes and triggered ports described in this section, refer to Managed Object Model (MOM).

5.1.4   Settings for Base MMTel Features, Communication Completion Service, and Ad-hoc Conferencing Service

The following HSS pseudo configuration is needed when the Communication Completion optional feature is used:

  1. Trigger the MTAS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method="INVITE" AND SessionCase="Originating" AND NOT
    RequestURI=".*noifc=orig.*"

  2. Trigger the MTAS on the originating unregistered port (mtasSipTrafficOrigUnregIpPort)

    when:

    Method="INVITE" AND SessionCase="Originating_Unregistered"

  3. Trigger the MTAS on the terminating port (mtasSipTrafficTerminatingIpPort)

    when:

    Method="INVITE" AND SessionCase="Terminating_Registered"
    AND NOT RequestURI=".*noifc=term.*"

  4. Trigger the MTAS on the terminating unregistered port (mtasSipTrafficTermUnregIpPort)

    when:

    Method="INVITE" AND SessionCase="Terminating_Unregistered"
    AND NOT RequestURI=".*noifc=term.*"”

  5. Trigger the MTAS on the terminating port (mtasSipTrafficTerminatingIpPort)

    when:

    Method="SUBSCRIBE" AND NOT SessionCase="Originating"
    AND (header="Event" Content="call-completion")

  6. Trigger the MTAS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method="REGISTER" AND (RegistrationType="Initial"
    OR RegistrationType="De-registration")

Note:  
MTAS must not be triggered on periodic re-registration.

If MTAS is configured for caching contact data (mtasSubsDataCacheContactData=1), then IFC must be configured to include the original REGISTER request and the 200 OK response in every 3rd-party REGISTER request sent to MTAS; see Section 5.1.11 Settings for Flexible Communication Distribution to Primary User's Devices. If caching contact data by MTAS is not needed, that is, Flexible Communication Distribution to Primary User’s Devices is not used (mtasFcdDistributeToPrimaryUserDevices=0), then caching is to be disabled on MTAS instead (mtasSubsDataCacheContactData=0), to avoid superfluous SUBSCRIBEs for "reg" event.


For more information about the triggered ports described in this section, refer to Managed Object Model (MOM).

5.1.5   Settings for Base MMTel Features and Session Transfer to Own Device (STOD) Service

The following HSS pseudo configuration is needed when the STOD optional feature is used, where it replaces Trigger 3 in Section 5.1.1 Base MMTel Settings.

  1. Trigger the MTAS on the terminating port (mtasSipTrafficTerminatingIpPort)

    when:

    Method="INVITE" AND SessionCase="Terminating_Registered"
    AND NOT RequestURI=".*noifc=term.*"

For more information about the triggered ports described in this section, refer to Managed Object Model (MOM).

5.1.6   Settings for Group Call Admission Control

All users who belong to a Call Admission Control (CAC) group must have their services delivered by the same MTAS. The IFC for all users belonging to the same CAC group must be configured so that when the user registers in the IMS, the same MTAS is chosen to provide the Group CAC (GCAC) service for the user as for all other members of the same CAC group.

For information about how to configure the CAC service in the MTAS, refer to MTAS Call Admission Control Management Guide.

5.1.7   Settings for Service Centralization and Continuity

When the Service Centralization and Continuity AS (SCC AS) is deployed on the MTAS node, the following HSS pseudo configuration is recommended:

  1. Trigger the SCC AS on the originating port (mtasSipSccOrigPort)

    Method="INVITE" AND SessionCase="Originating"
    AND NOT RequestURI=".*noifc=orig.*"

  2. Trigger the SCC AS on the originating unregistered port (mtasSipSccOrigUnregPort)

    Method="INVITE" AND SessionCase="Originating Unregistered"
    AND NOT RequestURI=".*noifc=orig.*"

  3. Trigger the SCC AS on the terminating port (mtasSipSccTermPort)

    Method="INVITE" AND SessionCase="Terminating"

  4. Trigger the SCC AS on the terminating unregistered port (mtasSipSccTermUnregPort)

    Method="INVITE" AND SessionCase="Terminating Unregistered"

  5. Trigger the SCC AS on the originating port (mtasSipSccOrigPort) for registration

    Include REGISTER REQUEST AND Include REGISTER RESPONSE

    If the S-CSCF supports the optimized 3rd Party Registration where subscriber registered first and added contacts, both are mapped to Initial RegistrationType and deregistered contact and last contact both are mapped to De-Register RegistrationType, the Re-Register only carries Refresh of contact and is not needed.

    This is the case for Ericsson S-CSCF:

    Method="REGISTER" AND (RegistrationType="Initial" OR
    RegistrationType="De-registration"

    In other cases the Re-Register RegistrationType is needed as well, to get information about all registered contacts:

    Method="REGISTER" AND (RegistrationType="Initial" OR
    RegistrationType="Re-registration" OR
    RegistrationType="De-registration")

    Note:  
    The SCC AS must be triggered on re-registrations from non-Ericsson S-CSCF to get information about all registered contacts. SCC AS must be triggered as the first AS for originating and originating unregistered IFC, and as the last AS for terminating and terminating unregistered IFC.

    The IFC definition must ensure that the SCC AS is not triggered in case subscribers send out-of-dialog SUBSCRIBE of conference event.


For more information about the CM attributes and triggered ports described in this section, refer to Managed Object Model (MOM).

5.1.8   SCC AS and MMTel Telephony AS Co-Located

When the SCC AS and MMTel Telephony AS are co-located on the same MTAS node, depending on the type of networks or service profiles MTAS serves, the following IFC configuration must be considered.

5.1.9   Settings for SCC with T-SDS

When the SCC AS with T-SDS is deployed on the MTAS node, the following HSS pseudo configuration is recommended:

  1. Trigger the SCC AS for the IMS T-SDS service on the terminating port (mtasSipSccTermPort)

    Method="INVITE" AND SessionCase="Terminating"

    The ServerName property in the Server Profile must be configured to match the CM attribute mtasSdsTAsName.

  2. Trigger the SCC AS for the IMS T-SDS service on the terminating unregistered port (mtasSipSccTermUnregPort)

    Method="INVITE" AND SessionCase="Terminating Unregistered"

    The ServerName property in the Server Profile must be configured to match the CM attribute mtasSdsTAsName.

Note:  
In addition to the IFCs in Section 5.1.7 Settings for Service Centralization and Continuity, the SCC AS must in this case be triggered as the first AS for terminating or terminating unregistered IFC.

For more information about the triggered port described in this section, refer to Managed Object Model (MOM).

5.1.10   Settings for SCC Supporting Mix of VoLTE and 2G/3G

When the SCC AS with supporting mix of VoLTE and 2G or 3G is deployed on the MTAS node, refer to MTAS IMS Centralized Services Management Guidefor more details, the following HSS pseudo configuration is recommended:

  1. Trigger the SCC AS on the terminating port (mtasSipSccTermPort).

    Method="INVITE" AND SessionCase="Terminating"

    One Service Profile must be configured for the 2G or the 3G user and another Service Profile for the VoLTE user.

    The ServerName property in VoLTE Service Profile must be configured to start with a string that matches the CM attribute mtasSubsDataVolteCaseName.

  2. Trigger the SCC AS service on the terminating unregistered port (mtasSipSccTermPort).

    Method="INVITE" AND SessionCase="Terminating Unregistered"

    One Service Profile must be configured for the 2G or the 3G user and another Service Profile for the VoLTE user.

    The ServerName property in VoLTE Service Profile must be configured to start with a string that matches the CM attribute mtasSubsDataVolteCaseName.

Note:  
SCC AS must be triggered as the last AS for terminating and terminating unregistered IFC.

For more information about the triggered port described in this section, refer to Managed Object Model (MOM).

5.1.11   Settings for Flexible Communication Distribution to Primary User's Devices

If the FCD service is used to distribute calls to Primary User's Devices(mtasFcdDistributeToPrimaryUserDevices=1), which requires caching contact data to be enabled on MTAS (mtasSubsDataCacheContactData=1) and the MMTel Telephony AS is standalone (that is not co-located with SCC AS), the following HSS pseudo configuration is recommended for registration:

  1. Trigger the MMTel Telephony AS on the originating port (mtasSipTrafficOriginatingIpPort) for registration.

    Include REGISTER REQUEST AND Include REGISTER RESPONSE.

    In case the S-CSCF supports the optimized 3rd Party Registration where subscriber registered first and added contacts both are mapped to Initial RegistrationType and deregistered contact and the last contact both are mapped to De-Register RegistrationType, the Re-Register only carries Refresh of contact and is not needed.

    This is the case for Ericsson S-CSCF:

    Method="REGISTER" AND (RegistrationType="Initial" OR
    RegistrationType="De-registration")

    In other cases, the Re-Register RegistrationType is needed as well, to get information about all registered contacts:

    Method="REGISTER" AND (RegistrationType="Initial" OR
    RegistrationType="Re-registration" OR
    RegistrationType="De-registration")

For more information about the triggered port described in this section, refer to Managed Object Model (MOM).

5.1.12   Settings for Emergency Call Notification

The following HSS pseudo configuration is recommended when the Emergency Call Notification feature is used:

  1. Trigger the MTAS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method="NOTIFY" AND SessionCase="Originating" AND
    EventHeader="emergencyCall;.*"

  2. Trigger the MTAS on the originating unregistered port (mtasSipTrafficOrigUnregIpPort)

    when:

    Method="NOTIFY" AND SessionCase="Originating_Unregistered"
    AND EventHeader="emergencyCall;.*"

For more information about the triggered ports described in this section, refer to Managed Object Model (MOM).

5.1.13   Settings for Charging Info Notification

The following HSS pseudo configuration is recommended when the Charging Info Notification feature is used:

  1. Trigger the MTAS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method="NOTIFY" AND SessionCase="Originating" AND
    EventHeader="charging-info;.*"

  2. Trigger the MTAS on the originating unregistered port (mtasSipTrafficOrigUnregIpPort)

    when:

    Method="NOTIFY" AND SessionCase="Originating_Unregistered" AND
    EventHeader="charging-info;.*"

  3. Trigger the MTAS on the terminating port (mtasSipTrafficTerminatingIpPort)

    when:

    Method="NOTIFY" AND SessionCase="Terminating_Registered" AND
    EventHeader="charging-info;.*"

  4. Trigger the MTAS on the terminating unregistered port (mtasSipTrafficTermUnregIpPort)

    when:

    Method="NOTIFY" AND SessionCase="Terminating_Unregistered" AND
    EventHeader="charging-info;.*"

For more information about the triggered ports described in this section, refer to Managed Object Model (MOM).

5.1.14   Settings for Dialog Event Notification

The following HSS pseudo configuration is recommended when the Dialog Event Notification feature is used:

  1. Trigger the MMTel AS on the originating port (mtasSipTrafficOriginatingIpPort)

    when:

    Method="SUBSCRIBE" AND SessionCase="Originating" AND
    (header="Event" Content ="dialog")

For more information about the triggered ports described in this section, refer to Managed Object Model (MOM).

5.1.15   Settings for Network AS

When the Network Application Server (NW AS) is deployed on the MTAS node, the following HSS pseudo configuration is recommended:

  1. Trigger MTAS on the SIP generic port (mtasSipAsGenericPort) Method="INVITE" AND SessionCase="Originating_Registered"

To trigger NW AS, the following conditions must be met:

For more information about the CM attributes and triggered ports described in this section, refer to Managed Object Model (MOM).

5.2   Implicit Registration Set

This section describes Implicit Registration Set (IRS).

5.2.1   Alias Identities

An IRS is a group of Public User Identities (PUI) that are registered through a single registration request. When one PUI within the set is registered, all PUIs associated with the IRS are registered at the same time. Similarly, when one of the PUIs within the set is deregistered, all PUIs that have been implicitly registered are deregistered at the same time.

A PUI is an alias of another PUI if both identities belong to the same IRS, are linked to the same service profile, and have the same service data configured for each service, see 3GPP TS 23.228 (V8.8.0).

The MTAS expects the first public identity in the received IRS to be the default one, and it has to be a SIP URI. This PUI is used as key for later HSS transactions on the Service Profile. The other identities in the IRS, that is, TEL-URIs, are alias identities.

5.2.2   Settings for Short Number Dialing Service

The Short Number Dialing (SND) service provides the members in a group with the ability to call each other by short numbers common to all members of the group.

For the SND service, the SND identities must be provisioned in the IRS of all SND users.

Note:  
The SND identity is not to be the default PUI.

The related SND domains must also be configured in the MTAS with proper settings of the mtasSndDomains CM attribute, refer to Managed Object Model (MOM).

For the concepts and configuration of the SND service in the MTAS, refer to MTAS Short Number Dialing Management Guide.

5.2.3   Settings for AS Controlled Forking

For the deployment-dependent IRS configuration for the AS Controlled Forking feature, see Section 11.1.1.1 IRS Configuration.

5.3   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 name of the listed service indications in the following sections reflects default identities used by MTAS. If other names have been configured, the same names must be defined in HSS.

5.3.1   MMTel Telephony Supplementary Services

Use of the MMTel Telephony Supplementary Services requires definition of a Service Indication in HSS.

5.3.2   MMTel Group Call Admission Control

Use of the Group Call Admission Control requires definition of a Service Indication in HSS.

5.3.3   MMTel Telephony Supplementary Services Service Profile

Use of the MMTel Telephony Supplementary Services Service Profile in MTAS requires definition of a Service Indication in HSS.

MmtServiceProfileConfig is the default service indication string used to identify the transparent data containing the MMTel Service Profile data. Service indication string different than the default value can be defined by the mtasShIfMmtelServiceProfileInd CM attribute in the MTAS.

5.3.4   SCC AS data

Use of Access Transfer Control Function (ATCF) info restoration requires definition of Service Indication with value of SccData in HSS.

6   Public Service Identities

The concept of Public Service Identities (PSIs) is used to identity 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).

  1. Statically preconfigured PSIs in the filter information of the users (PSIs only on the originating side).
  2. "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 the public identities matching that range (profile, assigned S-CSCF). Wildcarded PSIs are not sent through the traffic interfaces. They are defined in the SLF and HSS that check if a received specific public identity matches with a defined wildcard.
  3. Subdomain-based PSIs where the AS hosting the PSIs are looked up from the DNS. For this purpose, subdomains can be defined by the operator in the DNS infrastructure.

Depending on the service nature, different mechanisms can be used for configuration and routing of PSIs according to operator preference, see Section 5.4.12 in 3GPP TS 23.228 (V8.8.0).

6.1   Settings for Ad-hoc Conferencing Service

The Ad-hoc Conferencing service allows the subscribers to start a conference and invite other users (Conference Participants, CPs) to the conference. The Ad-hoc Conferencing service requires configuration of the following entities:

  1. The conference factory - the logical entity responsible for automatically creating a new conference focus on demand from a user agent. The conference factory is addressed by the conference factory URI.

    The mtasConfFactoryUri CM attribute defines the conference factory URI, consisting of a username and a subdomain.

    Example: conference@factory.operator.net

    It is recommended to configure this PSI in the IMS core domain as a subdomain-based PSI.

    The MTAS expects the SIP requests destined to the mtasConfFactoryUri on the port defined by the mtasSipPsiPort CM attribute.

  2. The conference focus - the centralized manager of the conference. The focus is addressed by a conference URI.

    The mtasConfUriPrefix CM attribute defines the username prefix part of the conference URI.

    Example: conf

The mtasConfUriSubdomain attribute defines the subdomain part of the conference URI.

Example: as1.operator.net

The prefix and subdomain, together with a non-configurable and automatically generated number, constitute an entire conference URI, <prefix><auto_number>@<sub_domain>.

In the MTAS implementation, the requests are routed internally from the conference factory to the conference focus. No external configuration is needed for the conference focus URI.

For more information about the CM attributes described in this section, refer to Managed Object Model (MOM).

6.2   Settings for 3PTY Service

The 3PTY service allows a user who is involved in two separate 2-party sessions with another two participants to convert to a 3PTY session by reusing the existing dialogs from the 2-party sessions.

The service is triggered in the MTAS by reception of an initial INVITE that has the Request-URI set to the 3PTY factory URI.

The mtas3ptyFactoryUri CM attribute defines the 3-party factory URI, consisting of a username and a subdomain. For more information, refer to Managed Object Model (MOM).

In the MTAS implementation, the requests to the 3PTY factory URI are handled in the originating MTAS, so no routing is done on the Request-URI. No external configuration is needed for the 3PTY factory URI.

6.3   Settings for Group Call Admission Control

The GCAC Supplementary Service enables the operator to restrict the number of sessions the users in the group are involved in. The group-specific configuration of the GCAC service is stored in user data where the group identity is a Public User Identity (PUI). So, for each group a user must be created in the HSS. This user is a distinct PSI-user. No IFC is to be created for this PSI-user as its purpose is just to hold the group configuration data.

For configuration of the Call Admission Control service in MTAS, refer to MTAS Call Admission Control Management Guide.

6.4   Settings for Single Radio Voice Call Continuity Release 10

The Single Radio Voice Call Continuity service in the SCC AS uses session anchoring to provide VoLTE UE with continuous MMTel call session when it runs out from coverage of the LTE Packet Switched domain, and needs to transfer its call to the Circuit Switched domain. The SRVCC Release 10 anchors the session in the home IMS network but the media is anchored in the serving IMS network in order to provide the VoLTE UE with a fast access transfer.

The registration procedure in SRVCC Rel-10 allows dynamic STN-SR allocation. When the VoLTE moves to another network, then the ATCF of the visited network allocates its own STN-SR for the given VoLTE contact. In that case, SCC AS sends a SIP MESSAGE to ATCF with ATU-STI associated with C-MSISDN of the registering contact on receipt of 3rd Party Registration. The SCC AS also updates the HSS with the new STN-SR / C-MSISDN allocation.

The mtasSrvccAtuSti CM attribute defines the ATU-STI value assigned to the SCC AS node that is used for initiating access transfer using SRVCC. For more information, refer to MTAS SRVCC Management Guide.

7   Dynamic Allocation Configuration

The MTAS does not store user subscription data. Instead the HSS transparent data repository is used as centralized storage of all MTAS data (subscriber service profiles, supplementary services data). This means that there is no resource in a given physical MTAS tied to any subscriber. A given MTAS AS is allocated to a user at IMS registration time.

This dynamic allocation concept brings the following benefits:

This dynamic allocation concept is described in Annex J in 3GPP TS 23.228 (V8.8.0).

The dynamic allocation mechanism for the MTAS is based on DNS.

7.1   DNS Configuration

Dynamic allocation concept, also called resource pooling, is based on DNS look up. This functionality is triggered when the user registers in the IMS network. The S-CSCF always sends requests to the primary node but failover to the secondary when it determines that the primary is down. The subscriber data is then fetched from the HSS by the selected MTAS and cached as long as the subscriber remains registered.

An example of redundancy configuration using Dynamic Allocation concept is shown in Figure 2. For load sharing purposes, DNS is configured to return the IP address of the primary MTAS nodes based on the S-CSCF IP address. This can be achieved with, for example, Split DNS.

Note:  
The existence of such traffic steering feature is DNS implementation dependent.

The fourth MTAS is used as stand-by for the other three primary nodes. DNS is configured to return the IP address of the fourth MTAS as secondary address for all S-CSCF source addresses.

Figure 2   Example of Redundancy Configuration Using Dynamic Allocation Concept

Load sharing can be achieved also by configuring different MTAS nodes for different users in the IFC. If load sharing is achieved through IFC configuration, similar N+1 redundancy scheme is recommended to be used. The DNS returns the IP address of the same stand-by MTAS as secondary address when translating the domain name of any other primary nodes.

7.2   Dynamic Allocation with AS Instance Caching

If the S-CSCF supports AS instance caching, the S-CSCF caches the IP address of the assigned AS and stores it during the IMS registration period of the user.

The S-CSCF always routes the subsequent originating or terminating service requests directly to the assigned MTAS without DNS lookup. The cached instance address is valid during the registration time of the user.

For AS instance caching to work, MTAS must be configured to support the P-Served-User header. For more information, see MTAS SIP Management Guide.

An example of redundancy configuration using Dynamic Allocation concept with AS instance caching is shown in Figure 3.

Figure 3   Example of Redundancy Configuration with AS Instance Caching

The DNS is configured to return the IP addresses of all the MTASs from the AS Pool and CSCF selects the AS based on round-robin providing n+m redundancy.

If CSCF determines that the assigned MTAS is down, it selects the next available MTAS, routes the request, and caches the AS for subsequent request. However for users with group-based MMTel Services, since the services must be delivered by the same MTAS, the IFC for the users must still be configured with dedicated AS.

8   DNS Based Redundancy and Load Sharing of External Server Nodes

When acting as User Agent Client (UAC), the MTAS supports DNS-based redundancy of the next hop SIP server (proxy or User Agent Server (UAS)). MTAS also supports the DNS-based redundancy of the external HTTP servers.

When more than one IP address is received from the DNS, the request is resent to the next address if the connection to the first one cannot be established owing to connectivity problems, or the request encounters time-out.

The queries used on the DNS interface for an external server node depend on how the address of the external server node is configured in MTAS, see Table 1 for more details.

Table 1    Queries on the DNS Interface

Address Type

DNS Query

Redundancy

Load Sharing

IP address

No

No

No

Hostname (port != 0)

A or AAAA

Yes

DNS based

Domain name (port == 0)

Yes

DNS and MTAS-based

The order of the IP addresses used when sending request to the external server nodes, depends on configuration of both of the DNS and of the MTAS.

8.1   SRV Records

The SRV records usually identify host machines serving both load sharing and redundancy purposes. The MTAS internal DNS Resolver first sorts the received SRV records based on their priority, and then execute weighted randomization of the records with same priority according to their weight.

8.2   A/AAAA Records

The A/AAAA records usually identify interfaces of a host machine serving both redundancy purposes. The MTAS internal DNS Resolver does not rotate A/AAAA records. However, the DNS servers can include a configuration option to rotate the A/AAAA records at each DNS query. To rotate the addresses for each traffic session, the TTL of the A/AAAA record must be set to 0; this way the DNS Resolver is forced to query the DNS for each new session to the external node.

8.3   Actual IP Address List of an External Server

The MTAS services are receiving a full list of IP addresses of an external server from the DNS Resolver (after all applicable SRV and A/AAAA queries) for each new session. The MTAS services are using the IP addresses, considered to be reachable, in the same order as received from the DNS Resolver.

When an address is considered to be not reachable at that moment of the session setup, it is moved to the end of the list.

For more information on the MTAS configuration of the DNS-based redundancy, refer to the following documents:

9   Configuration of Differentiated Services (DiffServ)

The MTAS supports Differentiated Services Code Point (DSCP) marking of the outgoing SCTP and SIP messages. The DSCP is the six most significant bits of the (former) IPv4 TOS octet or the (former) IPv6 Traffic Class octet. It is used to identify the level of service a packet receives in the network. All routers in the DiffServ domain must be configured to be able to deal with the DSCP and provide the desired Per-Hop Behavior.

For configuration of the DSCP marking value in the MTAS, refer to the following documents:

10   User Provisioning

This section describes user provisioning.

10.1   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 user.

10.1.1   IMS Subscription Administration

The IMS Subscription Administration configures the subscriber. The subscriber is the entity responsible for the payment of the charges applied to the associated users.

The following attribute is provisioned for a subscriber:

10.1.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:

10.2   Provisioning in MTAS

The user provisioning in the MTAS 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 uses SOAP to format the interface into messages. SOAP messages are carried by HTTP methods.

The Sh interface is used to access storage on the HSS. The MTAS 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 well-formed XML. For details on Sh interface, see Section 3.2 Sh Interface.

11   Deployment Dependent Configurations

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

11.1   AS Controlled Forking

The AS Controlled Forking feature makes it possible for other MTAS services to address specific terminals of the served user registered with the same IRS with the help of the terminal selectors.

The AS Controlled Forking is based on the following concepts and procedures introduced in RFC 3840 and RFC 3841:

Callee Preferences RFC 3840 (Indicating User Agent Capabilities in the Session Initiation Protocol) defines mechanisms by which a UE can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as feature parameters of the Contact-header field of the REGISTER method. The MTAS supports only the feature tags without values.
Caller Preferences RFC 3841 (Caller Preferences for the Session Initiation Protocol) defines a set of extensions to the SIP which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the preferences of the caller. The MTAS uses only the Accept-Contact header.

The terminal selector is a feature parameter that is used for addressing a single terminal when more than one terminal belongs to the same PUI or IRS. The terminal selector used in SIP signaling by the MTAS consists of two parts; the provisioned terminal selector and the configured terminal selector prefix defined by the mtasMmtTerminalSelectorPrefix CM attribute. For the concepts and configuration of the terminal selectors in relation with the AS Controlled Forking feature in the MTAS, refer to MTAS Target Handling Management Guide.

For use of the terminal selectors by the MTAS services, see the relevant service User Guides.

The AS Controlled Forking feature expects the feature parameters identifying the terminals included in the Contact header field of the REGISTER method.

The feature parameters can be provided by the terminals. If in the actual network deployment the terminals provide the needed feature parameters in the Contact-header field of the REGISTER method, no further configuration is needed in the network.

If the terminals cannot provide the needed feature parameters, a network-based workaround is needed. One example of the network-based workaround is described in Section 11.1.1 Network Based Workaround.

11.1.1   Network Based Workaround

An overview of the example workaround is shown in Figure 4.

Figure 4   Example of Network Based Workaround of Feature Parameter Registration

11.1.1.1   IRS Configuration

It is a common feature of the IMS terminals to allow the selection of the registered public identity.

The IRS that is provisioned for the user in HSS includes both the IMPUs that are used in the session handling as well as the "temporary" IMPUs that correspond to the terminals that Alice owns. These temporary IMPUs are "session barred" in HSS, which means they can be used for registration only. They are not included in the P-Associated-URI list either, which means that the terminals cannot be addressed by using them.

Note:  
The existence of "session barred" IMPU attribute is HSS implementation-dependent.

11.1.1.2   Proxy Configuration

The proxy node in the network extracts either the whole user part or a fragment of the user part from the To-header and inserts it as a feature parameter in the Contact-header.

A prefix can be defined on the network level by the operator, so that the resulting feature parameter is always unique, for example, <prefix>="+g.operator.". If such a prefix is defined in the network by the operator, the same prefix must be configured in the proxy node, and in the MTAS mtasMmtTerminalSelectorPrefix CM attribute.

Note:  
The existence of such a proxy node capable to SIP header modification is deployment-dependent.

The SIP Message Manipulation feature of the Session Border Gateway (SBG) node is capable of such header modification, see the documentation for SBG for further information.

11.2   Originating AS Chaining

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

For more information about Originating AS chaining in MTAS, refer to the following documents:

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).

Note:  
For callout of blue sessions, the maximum number of sessions defined in the MMTel CM Parameter mtasMmtMaxNumberOfSessions must be increased when all Conference Dial-Out requests start originating sessions for the Conference Creator in the originating AS.

11.3   MTAS Services Suppression Based on the INVITE Method

An S-CSCF or an AS before MTAS in the ISC chain can trigger suppression of some selected and configured services in MTAS by providing an INVITE method that contains a header and parameter in pair that matches the regular expression configured in the MtasFsfPattern managed object by the Flexible Service Format Selection (FSFS) service.

For more information about the FSFS service, refer to MTAS Flexible Service Format Selection Management Guide.

When the MTAS services are suppressed, the communication session is processed as if the services were not active.

12   Parameter Value Selection for Deployment Dependent CM Attributes

The deployment-dependent attributes are marked with Access Category "Site Specific" or "Solution Integration" in Managed Object Model (MOM).

Special care must be taken when setting or changing these parameters as coordination with other deployed Network Elements could be necessary. The setting and changing of the attributes marked as "Solution Integration" are normally to be performed by Ericsson trained personnel only.

13   Installation of Additional MTAS Nodes

When installation of additional MTAS nodes is needed for capacity or redundancy reasons, the following external configuration activities are needed:



Copyright

© Ericsson AB 2016, 2017. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.

    MTAS External Network Configuration         MTAS