Contents

1   Introduction

This document describes how to configure the Global System for Mobile Communications (GSM) Compatible Service Switching Function (SSF) 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   Licenses

To enable the GSM Compatible SSF function in the MTAS, the GSM Compatible SSF license must be installed.

For more information about the GSM Compatible SSF license, refer to MTAS Licenses.

1.1.2   Documents

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

• Ericsson Command-Line Interface User Guide
• Managed Object Model (MOM)
• Signaling Manager User Guide

1.1.3   Conditions

The following conditions must apply:

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

SS7 configuration is performed as described in MTAS SS7 Management Guide.

2   Overview

This document describes the CAMEL Application Part (CAP) support that the MTAS offers to Service Layer applications which make it possible for an application in the Service Layer to influence an MMTel call. The CAP support is based on the 3GPP TS 09.78 v7.1.0 specification.

2.1   Applicable URIs

CAMEL services are only started for calls between Tel URIs and Tel URIs embedded in SIP.

2.2   Limitations in Supported Functionality

Following are the limitations in supported functionality:

• Conditional triggering is not applied. CAMEL services are started for a subscriber that has CAP provisioned.
• MTAS does not support establishing a connection to an assisting SRF.
• Tariff switching during an ongoing call is not supported.
• Advice of Charge using CAMEL data is not supported.
• Play announcement and Prompt and Collect is only supported during call setup, that is, no mid-call announcements or collection is supported.

2.3   Mapping of SIP Request and Responses to CAP Operations

This section describes the mapping of SIP requests and responses to CAP operations, as shown in Table 1.

2.4   Mapping of SIP Headers to CAP Information Elements

This section describes the mapping of SIP headers to CAP information elements, as shown in Table 2.

2.5   Mapping of CAP Operations to SIP

This section describes the mapping of CAP operations to SIP, as shown in Table 3.

2.6   Mapping of CAP Information Elements to SIP Headers

This section describes the mapping of CAP information elements to SIP, as shown in Table 4.

2.7   Other Mappings to CAP Information Elements

2.8   Map Announcements from IN to IMS

To map announcements from the Intelligent Network (IN) layer to IMS, do as follows:

• Copy all announcements used in the IN and configure them in the Media Resource Function Processor (MRFP) or in the Media Resource Function Controller (MRFC) used in IMS, while keeping all their identities.
• Reuse the media server in the IN layer by configuring the address of it in the MTAS. This process requires Mr or Mp support in the IN media server.

For more information about the announcements, refer to MTAS Announcement Management Guide.

2.8.1   Mapping of CAP Information Elements to SIP through Mr

This section describes the mapping of CAP information elements to SIP through Mr as shown in Table 6 and Table 7.

2.8.2   Mapping of CAP Information Elements to H248 through Mp

This section describes the mapping of CAP information elements to H248 through Mp as shown in Table 8 and Table 9.

CAP PlayAnnouncement element mapping to signals "AASB/PLAY".

CAP PromptAndCollect element mapping to signal "AASDC/PLAYCOL".

2.9   Allow IN Service to Keep Control

To allow the IN service to keep control of a call if there is call setup failure, for example, when a called user is busy or not reachable, the value of mtasSipCancel2FinalResponseTimer must be increased from the default value, 5 seconds, to the recommended value 35 seconds. Refer to Managed Object Model (MOM) for more details.

Note:  

The value can be tuned per deployment, 35 seconds is just a recommendation.

2.10   MtasCommonData Configuration to Fetch Location Number

The location number is fetched by the MTAS by doing a database lookup. The mapping is required to be configured by the operator. Details about the configuration can be found in Managed Object Model (MOM).

The Managed Object Class (MOC) MtasCommonDataAccNetwTypeAccInfo matching the subscriber's location information is fetched and the attribute mtasCommonDataAccNetwTypeAccInfoLocNum is read. This attribute contains the location number.

The complete key used to find correct MtasCommonDataAccNetwTypeAccInfo is a concatenation of the access-type part of the PANI header, the character "&" and the access-info part of the PANI header.

2.10.1   Example

PANI header:

P-Access-Network-Info:3GPP-E-UTRAN;utran-cell-id-3gpp=”24001A123B123456”;network-provided

Key used for lookup: 3GPP-E-UTRAN&240010000B123456

