MTAS Japanese Charging Management Guide
MTAS

Contents

1Introduction
1.1Prerequisites

2
Overview
2.1ICBS
2.2FCH
2.3TDS

3
Subfunctions
3.1Retrieve Location Information
3.2PANI Header Evaluation
3.3SIP Headers Used for ICBS and FCH
3.4AVPs Used for ICBS and FCH for Rf
3.5ICBS and FCH Originating MTAS
3.6ICBS and FCH Terminating MTAS
3.7Fetching and Encoding ICBS and FCH Data
3.8ICBS and FCH Overwrite Mechanism
3.9TDS and FCH
3.10Manage JC
3.11Provisioning Home Location

4
Interaction with Other Services
4.1Communication Barring
4.2Communication Diversion
4.3Ad-hoc Conference Collocated Deployment
4.4Originating AS Chaining
4.5Communication Waiting
4.6Three Parties
4.7Gateway Model

5
JC Service Configuration
5.1JC Administrative State Configuration
5.2Offline Charging Configuration
5.3ICBS Database Configuration
5.4Wholesale for JC Configuration
5.5Service Data Configuration

6
Performance Management

7
Fault Management

1   Introduction

This document describes how to configure the Japanese Charging (JC) service in 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

To enable the service in the MTAS, the JC license must be installed. For more information about the JC license, refer to MTAS Licenses.

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 JC service provides Interconnection Charge Billing System (ICBS) and Flexible Charging (FCH) functionality in MTAS as defined by the Japanese standardization group Telecommunication Technology Committee (TTC), refer to Telecommunication Technology Committee (TTC) Standard JJ-90.10 Inter-Carrier Interface based on ISUP (ISDN User Part). MTAS transfers interconnection charging information per call basis in messages over Session Initiation Protocol (SIP), and stores the data to be sent in Accounting-Requests (ACRs) Diameter messages when offline charging is applicable.

Interconnection charging information is divided into accounting and charging information, as follows:

In IMS and MTAS, the accounting and charging information is transferred in signalling messages over SIP and Rf interfaces.

The JC service also handles FCH data for Telephone Directory Service (TDS).

The JC service only reports charging data for offline charging so no specific data related to JC service is reported for online charging.

If the call is unsuccessful, for instance, the call is barred by MTAS, or the call is rejected by the end user, the available ICBS and FCH data is reported in ACR (EVENT) message.

2.1   ICBS

ICBS is the data between users of the same operator, a concept in the Circuit Switched (CS) network and this concept is now applied to IMS. Users that belong to the same operator but are located in different cities have different ICBS data. It requires accounting information to be transferred on a per call basis in the signalling message over SIP, ISUP, and Bearer-Independent Call Control (BICC). For both originating and terminating MTAS, send the backward and forward ICBS data over the Rf-interface to the charging node.

ICBS is added by MTAS to SIP INVITE (originating MTAS) and 18x/200 responses (terminating MTAS). The ICBS data is determined by originating MTAS when not received in SIP INVITE, and by terminating MTAS when not received in 18/200 OK (INVITE).

2.2   FCH

FCH is only triggered on PSTN to IMS or IMS to PSTN calls between operators, where one is the PSTN network (NTT) in Japan, and the other is a mobile operator in Japan. The FCH data when received in 18x/200 OK (INVITE) is reported over the Rf-interface on originating MTAS and on terminating MTAS when, for example, a Communication Diversion, A→B→C, has taken place and the call leg B→C takes originating behavior.

When Configuration Management (CM) parameter mtasJcBehaviorType is set to "parameters" (1), terminating MTAS can receive FCH in 18x/200 OK (INVITE) response, otherwise it generates FCH, and reports the FCH data in ACR (START) accordingly.

FCH makes it possible for the operator of the terminating network to determine the call charge for calls, or call legs, originating in another network when call charge cannot be determined on basis of the called party number.

2.3   TDS

