Contents
1 Introduction
This document describes how to configure the Number Portability (NP) service 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 basic services in the MTAS, the NP license must be installed.
For more information about the NP 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:
An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
2 Overview
The NP service allows telephony subscribers to keep their telephone number when changing service provider (service provider portability), moving to a new location (location portability), or changing the subscribed services (service portability).
In MTAS, the main function of the NP service is to identify whether the other party's URI (only if it is in either tel URI or embedded tel URI format) is within the original or donor network or has been ported to other network. In case of outgoing communication, the other party is the called party. In case of incoming communication, the other party is either the calling party or the party that diverted or distributed the communication before reaching the served user. If the other party's URI has been ported to other network, the NP service conveys this NP-related information to the charging system.
MTAS plays an announcement to notify the caller that the called party is ported. The reason behind the NP announcement is that the caller may expect different charges than are applied. The NP announcement is played in basic MMTel calls and in Ad-hoc conference scenarios.
The NP service performs the NP lookup of the other party URI by sending a request to DNS/E.164 Number Mapping (ENUM). In case of outgoing communication, the other party is the called party, while in the case of incoming communication, the other party is either the calling party or the party that diverted or distributed the communication before reaching the served user.
The NP function is triggered by SIP INVITE request and the two following types exist:
The NP service for the outgoing communication is started by initial outgoing SIP INVITE. The received SIP INVITE is generated either by another node before MTAS or by another service started before the NP service inside the MTAS. In the typical use case for regular MMTel communication, the SIP INVITE that starts the NP service is generated by the caller. There are also some cases, typically in the transit case, where the SIP INVITE that starts the NP service is generated by another service inside the MTAS. This service is started before the NP service.
The following are examples of services that can generate the SIP INVITE to start the NP service:
- SIP INVITE starts the NP service following the Communication Diversion by Communication Diversion (CDIV) service
- SIP INVITE starts the NP service following the communication distribution by Flexible Communication Distribution (FCD) service
- SIP INVITE starts the NP service following the conference invitation by the conference focus
For more information about the CDIV service, refer to MTAS Communication Diversion Management Guide.
For more information about the FCD service, refer to MTAS Flexible Communication Distribution Management Guide.
For more information about the Ad-hoc conference service, refer to MTAS Ad-hoc Conference Management Guide.
The NP service for the outgoing communication implemented in the Originating MTAS looks up the NP-related information of the called party indicated in the Request-URI header of the SIP INVITE. If the called party's URI is ported to other network, the NP service receives the NP lookup respond containing the rn parameter. Then, the NP service conveys this NP-related information to the charging system. The NP service following the successful NP-related information lookup inserts an indicator into the Request-URI header in the SIP INVITE to inform the next services or nodes that there is no need to perform the NP lookup again.
The NP service for the incoming communication is started by incoming SIP INVITE in the Terminating MTAS. Following the service invocation, the NP service for the incoming communication evaluates the History-Info header of the received SIP INVITE to determine whether the SIP INVITE is received directly from the caller or is received after the Communication Diversion or communication distribution by other party before reaching the served user.
The NP service for the incoming communication implemented in the Terminating MTAS looks up the NP-related information of the calling party indicated in the P-Asserted-Identity header of the SIP INVITE in the case where the NP service receives the SIP INVITE directly from the calling party (regular MMTel communication). If the calling party URI is ported to other network, the NP service receives the NP lookup respond containing rn parameter and then the NP service conveys this NP-related information to the charging system.
For more information about the MMTel service, refer to MTAS MMTel Management Guide.
The NP service for the incoming communication implemented in the Terminating MTAS looks up the NP-related information of the party that diverted or distributed the communication before reaching the served user in the case where the NP service receives the SIP INVITE indirectly from the calling party following the Communication Diversion or communication distribution. If the party that diverted or distributed the communication is ported to other network, the NP service receives the NP lookup respond containing rn parameter. Then, the NP service conveys this NP-related information to the charging system.
For more information about the NP service, refer to IETF RFC 3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview.
For more information about the NP parameters, refer to the following documents:
2.1 Subfunctions
This section describes the following subfunctions:
- Providing NP-related information for outgoing communication
- Providing NP-related information for incoming communication
- Performing NP lookup
- Managing NP
2.1.1 Providing NP-Related Information for Outgoing Communication
This is a subfunction of the NP function that is used to evaluate the received SIP INVITE in an outgoing communication. This subfunction also determines whether to perform an NP-related information lookup, followed by providing the obtained NP-related information to the Charging Server. The handled SIP INVITE of the outgoing communication can be generated by the served user as the caller, other node started before MTAS, or by another service within MTAS (for example, the CDIV service, FCD service, Ad-hoc conference service).
2.1.2 Providing NP-related Information for Incoming Communication
This is a subfunction of the NP function that is used to evaluate the received SIP INVITE in an incoming communication. This subfunction also determines whether to perform an NP-related information lookup, followed by providing the obtained NP-related information to the charging server. The handled SIP INVITE of the incoming communication can be received directly from the caller or received following the Communication Diversion or communication distribution executed in the preceding node.
2.1.3 Performing NP Lookup
This is a subfunction of the NP function that is used to send NP lookup request to the DNS/ENUM server, and then checks and processes the obtained result.
2.1.4 Manage NP
This subfunction makes it possible for O&M operator to configure the NP service to enable or disable the service when the license is present and valid.
2.2 Obtained rn Parameter Process
When the NP service performs an NP lookup to the DNS/ENUM server and the phone number of the other party is ported, the NP lookup response contains an rn parameter. The obtained rn parameter value from DNS/ENUM server can be in global format, local format, or invalid format.
The NP service conveys the NP-related information to the charging system by using the rn parameter value in global format. In the case of NP service for outgoing communication, the outgoing Request-URI contains rn parameter where the value is in global format.
If the obtained rn parameter value from DNS/ENUM server is in local format, the NP service normalizes the value before using it for charging information or for Request-URI modification.
If the obtained rn parameter value from DNS/ENUM server has an invalid format, the NP service does not prevent the call attempt. However, the NP service does not convey any information to the charging system. In the case of NP service for outgoing communication, the NP service adds neither rn parameter or npdi parameter into the Request-URI.
The announcement is selected based on the Routing Number (RN) of the ported user with possibility that no announcement is played for some RN ranges. This is to avoid playing NP announcement to subscribers ported in to the network served by MTAS as well as to suppress NP announcement for virtual RN numbers used in some operator’s network for subscribers ported within the network.
For more information about the NP parameters, refer to the following documents:
2.3 Interaction with Other Services
This section describes how the NP service interacts with other services.
2.3.1 Communication Barring
In the originating MTAS, the NP service is triggered before Outgoing Communication Barring (OCB) service. Therefore, the NP service when triggered by an outgoing communication can perform an NP lookup although the called-party is barred by OCB.
In the terminating MTAS, the NP service is triggered before the Incoming Communication Barring (ICB) service. Therefore, the NP service, when triggered by an incoming communication, can perform an NP lookup although the caller is barred by ICB.
For more information about the Communication Barring service, refer to MTAS Barring and Dial Plan Services Management Guide.
2.3.2 Communication Diversion
In the Transit MTAS, when an incoming communication is diverted by any type of CDIV service, the generated SIP INVITE to the new target starts the NP service if the mtasNpControl attribute is set to either 1 or 3. If started, the NP service performs an NP lookup by using as the input the new target URI if it is either in tel URI or in embedded tel URI format.
For more information about the CDIV service, refer to MTAS Communication Diversion Management Guide.
2.3.3 Flexible Communication Distribution
In the Transit MTAS, when an incoming communication is distributed by FCD service every generated SIP INVITE starts the NP service if the mtasNpControl attribute is set to either 1 or 3. If started, the NP service performs an NP lookup for every distributed target that has either tel URI or embedded tel URI format. Every successful NP lookup is followed by NP-related information conveyance to the charging system.
For more information about the FCD service, refer to MTAS Flexible Communication Distribution Management Guide.
2.3.4 Charging
When the NP service is triggered by an outgoing communication attempt and is followed by successful NP lookup resulting in receiving information that the called party is ported, it generates charging message for originating charging. The charging message includes a service-specific Attribute-Value Pair (AVP) that identifies the type of NP service (in this case, the NP service for outgoing communication), and a Number-Portability-Routing-Information AVP that contains the routing number information.
When the NP service is triggered by incoming communication attempt and followed by successful NP lookup resulting in receiving information that the caller is ported, or the party that diverts or distributes the communication is ported, it generates charging message for terminating charging. The charging message includes a service-specific AVP that identifies the type of NP service (in this case the NP service for incoming communication), and Number-Portability-Routing-Information AVP that contains the routing number information.
For more information about Charging in MTAS, refer to MTAS Charging Management Guide.
2.3.5 Carrier Select and Carrier Select Rn
The NP service for outgoing communication is started before Carrier Select or Carrier Select Rn service. However, the Request-URI containing Carrier Select Code (CSC) in the SIP INVITE is processed by Dialed String Analysis (DSA) in the Number Normalization service, which is started before the NP service.
After the DSA process, the Request-URI header can contain cic parameter if the Carrier Select service is provisioned or rn parameter if the Carrier Select Rn service is provisioned.
When the Request-URI of an initial SIP INVITE contains an rn parameter inserted to be processed by Carrier Select Rn service and it does not contain an npdi parameter, the NP service checks the mtasNpRnBeforeNpLookup attribute value.
If the mtasNpRnBeforeNpLookup attribute is set to 1, the NP service suppresses the NP lookup and does not send any information to the charging system. The SIP INVITE is forwarded as it is without any modification.
However, if the mtasNpRnBeforeNpLookup attribute is set to 0, the NP service removes the rn parameter enclosed in the Request-URI of the initial SIP INVITE and then perform NP lookup. If the response of the NP lookup contains the rn parameter, the charging system is conveyed with the NP-related information. Also, the obtained rn parameter is added into the Request-URI before the SIP INVITE is forwarded to other node.
When the Request-URI of an initial SIP INVITE contains the cic parameter inserted to be processed by Carrier Select service and it does not contain npdi parameter, the NP service performs an NP lookup. If the response of the NP lookup contains rn parameter, the charging system is conveyed with the NP-related information and the obtained rn parameter is added into the Request-URI before the SIP INVITE is forwarded to other node. In this case, both rn and cic parameters appear in the outgoing SIP INVITE.
For more information about the CSRn service, refer to MTAS Carrier Select and Carrier Pre-Select Management Guide.
2.3.6 Carrier Pre-Select and Carrier Pre-Select Rn
The NP service for outgoing communication is started before Carrier Pre-Select or Carrier Pre-Select Rn service.
When the Request-URI of an initial SIP INVITE contains an rn parameter inserted to be processed by the Carrier Pre-Select Rn service and it does not contain npdi parameter, the NP service checks the mtasNpRnBeforeNpLookup attribute value.
If the mtasNpRnBeforeNpLookup attribute is set to 1, the NP service suppresses the NP lookup and does not send any information to charging system. The SIP INVITE is forwarded as it is without any modification.
However, if the mtasNpRnBeforeNpLookup attribute is set to 0, the NP service removes the rn parameter enclosed in the Request-URI of the initial SIP INVITE and then performs NP lookup. If the response of the NP lookup contains the rn parameter, the charging system is conveyed with the NP-related information and the obtained rn parameter is added into the Request-URI before the SIP INVITE is forwarded to the other node.
When the Request-URI of an initial SIP INVITE contains cic parameter inserted to be processed by Carrier Pre-Select service and it does not contain npdi parameter, the NP service performs an NP lookup. If the response of the NP lookup contains the rn parameter, the charging system is conveyed with the NP-related information and the obtained rn parameter is added into the Request-URI before the SIP INVITE is forwarded to other node. In this case, both the rn and cic parameters appear in the outgoing SIP INVITE.
For more information about the CPSRn service, refer to MTAS Carrier Select and Carrier Pre-Select Management Guide.
2.3.7 Ad-hoc Conference
In the conference focus, the NP service is started after the conference service. When the conference service receives an invitation attempt to the participants, after processing and validating the invitation, it generates new SIP INVITEs addressed to invited participants. Thus, every generated SIP INVITE starts the NP service if the mtasNpControl attribute is set to either 1 or 3. If started, the NP service performs an NP lookup for every distributed SIP INVITE message to the participant that has either tel URI or embedded tel URI format. Every successful NP lookup is followed by NP-related information conveyance to the charging system.
For more information about the Ad-hoc conference service, refer to MTAS Ad-hoc Conference Management Guide.
2.3.8 Number Normalization
In the Originating MTAS, the NP service is started after the Number Normalization service. Therefore, the Request-URI header of the SIP INVITE that triggers the NP service has a normalized URI.
For more information about the Number Normalization service, refer to MTAS Number Normalization Management Guide.
3 NP Configuration
The NP service is controlled by the MtasNp MO. An overview of the NP MO structure is shown in Figure 1.
Configurable MOs and attributes related to the NP service are defined in the following documents:
3.1 Configuration Activities
The configuration activities are listed in Table 1.
|
Activity |
Attribute |
|---|---|
|
Enables or disables the NP service. The NP service can be enabled for originating MTAS only, for terminating MTAS only, or for both originating and terminating MTAS. |
mtasNpControl |
|
Configures the behavior of the NP service in originating MTAS following the receipt of SIP INVITE containing the rn parameter without the corresponding npdi parameter whether to perform NP lookup and to convey the NP-related information to the charging system or not. |
mtasNpRnBeforeNpLookup |
3.2 NP Administrative State Configuration
The NP service is enabled by setting the mtasNpAdministrativeState attribute in the MtasNp MO to 1 (Unlocked). If the mtasNpAdministrativeState is set to 0 (Locked), no NP service is provided by the MTAS.
3.3 Wholesale for NP Configuration
The NP service supports Wholesale. NP is configurable on Virtual Telephony Provider level.
Wholesale for NP is activated when the following attributes are set to 1 (Unlocked):
- The vtasNpAdministrativeState attribute in the VtasNp MO
- The mtasNpAdministrativeState attribute in the MtasNp MO
For more information about the Wholesale service, refer to MTAS Wholesale Support Management Guide.
4 Service Data Management
This section describes how to configure the service data.
4.1 Operator Subscription Level Service Configuration
The operator can activate or deactivate the number portability announcement service subscription for the subscriber by setting the user data using the CAI3G protocol. For more information about the CAI3G protocol, refer to MTAS CAI3G Interface.
The data in the operator part of the subscribers XML file must comply with the number-portability-announcement schema as defined in MTAS Service Data Structure. When the activated element is set to "true", MTAS plays an announcement to notify the caller that the called party is ported.
5 Performance Management
For measurements related to the NP service, refer to Managed Object Model (MOM).
6 Fault Management
For alarms related to the NP service, refer to MTAS Alarm List.