If the access-type equals "3GPP-GERAN", MTAS uses the value of the cgi-3gpp element and maps this to a location number using the configuration data in the MtasCommonDataAccTypeAccInfo MOs.

If the access-type equals "3GPP-UTRAN-FDD"or "3GPP-UTRAN-TDD", MTAS uses the value of the utran-cell-id-3gpp element and maps this to a location number using the MtasCommonDataAccTypeAccInfo MOs.

If the access-type equals "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", MTAS uses the value of the utran-cell-id-3gpp element and maps this to a location number using the MtasCommonDataAccTypeAccInfo MOs.

2.11   NPLI Configuration to Fetch Location Information and Location Number

Network Provided Location Information (NPLI) retrieval in MMTel Telephony AS can be enabled to retrieve Location Information from HSS for populating CAPv2 IDP.LocationInformation IE and CAPv2 IDP.LocationNumber IE.

The configuration policy 6 for CM parameters mtasMmtNpliOriginating and mtasMmtNpliTerminating is required. The policy 6 tries a fixed order of domain after considering the registered data. For mtasMmtNpliTerminating, the policy 6 is also the only option to trigger the NPLI when INVITE arrives, which is needed for CAMEL interaction.

In addition, the configuration mtasMmtNpliTerminatingActiveLocationRetrieval can be used together with mtasMmtNpliTerminating policy 6, to decide whether active location retrieval is done, which means paging towards the UE is triggered.

Refer to MTAS CAP Support for details on IDP.LocationInformation and IDP.LocationNumber.

2.12   Applicable Trigger Detection Points

The MTAS supports all Trigger Detection Points in the Originating Basic Call State Machine (O-BCSM) and in the Terminating Basic Call State Machine (T-BCSM), refer to specification 3GPP TS 09.78 v7.1.0 for details.

Refer to MTAS Charging Management Guide for more information.

2.13   Subfunctions

The subfunctions included in the GSM Compatible SSF function are described in this section.

Setting up charging in MTAS is described in MTAS Charging Management Guide and needs be done to enable CAPv2 to send additional charging data.

2.13.1   CAMEL Prepaid Charging

The CAMEL prepaid charging subfunction provides the CAMEL service control over the call duration. If the CM mtasNccCreditAnnouncementName is configured, the configured warning tone is played to the served user 30 seconds before the allowed duration has been reached, if the earlier received CAPv2 Apply Charging (ACH) message included "Release If Duration Exceeded" with a tone parameter.

Note:  

The warning tone is not played when Communication Diversion, CAMEL Diversion, or 3-Party service is executed.

2.13.2   Playing Announcement

The playing announcement is initiated by the CAMEL service and enables the CAMEL service to play announcements to the calling user (caller).

For more information about MTAS announcements, refer to MTAS Announcement Management Guide.

2.13.3   Provisioning Data

If the operator wants to provision a user, with either originating or terminating triggers either the originating-service-key or the terminating-service-key element must be set to the value -1.

Setting the originating-service-key or the terminating-service-key to 0 or a greater value means that IN is to be triggered.

For more information about user provisioning, see Section 3.5 Service Data Provisioning and refer to MTAS CAI3G Interface.

2.14   Interaction with Other Services

This section specifies the service interactions between the MMTel services and services that can be realized in the Service Layer. Generally, it is either the MMTel service or the Service Layer service that is active, which is done by provisioning the user correctly. For example, barring rules for a specific user must only exist in the MMTel or in the Service Layer.

Another example is that if MMTel Communication Diversion (CDIV) is provisioned, then CAMEL diversion is not to be enabled in the Service Layer and conversely.

2.14.1   Abbreviated Dialing

The CAMEL service is started after the Abbreviated Dialing service. Therefore, a short number is translated to a long number before it is handled by the CAMEL service.

For more information about the Abbreviated Dialing service, refer to MTAS Abbreviated Dialing Management Guide.

2.14.2   Address Policing

The Address Policing service is applied when the CAMEL service has translated the dialed number.

For more information about the Address Policing service, refer to MTAS Address Policing Management Guide.

2.14.3   Advice of Charge

No interaction.

2.14.4   AS Chaining

This section describes AS chaining.

2.14.4.1   Communication Diversion