The number inquiry assistance service is offered by NTT PSTN networks in Japan. TDS can be inquired by Voice over LTE (VoLTE) users through dialing 104. The TDS user is charged based on how many phone-number inquiries the user is verbally asking from the TDS assistant. For each inquiry, a TTC-specific ISUP Charge (CHG) message is sent by TDS. Once sent, this CHG is mapped to an SIP INFO message by Media Gateway Controller (MGC) and then sent to MTAS. When FCH data is present in the SIP INFO message, MTAS reports the FCH data over the Rf-interface by sending ACR (INTERIM) message. MTAS stops the processing of the SIP INFO message and sends 200 OK (INFO) back.

3   Subfunctions

The subfunctions included in the JC service are described in this section.

3.1   Retrieve Location Information

When MTAS performs database lookup to retrieve the ICBS data, Charge Area (CA) and Carrier Code (CC), the location information is needed as it is used as key for the database.

MTAS has the following methods to obtain the location information:

  1. Take the contents from the P-Access-Network header (PANI), as follows:
    • Originating side – taken from incoming INVITE.
    • Terminating side – taken from incoming 18x or 200 OK (INVITE) message.
  2. Check if the Network Provided Location Information (NPLI) is cached in MTAS because of previous fetching from Home Subscriber Server (HSS) for this call. If it is not stored, fetch it from the HSS.

    Only fetched when NPLI required is configured on node level and when no valid NPLI is present in PANI header, see Section 3.2 PANI Header Evaluation for a description of how JC service determines in a valid PANI header.

  3. Use the home location provided by the operator in the common data of users, in the following cases:

When MTAS cannot find any location information at all, the database lookup is not performed. Based on how mtasJcFailureAction is configured, MTAS terminates the call or continues the call without ICBS data in SIP messages and ACR (START).

When ICBS data is not found and mtasJcFailureNotification is enabled, MTAS sends OAM notification: MtasJc, ICBS data not found.

3.2   PANI Header Evaluation

MTAS checks the following in the PANI header before accepting it as valid NPLI:

Example of an accepted PANI header:

Accepted PANI header where ECI is represented as quoted string:

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

Accepted PANI header where ECI is represented as token, for example, none-quoted string:

P-Access-Network-Info:3GPP-E-UTRAN;utran-cell-id-3gpp=
240012F2FABCDEF1;network-provided

3.3   SIP Headers Used for ICBS and FCH

When CM parameter mtasJcBehaviorType is set to "headers" (0), the ICBS data is transported in the SIP messages in the following SIP headers:

When CM parameter mtasJcBehaviorType is set to "parameters" (1), the ICBS data is transported in the following SIP header:

For more information regarding the format of the header, refer to MTAS Interface to CSCF (ISC, Ma, Pw).

3.4   AVPs Used for ICBS and FCH for Rf

When CM parameter mtasJcBehaviorType is set to "headers" (0), the ICBS data transported in the following AVPs over the Rf interface:

When CM parameter mtasJcBehaviorType is set to "parameters" (1), the ICBS data transported in the following AVPs over the Rf interface:

For more information regarding format of the AVP, refer to Diameter Offline Charging in MTAS.

3.5   ICBS and FCH Originating MTAS

For every initial INVITE message received without ICBS data, MTAS retrieves CA and CC from the database and adds it to the outgoing INVITE. The ICBS data, AUC, is read from the configuration parameter mtasJcAdditionalUserCategories and the other ICBS values are fixed. MTAS sends the forward ICBS data in the ACR (START) when originating offline charging is applicable.

When CM parameter mtasJcBehaviorType is set to "parameters" ("1") and initial INVITE message is received with ICBS data, MTAS skips the database lookup and just sends the forward ICBS data received in ACR (START).

For 18x/200 OK (INVITE) messages, MTAS extracts the received FCH and backward ICBS data and sends in ACR (START) when originating offline charging is applicable. Since FCH and backward ICBS data can be received several times in 18x/200 OK messages, an overwrite mechanism is implemented as described in Section 3.8 ICBS and FCH Overwrite Mechanism. The overwrite mechanism is applicable per dialog and the data from the dialog, answered through 200 OK (INVITE), is reported in offline charging.

3.6   ICBS and FCH Terminating MTAS

For every INVITE message received, MTAS extracts the forward ICBS data and sends it in ACR (START) when terminating offline charging is applicable.

Terminals are assumed to comply with IR.92, refer to GSMA PRD IR.92 - IMS profile for voice and SMS for more details, hence Supported: 100rel is included in INVITE sent to MTAS. Supported: 100rel or Required: 100rel is used to indicate to the terminating side that reliable responses can be sent to MTAS, ICBS, and FCH can be passed reliably through the network.

MTAS is covering the case when supported: 100rel is missing in the INVITE by sending ICBS in 200 OK (INVITE), when no reliable 18x responses have been sent. Some other nodes, for example, MGC can prefer to receive ICBS in 18x reliable responses and therefore support of IR.92 is preferred.

Backward ICBS data is added to all unreliable 18x responses until first reliable 18x response is received, when no reliable response received or 200 OK (INVITE) is the first response, the backward ICBS is added to the 200 OK (INVITE).

Responses generated by MTAS undergo the same logic as for received responses. MTAS adds ICBS data again for responses received on a new SIP dialog even if ICBS data has been sent reliably to the originating network. This is the case, for example, when the C (diverted user) responds with 18x and MTAS forwards this response to the originating network from the terminating MTAS of B (redirecting user), this response is then using another dialog than the responses sent from B.

MTAS retrieves ICBS data, CA and CC, by doing a database lookup when ICBS data is missing from first received 18x/200 OK (INVITE) response. MTAS adds the retrieved ICBS data to 18x/200 OK (INVITE) before forwarding the response to the originating network. The ICBS data, AUC, is read from the configuration parameter, mtasJcAdditionalUserCategories, and the other ICBS data is fixed. Forward ICBS data is set in INVITE sent to the redirection (transit) target. Same CA, CC, and AUC are used for backward ICBS data but some of the fixed ICBS data is set differently for forward ICBS data.

When CM parameter mtasJcBehaviorType is set to parameters (1) and 18x/200 OK (INVITE) response is received with ICBS and FCH data, MTAS skips the database lookup and just saves the received ICBS and FCH data for latter ACR (START) report.

When terminating offline charging is applicable, the backward ICBS data is sent in ACR (START) for call leg A→B together with the forward ICBS data received in the INVITE.

The forward ICBS data sent in INVITE to the transit target, is sent in ACR (START), when originating offline charging is applicable, for call leg B→transit together with backward ICBS and FCH data received in 18x/200 OK (INVITE) messages from the transit target.

When CM parameter mtasJcBehaviorType is set to "headers" (0) FCH data is not reported in ACR (START) on the terminating MTAS, only for B→transit call leg where originating behavior is applicable.

When CM parameter mtasJcBehaviorType is set to "parameters" (1), the terminating MTAS generates FCH data if ICBS data is not received in 18x/200 OK (INVITE) response, and reports FCH data in ACR (START).

3.7   Fetching and Encoding ICBS and FCH Data

The CA and CC are fetched by MTAS by doing a database lookup. The Managed Object Class (MOC) MtasCommoDataAccNetwTypeAccInfo matching the location information of the subscriber is fetched and the first item in the attribute list mtasCommonDataAccNetwTypeAccInfoApplSpecificData starting with ICBS is read ICBS&5digits&4digits, for example, ICBS&98000&1006. The five digits after the first & represents the CA and the four digits after the second & represents the CC which is part of the CARI data.

Each CA is associated with a CC, and several CAs can share one CC.

The key for database lookup is derived from the location information of the subscriber, that is received in the PANI header as ECGI (Mobile Country Code (MCC), Mobile Network Code (MNC), Tracking Area Code (TAC), Cell-Id). The TAC value is set to 0000 by the MTAS before querying the database.