When the Originating AS Chaining is enabled and when CAMEL diversion is triggered, the CAMEL service utilizes the P-Served-User header and the generic parameter of the header to indicate whether O-CSI is applicable. The CAMEL interaction for the diverted call leg is suppressed in terminating MTAS for the diverting user (B) and instead is triggered in the diverting user's (B) AS triggering originating execution.

2.14.4.2   Conference

When Originating AS Chaining is enabled, the CAMEL invocation for MO case for the Conference Participants is triggered where the INVITE to a participant is created, and then when the INVITE is routed to the Conference Creator’s AS again, the CAMEL invocation is not triggered.

2.14.5   AS Interworking

No interaction.

2.14.6   Calling Party Category

If a Calling Party Category is received from the CAMEL service, this value overrides the Calling Party Category value provisioned for this user.

For more information about the Calling Party Category service, refer to MTAS Calling Party Category Management Guide.

2.14.7   Call Return

Originating CAMEL invocation is done for the INVITE sent when the served user wants to call the last user, who called the served user.

2.14.8   Charging Service

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

2.14.8.1   Online Charging

The CAMEL service affects MMTel online charging. The impact depends on which CAP operation is received or sent. The following CAP operations have an impact:

2.14.8.1.1   Initial DP (IDP)

The data used to populate IDP is only sent to charging when CON or CUE is received. The IMSI sent in the IDP is reported in the Subscription-ID AVP.

2.14.8.1.2   Connect (CON)

When the request URI is changed, that is, when New Destination number is received in CON, then the new number is reported in Called-Party-Address AVP for call leg A to B (originating side) and for call leg B to C (terminating side).

When a Calling Party Category is received the P-Asserted-Identity is updated with this value then this is present in the Calling-Party-Address AVP.

2.14.8.2   Offline Charging

The CAMEL service affects MMTel offline charging. The impact depends on which CAP operation is received or sent. The following CAP operations have an impact:

2.14.8.2.1   Initial DP (IDP)

The data used to populate IDP is only sent to charging when CON or CUE is received. The IMSI sent in the IDP is reported in the Subscription-ID AVP.

The generated call referenced number used to populate the call referenced number element in IDP is reported in the GSM-Call-Reference-Number AVP. The MSC address in the IDP is populated with the configured global title in mtasCsiGlobalTitle and is reported in the MSC-Address AVP.

2.14.8.2.2   Connect (CON)

If a CAMEL diversion takes place, the new diversion target is set in the Charging Function. The user B that is diverting the call is reported in the Redirecting-Party-Address AVP.

When Generic Number is configured to replace the number in P-Asserted-Identity and From headers, the Generic number added to P-Asserted-Identity header is reported in the Calling-Party-Address for call leg A to B (originating side) and for call leg B to C (terminating side).

When the request URI is changed, that is, when New Destination number is received in CON, then the new number is reported in Called-Party-Address AVP for call leg A to B (originating side) and for call leg B to C (terminating side).

When a Calling Party Category is received the P-Asserted-Identity is updated with this value then this is present in the Calling-Party-Address AVP. The Ericsson specific AVP IMS-Service-Identity is set to CAMEL_DIVERSION when new number received in CON for the MT case.

2.14.8.2.3   Furnish Charging Information (FCI)

Any free format data received in a CAP FCI is stored in the Service-Specific-Data AVP. Only the latest received free format data received in FCI is reported in the Service-Specific-Data AVP. In case of earlier received FCI, free format data is overwritten.

The value Party To Charge Information element is used as the charged party.

The Service-Specific-Type is set to CAMEL.

2.14.9   Closed User Group

No interaction.

2.14.10   Communication Barring

This section describes the CAMEL service interaction with Outgoing Communication Barring (OCB) and Incoming Communication Barring (ICB).

For more information about the Barring services, refer to MTAS Barring and Dial Plan Services Management Guide.

2.14.10.1   OCB

OCB is performed on the result from the CAMEL service invocation on the originating MTAS, meaning that any New Destination address received from the Service Control Point (SCP) is checked by the OCB service. The same applies on a terminating MTAS for a diverted call.

2.14.10.2   ICB

ICB is performed on the terminating MTAS before CAMEL service invocation.

2.14.11   Communication Completion

A CAMEL service invocation is made on the call leg to the called user.

For more information about the Communication Completion service, refer to MTAS Communication Completion Management Guide.