The complete key used to find correct MtasCommoDataAccNetwTypeAccInfo takes the following appearance: <access type>&<MCC><MNC><TAC><Cell ID/ECI>, the key must be configured in capital representation (A-F) hex string format for the ECGI part.

For example, for the location information 3GPP-E-UTRAN&24001A123B123456, the key used is 3GPP-E-UTRAN&240010000B123456. The MtasCommoDataAccNetwTypeAccInfo must be configured with TAC value set to 0000 in the key.

Note:  
When the key is configured in this way, other services, for example, DNM, MRF Access MAP in Media Control, and CSI, if they share MOC instances with Japanese Charging service, does not work because of the TAC value masked in the key.

The syntax – headers used in the subsection headings indicates that CM parameter mtasJcBehaviorType is configured to ‘headers’ (0), while – parameters indicates mtasJcBehaviorType is configured to parameters (1).

3.7.1   Charge Area

This section describes the charging area.

3.7.1.1   Charge Area – Headers

The five digits long CA fetched from the database are added to P-Area-Info header, for example, when CA retrieved from database is 98000:

P-Area-Info:98000

For more details regarding encoding of P-Area-Info header, refer to MTAS Interface to CSCF (ISC, Ma, Pw).

3.7.1.2   Charge Area – Parameters

The 5-digit long CA fetched from the database is added as one parameter in ttc-charging-params extension of PCV header, for example, when the CA retrieved from database is 98000 the parameter is: cai=98000

3.7.2   Carrier Information

This section describes the CARI.

3.7.2.1   Carrier Information – Headers

The 4-digits long CC fetched from the database are added to X-Carrier-Info header and other values in the header are hard-coded as described:

Example of the X-Carrier-Info header when MTAS is in originating role and the CC retrieved from the database is 1006:

X-Carrier-Info:00fb05fe03000160

Example of the X-Carrier-Info header when MTAS is in terminating role and the CC retrieved from the database is 1006:

X-Carrier-Info:00fc05fe03000160

For more details regarding encoding of the X-Carrier-Info header, refer to MTAS Interface to CSCF (ISC, Ma, Pw).

3.7.2.2   Carrier Information – Parameters

MTAS sets the parameters when it generates the CARI part of ICBS.

The CC is retrieved from the CM attribute mtasCommonDataAccNetwTypeAccInfoApplSpecificData.

Originating example: cari=iecind-0, cat-olec, code-1006

Terminating example: cari=iecind-0, cat-tlec, code-1006

3.7.3   Additional User Category

This section describes the AUC.

3.7.3.1   Additional User Category – Headers

The originating MTAS sets the Originating Additional User Category (OAUC) and the terminating MTAS sets the Terminating Additional User Category (TAUC) in the X-AUT header. The AUC value is configurable using mtasAdditionalUserCategories and is read when MTAS must set the AUC value. The configuration parameter includes the two AUC types for mobile service, Type 1 and Type 2. Refer to MTAS Interface to CSCF (ISC, Ma, Pw) for more details on configuration parameters.

Only one configuration parameter is used for both values, as follows:

The X-AUT header takes the same appearance even if MTAS is in originating or terminating role since it is the same configuration that is being read, for example:

X-AUT:fd01fc06

For more details regarding encoding of the X-AUT header, refer to MTAS Interface to CSCF (ISC, Ma, Pw).

3.7.3.2   Additional User Category – Parameters

The AUC values are read from the CM parameter mtasJcAdditionalUserCategories, where the default value is mobile_1-1;mobile_2-8. Every semicolon-separated value is read and set in a separate AUC parameter in the PCV header. The CM parameter format is: type_x_auc_value;type_x_auc_value. For example, when default value is used: auc=mobile_1-1;auc=mobile_2-8

3.7.4   Forward Call Indicator

This section describes the Forward Call Indicator (FCI).

3.7.4.1   Forward Call Indicator – Parameters

This is valid when mtasJcBehaviorType is set to parameters (1). FCI as part of ICBS data consists of the following parameters, and it is only set for INVITE in forward direction by Originating MTAS:

Example: fci=nii-nat, oa-isdn

3.8   ICBS and FCH Overwrite Mechanism

When the same parameter is received once again within the same dialog, the parameter overwrites the earlier received parameter. Exception to this rule is the reception of Charge Information (CI) parameter with units per time period value no indication or charge rate information category with value no flexible charge rate information. In this case, the newly received CI parameter is discarded and a possible earlier received value stays valid.

The reception of a new CARI parameter indicates that the previously received ICBS information Terminating Local Exchange Carrier (TLEC), Interexchange Carrier (IEC), Chosen Interexchange Carrier (CIEC), Terminating Charge Area (TCA), Terminating Additional User Category (TAUC), and CI is no longer valid. All received Service Control Point Carriers (SCPCs) are always valid and not overwritten.

When 18x/200 OK (INVITE) is received on multiple/different dialogs MTAS keeps track of the different ICBS and FCH data, and applies overwrite logic within one dialog. When 200 OK (INVITE) is received, MTAS only reports ICBS and FCH in ACR (START) for the answered dialog.

For Backward Call Indicator (BCI), the latest received BCI parameters are valid regardless if a new CARI parameter has been received before. In other words, the latest received BCI parameter that is not empty always overwrites the previous BCI. This case is only applicable when the CM mtasJcBehaviorType is set to parameters (1).

3.9   TDS and FCH

When the JC service is executed on originating MTAS, MTAS receives a SIP INFO message within an ongoing session with the X-CHGInfo header present in the SIP INFO message, MTAS terminates the SIP INFO message and replies with 200 OK (INFO). MTAS generates an ACR (INTERIM) message to report the FCH data by populating the Flexible-Charging-Info AVP with the received X-CHCInfo header, when originating offline charging is applicable.

3.10   Manage JC

It is possible for the O&M operator to configure the JC service to enable or disable the service when the license is present and valid.

3.11   Provisioning Home Location

When NPLI cannot be found in PANI or from HSS, the provided home location is used and must provision, see Section 5.5 Service Data Configuration.

4   Interaction with Other Services

This section describes how the JC service interacts with other services. The ICBS logic in this section refers to subfunctions described in sections from Section 3.1 Retrieve Location Information through Section 3.9 TDS and FCH.

Note:  
The NPLI logic is not part of the ICBS logic in principle, that is, even when no ICBS logic is performed the NPLI logic can still be performed as a separate function.

4.1   Communication Barring

This section describes the Communication Barring.

4.1.1   Incoming Communication Barring

When Incoming Communication Barring (ICB) for Dynamic Black List (DBL) and Anonymous Communication Rejection (ACR) are configured with established session announcement, MTAS sends 183 Session progress followed by 200 OK (INVITE) instead of SIP error response. This response triggers JC service to fetch and add backward ICBS to the generated 183 session progress. This option is a terminating use case and no PANI header is available as no 18x is received from B. Therefore MTAS sends Sh-pull to HSS to fetch NPLI when terminating NPLI is enabled, or use the provided home location. The backward ICBS is not repeated in 200 OK (INVITE) since it is sent in a reliable 183 response already.

When barring service is not configured with established session announcement, a SIP error response is sent when ICB is active instead of the 183 response followed by 200 OK and MTAS does not execute the ICBS logic.

4.1.2   Outgoing Communication Barring

When a call is barred by Outgoing Communication Barring (OCB), the INVITE does not leave orig-MTAS and the ICBS data is not added by MTAS. The available ICBS and FCH data is reported in ACR (EVENT) message.

4.2   Communication Diversion

MTAS Communication Diversion (CDIV) executes the term-MTAS JC functionality for the B-user on the leg (A→B). For the new diverted call leg (B→C), the same MTAS executes orig-MTAS JC functionality for B-user.