2.14.12   Communication Diversion

If a CAMEL call diversion takes place, that is, when the SCP sends a new called party number in the CAPv2 CON message, then the MMTel CDIV service is not started. If an MMTel CDIV at Busy or No-Reply service diverts the call, and if the SCP node armed event report with RRB (tBusy or tNoAnswer) before that, the ERB notification is not sent by the CAMEL service.

MTAS triggers CAMEL interaction for the B to C leg (transit) when MMTel CDIV has been done. This is needed when no CAMEL diversion takes place, for example, CUE or CON with the same number is received.

The CAMEL service in MTAS knows when MMTel CDIV is done for Call Forwarding Unconditional (CFU) and populates the IDP. OriginalCalledPartyID, IDP.RedirectingPartyID, and the IDP.RedirectingInformation for MT case. In this case, MTAS assumes that the SCP does not trigger a CAMEL diversion since this prevents the MMTel CDIV to be performed and the data sent in the IDP for MT case is then faulty.

MMTel CDIV triggered for other cases, for example Call Forwarding No Reply (CFNR), the IDP for MT case cannot be populated with redirecting related information since it is sent before the INVITE is sent to B and MTAS does not know if MMTel CDIV is performed.

In case of Communication Deflection, the deflected call is subject to CAMEL control in the same way as for a forwarded call.

If ACH with ReleaseIfDurationExceeded is received in the B-C leg CAMEL session and the CM mtasSsfSupportReleaseIfDurationExceeded is true, the call is released after the last time the slice expires.

For more information about the CDIV service, refer to MTAS Communication Diversion Management Guide.

2.14.13   Communication Waiting

No interaction.

2.14.14   Conference Collocated Deployment

CAMEL interaction is not started for the INVITE sent for conference creation. For the Dial-out case, a CAMEL invocation, based on the O-CSI for the Conference Participant, is done for every outgoing call leg.

For the Move Active Session to Existing Conference case, the original CAMEL sessions are preserved based on the OCSI/TCSI provisioning and the call scenario.

If ACH with ReleaseIfDurationExceeded is received in one CAMEL session and CM mtasSsfSupportReleaseIfDurationExceeded is true, the whole conference is released after the last time slice expires.

Terminating services for a participant, including CAMEL service invocation, is executed as for any terminating call. No specific action related to CAMEL is taken related to that the terminating user is a Conference Participant.

For more information about the conference services, refer to MTAS Ad-hoc Conference Management Guide.

2.14.15   Customized Alerting Tones

If the CAMEL service orders update of the From header, the MTAS passes on the updated From header to the Customized Alerting Tones (CAT) Server.

For more information about the CAT service, refer to MTAS Customized Alerting Tones Management Guide.

2.14.16   Flexible Communication Distribution

One CAMEL invocation is made for the original target, but no CAMEL invocations are made for the outgoing Flexible Communication Distribution (FCD) call legs. If a CAMEL diversion takes place, FCD is not executed.

For more information about the FCD service, refer to MTAS Flexible Communication Distribution Management Guide.

2.14.17   Flexible Service Format Selection

It is not possible to suppress the execution of the CAMEL service by using the Flexible Service Format Selection (FSFS) function.

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

2.14.18   Gateway Model

No interaction.

2.14.19   Generic Announcement

No interaction.

2.14.20   Group Call Admission Control

No interaction.

2.14.21   Hold

No interaction.

2.14.22   Hotline

No interaction.

2.14.23   Identity Presentation

When the CAMEL service invocation results in the reception of a CONNECT message including a Generic Number parameter, this number is included in the display name part of the From and P-Asserted-Identity headers in the INVITE message. If configured, the Generic Number of a CONNECT also replaces the number in From and P-Asserted-Identity headers.

When Identity Presentation is enabled, the OCNIP and CNIP service does not allow presentation of the From and P-Asserted-Identity headers unless CNIP license is available and OCNIP and CNIP is enabled. When Identity Presentation is not enabled the Generic Number is present in the From and P-Asserted-Identity headers when received in CON.

The MTAS uses the values "presentation allowed" and "presentation restricted" for the IDP.CallingPartyNumber.ScreeningIndicator parameter field. If the SIP Privacy header contains any of the values id, user, or header, the MTAS maps this to "presentation restricted". In all other cases, the MTAS uses the value "presentation allowed".

For more information about the Identity Presentation service, refer to MTAS Identity Presentation Management Guide.

2.14.24   Japanese Charging

No interaction.

2.14.25   Malicious Communication Identification

No interaction.

2.14.26   Media Resources and User Interaction

Media resources are known to the MTAS by configuration. These resources exist either in an MRFP or in an MRFC. The protocols used to access the media resources are H.248 if there is an MRFP, or SIP if there is an MRFC.

For more information about the media functions in MTAS, refer to the following documents:

• MTAS Interface to MRF (Mr)
• MTAS H.248 Support

2.14.27   MMTel

No interaction.

2.14.28   Multiple Language

No interaction.

2.14.29   Network Announcement

No interaction.

2.14.30   Network Ringback Tone

No interaction.

2.14.31   Number Normalization

The numbers sent to the CAMEL service in the information elements of the lDP, can, or cannot be in a normalized format. This process enables the CAMEL services like VPN groups to translate the dialed number into a public number.

Numbers received from the CAMEL service is not in a normalized format. The Number Normalization common component must be configured in a way that allows all non-global numbers received from the CAMEL service to be normalized.

For more information about the Number Normalization service, refer to MTAS Number Normalization Management Guide.

2.14.32   Number Portability

A Number Portability analysis is made on numbers received from the CAMEL service.

For more information about the Number Portability service, refer to MTAS Number Portability Management Guide.

2.14.33   Number Translation

The number translation analysis is made on number received from the CAMEL service.

2.14.34   Operator Controlled Transfer

No interaction.

2.14.35   Parlay X

CAMEL interaction is not started when Parlay X is enabled. This is controlled by the NCC transparent data.

2.14.36   Priority Call

No interaction.

2.14.37   Session Transfer to Own Device

One CAMEL invocation is made for the original target, but no CAMEL invocations are made for the outgoing Session Transfer to Own Device (STOD) call legs. If a CAMEL diversion takes place, STOD is not executed.

For more information about the STOD service, refer to MTAS Session Transfer to Own Device Management Guide.

2.14.38   Short Number Dialing

The CAMEL service handles the request URI before it is seen by the Short Number Dialing (SND) service, meaning that the CAMEL service translate a short number into a public number before the SND handles the destination address.

For more information about the SND service, refer to MTAS Short Number Dialing Management Guide.

2.14.39   Subscriber Credit Notification

No interaction.

2.14.40   Supplementary Service Codes

The SSC service handles the request URI before it is seen by the CAMEL service. The SSC is not started on a Follow-on Call.

For more information about the SSC service, refer to MTAS Supplementary Service Codes Management Guide.

2.14.41   Three Party Call

The CAMEL service is executed on the call legs for the three-party participants as for a normal originating or terminating session independently of the three-party execution. No CAMEL service is executed on the call leg for the three-party originator.

For more information about the Three Party service, refer to MTAS Three Party Management Guide.

2.14.42   Unregistered Subscriber Service

No interaction but the CAMEL service is started for unregistered subscribers in the same way as for registered subscribers to handle calls from both 2G/3G access. For LTE/4G access the subscribers are registered to IMS, which is not the case for calls for 2G/3G.

For more information about the subscriber data in MTAS, refer to MTAS Subscriber Data Management Guide.

2.14.43   User Call Admission Control

No interaction.

2.14.44   Video Fallback to Audio

No interaction.

2.14.45   Voicemail Service

No interaction.

2.14.46   Wholesale

No interaction.

3   GSM Compatible SSF Configuration

An overview of the GSM Compatible SSF MO structure is shown in Figure 1.

For configurable MOs and attributes related to the GSM Compatible SSF, refer to Managed Object Model (MOM).

3.1   NCC Configuration

The NCC service is enabled by setting the mtasNccAdministrativeState attribute in the MtasNcc MO to 1 (Unlocked). More configuration activities are listed in Table 10.

3.2   CSI Configuration

The CSI is enabled by setting the mtasCsiAdministrativeState attribute in the MtasCsi MO to 1 (Unlocked), and the mtasSsfCapv2AdministrativeState attribute in the MtasSsf MO to 1 (Unlocked). More configuration activities are listed in Table 11.

3.3   SS7 Configuration