This option means that for B→C leg, the forward ICBS parameters are derived based on the redirecting user (B) instead of the calling user (A). As for the A→B leg, the backward ICBS parameters are derived based on the redirecting (served) user (B).

If there is diversion without SIP signalling to the B target, for example, CDIV unconditional or when no PANI header received in 18x from B, the NPLI is queried from the HSS when NPLI originating is enabled. Otherwise the provided home location is used. For CDIV without SIP signalling towards B, the Sh-pull towards HSS and database lookup for ICBS is done when INVITE is received in term-MTAS, to get forward ICBS for B to include in INVITE sent to C.

The redirecting MTAS ensures the following:

CDIV use cases without SIP signalling to or from the B-target, where Sh-pull to retrieve NPLI is sent and the ICBS database lookup is done when INVITE is received in term-MTAS, are as follows:

For the other CDIV cases, a response from B is received and MTAS can check whether PANI header is available and use that NPLI when available. Sh-pull is triggered when no network-provided PANI header is available in the 18x and the ICBS database lookup is done when 18x is received from B. When 18x has ICBS data that is not complete (that is, missing Charge Area or Carrier Code), it is not changed but later the 181 Call Is Being Forwarded response message is updated with complete ICBS data.

4.3   Ad-hoc Conference Collocated Deployment

For conference creation, MTAS makes one database lookup for ICBS and uses that data for both forward and backward ICBS data for the Conference Creator. MTAS adds backward ICBS to the generated 200 OK (INVITE) sent as response to the Conference Creator INVITE. MTAS populates the ACR (START) message with forward and backward ICBS based on Conference Creator.

For focus (Conference Creator) to Conference Participant (CP), that is, dial-out, when CP is added to the conference, the focus adds forward ICBS parameter to the INVITE to the CP. The terminating Application Server (AS) for each CP adds its backward ICBS data based on that CP. ACR (START) contains forward ICBS for Conference Creator and backward ICBS for CP. FCH is sent in ACR (START) if received in 18x or 200 OK (INVITE) from CP.

4.4   Originating AS Chaining

After CDIV or Ad-hoc conference CP invite action has been performed, the INVITE message to C (CDIV) or CP is routed to the MMTel Telephony AS of B (CDIV) or CC (conference) again, and trigger originating service execution when originating AS chaining is enabled. This INVITE already contains ICBS data and therefore ICBS logic is not performed.

4.5   Communication Waiting

For the Communication Waiting (CW) interaction with JC, MTAS looks up the backward ICBS data for the call A to B, and for the call C to B; based on the location information of B. If NPLI is enabled, the location information for B is fetched from the HSS for both calls (A to B and for C to B). Both backward and forward ICBS data is reported in the ACR (START) for both calls, in the same way as done for a basic call between two subscribers.

ICBS logic is only performed during the setup of a call. No ICBS logic is performed when B puts A on hold, to answer the waiting call from C or when B resumes the call with A.

4.6   Three Parties

For the Three Party (3PTY) interaction with JC, MTAS looks up forward ICBS data for the call A to B, and for the call A to C based on the location of A. If NPLI is enabled, the location information for A is fetched from the HSS for both calls. Both backward and forward ICBS data is reported in the ACR (START) for both calls in the same way as done for a basic call between two subscribers.

When the 3PTY Conference Creator creates the 3PTY conference by sending the INVITE to originating MTAS, the creator’s (A’s) backward ICBS data is added by MTAS to the 200 OK (INVITE) to the creator. The forward and backward ICBS data for the 3PTY creator is sent in the ACR (START).

4.7   Gateway Model

When Gateway Model (GM) is used, there is only one dialog to the caller, hiding multiple early dialogs. JC sends the ICBS and FCH data multiple times even when GM maps messages to one dialog.

5   JC Service Configuration

This section describes the configuration activities.

The JC service is controlled by the MtasJc Managed Object (MO). An overview of the JC MO structure is shown in Example 1.

Example 1   JC MO Structure

MtasFunction
    |
MtasServices=0
    |
MtasMmt=0
    |