The configuration of the SS7 stack with ETSI INAP, and SCTP is described in MTAS SS7 Management Guide.

3.4   Administrative States for GSM Compatible SSF Configuration

The GSM Compatible SSF is enabled by setting the mtasCsiAdministrativeState attribute, mtasSsfCapv2AdministrativeState attribute, and the mtasNccAdministrativeState attribute in the MtasCsi MO, MtasSsf MO, and the MtasNcc MO to 1 (Unlocked). If the mtasSsfCapv2AdministrativeState attribute, mtasCsiAdministrativeState attribute, or the mtasNccAdministrativeState attribute is set to 0 (Locked), the GSM Compatible SSF is not activated in the MTAS.

3.5   Service Data Provisioning

This section describes how to configure the service data used by the NCC service.

3.5.1   Operator Subscription Level Service Configuration

The operator can activate or deactivate the NCC service subscription for the subscriber by setting the user data using CAI3G protocol through the XDMS. For more information about the CAI3G protocol, refer to MTAS CAI3G Interface.

The following applies:

• NCC CAP-related elements are not to be enabled with NCC Parlay X elements and conversely.
• The activated elements decide whether the user is provisioned with the NCC service or not.
• The gsm-scf-address is the global title to the SCF.
• Originating-service-key identifies the application to trigger in the SCF.
• Terminating-service-key identifies the application to trigger in the SCF.
• Default-call-handling defines how the call is to proceed in case a failure in the CAMEL interaction.
• IMSI is the IMSI for the subscriber and NCC service uses this when IRS does not contain IMSI and when mtasNccImsiBehavior is configured to use this IMSI. Typically used for unregistered subscribers when the IMSI in IRS is blocked on the HSS. If IMSI is not configured in the NCC service data, but IMSI element is present in the subscription element of the User Common Data, the NCC service uses that IMSI.

<?xml version="1.0" encoding="UTF-8"?> <soap-env:Envelope xsi:schemaLocation=
"http://schemas.xmlsoap.org /soap/envelope/../../cai3g/schemas/Soap-Envelope.xsd 
http://schemas.ericsson.com/cai3g1.2/../../cai3g/schemas/ 
cai3g1.2_header-fault-corrected.xsd http://schemas.ericsson.com/mtas/mmtel/cai3g..
/schemas/ mmtel_aggregated_service.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:mc="http://schemas.ericsson.com/mtas/mmtel/cai3g" 
xmlns:cai3g="http://schemas.ericsson.com/cai3g1.2/"> 
<soap-env:Header> 
                <cai3g:SessionId>S1</cai3g:SessionId>
                <cai3g:TransactionId>1</cai3g:TransactionId>
                <cai3g:SequenceId>100</cai3g:SequenceId>
        </soap-env:Header>
        <soap-env:Body> 
                <cai3g:Create>
                        <cai3g:MOType>MMTel@http://schemas.ericsson.com/mtas/mmtel/cai3g</cai3g:MOType>
                        <cai3g:MOId>
                                <mc:publicId>sip:user@telco.com</mc:publicId>
                        </cai3g:MOId>
                        <cai3g:MOAttributes>
                                <mc:createMMTel publicId="sip:user@telco.com">
                                        <mc:publicId>sip:user@telco.com</mc:publicId>                                        
                                        <mc:northbound-call-control>
                                                <mc:ncc-operator-configuration>
                                                    <mc:activated>true</mc:activated>
                                                    <mc:gsm-scf-address>46123456789</mc:gsm-scf-address>
                                                    <mc:originating-service-key>1⇒
                                                    </mc:originating-service-key>
                                                    <mc:terminating-service-key>2⇒
                                                    </mc:terminating-service-key>
                                                    <mc:default-call-handling>release⇒
                                                    </mc:default-call-handling>
                                                    <mc:imsi>2400111</mc:imsi>
                                                </mc:ncc-operator-configuration>
                                        </mc:northbound-call-control>                                        
                                </mc:createMMTel>               
                        </cai3g:MOAttributes>                   
                </cai3g:Create>
        </soap-env:Body>
</soap-env:Envelope>

4   Performance Management

For measurements related to the GSM Compatible SSF, refer to Managed Object Model (MOM).

5   Fault Management

For alarms related to the GSM Compatible SSF, refer to MTAS Alarm List.