MtasJc=0
Attributes: mtasJcAdministrativeState,
mtasJcBehaviorType,	mtasJcFailureAction,
mtasJcAdditionalUserCategories, mtasJcFailureNotification

JC utilizes the MtasCommonData MOC where MtasCommoDataAccNetwTypeAccInfo is accessed through the MtasCommonDataAccNetwType MOC to find ICBS data in parameter mtasCommonDataAccNetwTypeAccInfoApplSpecificData.

For a definition of configurable MOs and attributes related to the JC service, refer to Managed Object Model (MOM).

5.1   JC Administrative State Configuration

The JC service is enabled by setting the mtasJcAdministrativeState attribute in the MtasJc MO to 1 (Unlocked). If the mtasJcAdministrativeState is set to 0 (Locked), no JC service is provided by the MTAS.

5.2   Offline Charging Configuration

For more information about offline charging in MTAS, refer to Diameter Offline Charging in MTAS.

5.3   ICBS Database Configuration

ICBS database is enabled by configuring MtasCommonDataAccNetwType with key set to access-type, for example, 3GPP-E-UTRAN, and configuring MtasCommoDataAccNetwTypeAccInfo MOCs with ICBS data set in the attribute mtasCommonDataAccNetwTypeAccInfoApplSpecificData.

The key for the MtasCommoDataAccNetwTypeAccInfo MOCs must follow this syntax: <access type>&<MCC><MNC><0000><CellID/ECI> and in capital letters as explained in Section 3.7 Fetching and Encoding ICBS and FCH Data. The access-type must be the same as set in the parent MtasCommonDataAccNetwType, for example, 3GPP-E-UTRAN.

The mtasCommonDataAccNetwTypeAccInfoApplSpecificData is a list and must contain one item representing ICBS data and follow the ICBS&CA&CC syntax.

ICBS must be written in capital letters, CA must be five digits long, and CC must be four digits long see Section 3.7 Fetching and Encoding ICBS and FCH Data.

5.4   Wholesale for JC Configuration

Not applicable.

5.5   Service Data Configuration

This section describes how to configure the service data used by the JC service. No specific service data for JC service is required but the home location in user common data is used by JC service in some situations, see Section 3.1 Retrieve Location Information.

5.5.1   Operator Subscription Level User Common Data Configuration

The operator can provision the home location in user common data, which is used by JC service when no NPLI can be found. Provisioning the home location requires provisioning of other values, which are not used by JC service and can be set to dummy values when user common data is only provided owing to the JC service. See Example 2 for other values that need to set in user common data.

For more information about the CAI3G protocol and XML schema details, refer to MTAS CAI3G Interface.

An example of a CAI3G protocol of how to provision home location by creating User common data with home location set is shown in Example 2.

Example 2   Provisioning Home Location by Creating User Common Data with Home Location Set

<?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:user-common-data>
<mc:ucd-operator-configuration>
<mc:activated>true</mc:activated>
<mc:max-targets>2</mc:max-targets>
<mc:max-device-targets>2</mc:max-device-targets>
<mc:target-device-list>deactivated</mc:target-device-list>
<mc:home-location>P-Access-Network-Info:3GPP-E-UTRAN;
utran-cell-id-3gpp=24001A123AAAAAA1;network-provided
  </mc:home-location>
</mc:ucd-operator-configuration>
<mc:ucd-user-configuration></mc:ucd-user-configuration>
</mc:user-common-data>
</mc:createMMTel>
</cai3g:MOAttributes>
</cai3g:Create>
</soap-env:Body>
</soap-env:Envelope>

6   Performance Management

There are no specific measurements related to the JC service. For MTAS general measurements, refer to MTAS Performance Indicators and Managed Object Model (MOM).

7   Fault Management

Alarms related to the JC service are listed in MTAS Alarm List.

Notifications related to the JC service are listed in MTAS Notification List.



Copyright

© Ericsson AB 2016. 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 Japanese Charging Management Guide         MTAS