Contents
1 Introduction
This document describes the interface between the IPWorks and the external SS7 nodes for Local Number Portability (LNP) and Toll Free functions.
Scope
This document describes how IPWorks uses the SS7 protocol to communicate with the Service Control Point (SCP) nodes to perform the LNP and Toll-free queries. IPWorks simulates a Server-Server Protocol (SSP). Only Advanced Intelligent Networks (AIN) LNP and Toll Free related interfaces are covered in this document.
This document covers the following topics:
- Interface Overview
- Interface Role
- Services
- Encapsulation and Addressing
- Procedures
- Information Model
- Error Handling
- Related Standards
Target Groups
This document is intended for the personnel needing to understand the logical entity, including interfaces and protocols, of the IPWorks.
1.1 Prerequisites
N/A
1.2 Related Information
Trademark information, typographic conventions, definition and explanation of acronyms and terminology can be found in the following documents:
- Trademark Information, Reference [1]
- Glossary of Terms and Acronyms, Reference [2]
- Typographic Conventions, Reference [3]
The standard, related to the SS7 interface, can be found in the section Reference List .
2 Interface Overview
This section describes the interface between IPWorks and the external SS7 nodes as shown in Figure 1.
IPWorks includes an External Resolution Handler (ERH) feature that is built into the ENUM server. This provides the possibility to resolve DNS requests in the ENUM zone with respect to number portability with the help of external SS7 legacy databases such as the SCP.
The IPWorks ERH interface with external SS7 nodes is based on Telcordia Specifications as well as some IPWorks specific implementation and deployment, especially regarding the optional parameters processing and some specific messages handling.
2.1 Interface Role
This section describes the role of the AIN in this (SCP)/Adjunct Interface.
AIN is using AINGR: Switch - Service Control Point (SCP)/Adjunct Interface GR-1299 CORE and GR-1298 CORE.
2.2 Services
This section describes the services the AIN uses in this (SCP)/Adjunct Interface.
|
Used Service |
Description |
|---|---|
|
LNP/Toll Free Analyze_Route within AIN |
The SCP provides routing instructions to the IPWorks by returning an AIN Analyze_Route message in the ANSI TCAP response message. IPWorks triggers the service request upon receiving Enum queries which fall into some pre-configured number series, and Analyze_Route reply will be used by IPWorks to compose the Enum response. |
2.3 Encapsulation and Addressing
For SCCP layer routing, both the Signaling Point Code (SPC) + Subsystem Number (SSN) and Global Title Translation (GTT) routing mechanisms are supported. If GTT routing is chosen, the TT default value is 0, but configurable.
This section describes what lower protocols the AIN interface uses:
- TCAP and Signaling System No. 7. For more information about the AIN being transported over TCAP and how the AIN operations make use of TCAP and lower layers of Signaling System No. 7, see Reference [13], Reference [15], Reference [14] and Reference [16].
- SCCP. For the SCCP layer routing, IPWorks supports both the below mechanisms:
- SIGTRAN and T1. IPWorks supports SIGTRAN as the transport vehicle.
3 Procedures
This section describes the procedures used in connection with the used interfaces of SS7.
An overview of the dynamics is shown in Figure 2.
The Advanced Intelligent Network(AIN) is an application that uses the SS7 protocol. The AIN is not a part of the protocol, but relies on the SS7 protocol to provide appropriate capabilities to enable the AIN architecture both at the protocol level and the network architecture level.
As part of the services provided by AIN application, the LNP and Toll Free services depend on the SS7 transport without explicit knowledge of all the underlying levels. They interface directly with TCAP to pass information in the form of components and parameters between nodes.
The SS7 protocol procedures follow the specifications in Telcordia Technologies Research Specification of Signalling SystemNumber 7-GR-246-CORE, Reference [18].
For the SCCP routing procedure, IPWorks currently only support working as a SSP as specified in Local Number Portability Capability Specification: Service Provider Portability-GR-2936-CORE, Reference [13] and Switching and Signaling Generic Requirements for Toll-Free Service Using AIN-GR-2892-CORE, Reference [16].
The typical network configuration is that IPWorks connects to a STP pair and routes to SCPs based on GTT.
Figure 3 shows the typical IPWorks SS7 network configuration.
3.1 Procedures for LNP Related Query
3.1.1 Normal Procedures
3.1.1.1 Successful Query with Database Response Routing
To perform a LNP service query for an ENUM query, perform the following steps:
- IPWorks sends an AIN Info_Analyzed message to the SCP.
- Note:
- The Info_Analyzed message is contained in ANSI TCAP Query with Permission message.
- The SCP provides routing instructions to the IPWorks by returning an AIN Analyze_Route message in the ANSI TCAP response message.
- IPWorks uses the information included in the Analyze_Route message to compose the ENUM response for its client.
Figure 4 shows a successful LNP query:
3.1.2 Abnormal Procedures
This section describes the procedures to handle the messages not expected for the LNP query in a normal case.
3.1.2.1 Unexpected Request_Report_BCM_Event Message Received by IPWorks
When a response from the LNP Database contains an Analyze_Route message along with a Request_Report_BCM_Event message, both of which are contained in ANSI TCAP Conversation with Permission package, IPWorks performs the following steps:
- IPWorks closes the transaction.
- IPWorks sends a Close message with a CloseCause value of unexpectedCommunication to the SCP.
- IPWorks continues the call processing as if the response only contained the Analyze_Route message.
Figure 5 shows the processing procedure for the Request_Report_BCM_Event message.
3.1.2.2 Unexpected Send_To_Resource Message Received by IPWorks
A Send_To_Resource message is not expected to be returned from the LNP SCP.
When a Send_To_Resource message, IPWorks performs the following steps as shown in Figure 6:
- IPWorks ignores the Send_To_Resourcemessage.
- IPWorks processes the Analyze_Route message that follows the same manner as it processes the Analyze_Route message without the intervening send_To_Resource message.
When both a Send_To_Resource and a Request_Report_BCM_Event are received with the Analyze_Route operation, IPWorks performs the following steps as shown in Figure 7:
- IPWorks ignores the Send_To_Resource message.
- IPWorks processes the Analyze_Route message as normal.
- IPWorks sends a Close message with a CloseCause value of unexpectedCommunication to the SCP.
3.1.2.3 ACG Message Received by IPWorks
The Automatic Call Gapping (ACG) message is a network management related message used to protect the SCP from overload.
When an overload occurs, an SCP sends the message to IPWorks. IPWorks does not implement the ACG feature and ignores the message simply.
When a response from the LNP SCP contains an Analyze_Route message with an ACG message, IPWorks performs the following steps as shown in Figure 8:
- IPWorks processes the Analyze_Route message as usual.
- IPWorks ignores the ACG message.
- Note:
- The ACG message has no impact on the processing of other messages, for example, Send_To_Resource, Request_Report_BCM_Event and so on.
3.1.2.4 Send_Notification Message Received by IPWorks
The Send_Notification message can come in any package with Analyze_Route (with or without Request_Report_BCM_Event) or Send_To_Resource.
When a call exists to the NULL PIC because it is disconnected, cleared or not completed, IPWorks performs the following steps as shown in Figure 9:
- IPWorks receives the Send_Notification message.
- IPWorks sends the Termination_Notification message to the SCP in ANSI TCAP Unidirectional message.
- IPWorks ignores the ACG message if the ACG comes with the same Send_Notification message.
When both the Request_Report_BCM_Event and Send_Notification messages are received by IPWorks, IPWorks performs the following steps as shown in Figure 10:
3.1.2.5 Continue Message Received by SSP
When IPWorks receives a Continue response message, it implies that the DN is not ported and is similar to the case where IPWorks receives a Analyze_Route message with the dialled directory number in the CalledPartyID parameter.
- Note:
- In a normal case, this message is not expected for a LNP query.
The Continue message can also be combined with Request_Report_BCM_Event, Send_To_Resource, ACG and Send_Notification.
If the Continue message is sent in an ANSI TCAP conversation message, IPWorks sends an AIN Application_Error message to end the TCAP and AIN transaction as shown in Figure 11.
3.1.2.6 Disconnect Message Received by SSP
When IPWorks receives a Disconnect, it implies that the call must be released and closed according to the AIN. IPWorks will release the call and close the dialogue.
If the disconnect message is sent in an ANSI TCAP conversation message while not in ANSI TCAP Response message, IPWorks send an AIN Application_Error message to end the TCAP and AIN transaction as shown in Figure 12.
3.2 Procedures for Toll Free Related Query
3.2.1 Normal Procedures
3.2.1.1 Successful Query with Database Response Routing
To perform an Toll Free service query for an ENUM query, perform the following steps as shown in Figure 13:
- IPWorks sends an Toll Free Info_Analyzed message to the SCP.
- The SCP provides routing instructions to the SSP by returning an Analyze_Route response message.
The procedure is similar to that for LNP except for different parameters for Info_Analyzed and Analyze_Route.
3.2.2 Abnormal Procedures
This section describes the procedures to handle the messages not expected for the Toll Free query in a normal case.
3.2.2.1 Send_To_Resource Message Received by IPWorks
When the Toll-Free service is not able to respond with routing instructions due to some reasons (for example, the dialled Toll-Free number is unassigned) and instead provides IPWorks with the instructions to play an announcement using the Send_To_Resource message.
IPWorks releases the call and ends the dialogue as shown in Figure 14.
3.2.2.2 Other Messages Received by IPWorks
When IPWorks receives the rest messages, it processes the messages exactly the same way as for the LNP query, for example,
- ACG
- Send_Notification
- Request_Report_BCM_Event
- Disconnect
3.3 General Abnormal Procedures for LNP and Toll Free
3.3.1 TCAP Protocol Error
If a protocol error , either fatal or non-fatal, occurs, it is in any of the following parts of a TCAP package:
- Transaction Portion
- Component Portion
- Dialogue Portion
IPWorks follows the ANSI TCAP protocol errors processing standard, refer to Reference [6].
3.3.2 Fatal Application Error
If the following fatal application errors exist, they are reported and indicated within the ApplicationErrorString parameter carried by the Report_Error message.
The errors are listed as follows:
- Response Message Timer Expired
- Unexpected Message
- Unexpected Message Sequence
- Unexpected Parameter Sequence
- Erroneous Data Value
- Unexpected Communication
- Missing Conditional Parameter
For detailed information about the AIN application layer processing, refer to Reference [7], Reference [8], Reference [9], and Reference [10].
3.3.2.1 Application Error
The received AIN Message X is delivered as a to the TCAP user (IPWorks application). If a fatal application error is detected as listed in Section 3.3.2 , IPWorks sends the error message to the remote SCP.
Figure 15 Application Error Processing
If any AIN message or messages combination meet the following requirements, the message is handled as an unexpected message:
- Any AIN message or AIN messages combination within a TCAP package that is not mentioned in Section 3.1, even if the AIN message appears in a different ANSI TCAP message (for example, Send_To_Resource in a ANSI TCAP Response while not in Conversation with Permission)
The same rule applies to the Toll Free in Section 3.2.
3.3.2.2 Timer T1 Expired
Timer T1 is managed by the TCAP user (The IPWorks application).
When the timer expires, IPWorks reports the error with error string "Response Message Timer Expired" to the SCP according to defined AIN procedures as shown in Figure 16.
- Note:
- The default value for this timer is 3 seconds, and the configurable range is from 0.1 to 30 seconds, with 0.1-second increments.
4 Information Model
This section describes the information model including mandatory and optional parameters of each service operation.
4.1 General
The presence of an information element is defined in the P column in the subsections as follows:
| M | Mandatory | |
| C | Conditional | |
| O | Optional | |
4.2 Info_Analyzed
When IPWorks decides that an LNP or Toll Free query need to be performed, an AIN Info_Analyzed message is sent on a new TCAP dialogue to the LNP capable SCP.
For LNP and Toll Free, though they both use AIN Info_Analyzed message to retrieve the required information, usually the message does not contain the same set of elements. For the specific definition of each element, refer to Reference [10] for detailed information.
4.2.1 LNP Info_Analyzed Message
Table 2 shows the information model of the LNP Info_Analyzed message.
|
Element |
Type |
P |
Comment |
|---|---|---|---|
|
UserID |
Refer to Reference [10] |
M |
Mandatory from AIN protocol point of view |
|
BearerCapability |
Refer to Reference [10] |
M |
Mandatory from AIN protocol point of view |
|
CalledPartyID |
Refer to Reference [10] |
M |
Required by LNP query |
|
TriggerCriteriaType |
Refer to Reference [10] |
M |
Required by LNP query |
|
CallingPartyID |
Refer to Reference [10] |
O |
All the three optional parameters shall be used in the LNP Info_Analyzed message, or none of them. |
|
ChargeNumber |
Refer to Reference [10] |
O |
Required by Toll Free query |
|
JurisdictionInformation |
Refer to Reference [10] |
O |
Required by Toll Free query |
4.2.2 Toll Free Info_Analyzed Message
Table 3 shows the information model of the Toll Free Info_Analyzed message.
|
Element |
Type |
P |
Comment |
|---|---|---|---|
|
UserID |
Refer to Reference [10] |
M |
Mandatory from AIN protocol point of view |
|
BearerCapability |
Refer to Reference [10] |
M |
Mandatory from AIN protocol point of view |
|
CalledPartyID |
Refer to Reference [10] |
M |
Required by Toll Free query |
|
TriggerCriteriaType |
Refer to Reference [10] |
M |
Required by Toll Free query |
|
Lata |
Refer to Reference [10] |
M |
Required by Toll Free query |
|
ChargeNumber |
Refer to Reference [10] |
M |
Required by Toll Free query |
|
ChargePartyStationType |
Refer to Reference [10] |
M |
Required by Toll Free query |
4.2.3 Termination_Notification Message
When receiving a Send_Notification message from the SCP, IPWorks responds with a Termination_Notification message.
Table 4 shows the information model of the Termination_Notification message.
|
Element |
Type |
P |
Comment |
|---|---|---|---|
|
EchoData |
Refer to Reference [10] |
M |
Mandatory from AIN protocol point of view |
|
TerminationIndicator |
Refer to Reference [10] |
M |
Mandatory from AIN protocol point of view |
|
ConnectTime |
Refer to Reference [10] |
O |
Mandatory from AIN protocol point of view |
4.2.4 Close
When receiving a message like Request_Report_BCM_Event, IPWorks sends a AIN Close message to SCP.
Table 5 shows the information model of the Close message.
|
Element |
Type |
P |
Comment |
|---|---|---|---|
|
CloseCause |
Refer to Reference [10] |
M |
It is optional in AIN protocol, but IPWorks always fill the close message with CloseCause = unexpectedCommunication. |
4.2.5 Report_Error
When an application error is detected in a closed TCAP transaction or in a Response Message Timer Expired condition, IPWorks reports the Report_Error message..
Table 6 shows the information model of the Report_Error message.
|
Element |
Type |
P |
Comment |
|---|---|---|---|
|
ApplicationErrorString |
Refer to Reference [10] |
M |
Refer to [3] |
4.2.6 Application_Error
When an application error is detected in an existing TCAP transaction to SCP, IPWorks reports the Application_Error message.
|
Element |
Type |
P |
Comment |
|---|---|---|---|
|
ApplicationErrorString |
Refer to Reference [10] |
M |
Refer to Reference [10] |
4.2.7 Analyze_Route and other messages from SCP
After sending out Info_Analyzed message, IPWorks is expected to receive the Analyze_Route message from the SCP normally. The format of this message and other abnormal messages from the SCP must comply with the definition in Reference [10].
5 Information Elements
For the detailed definition of the elements used in various LNP and Toll Free messages, refer to Reference [10].
6 Error Handling
6.1 AIN LNP/Toll Free Layer Error Handling
Refer to Section 3.3.2 for the error handling at this layer.
6.2 TCAP Layer Error Handling
Refer to Section 3.3.1 for the error handling at this layer.
6.3 Lower Layer Error Handling
Refer to Reference [11] and Reference [12] for the error handling at this layer.
7 Security Considerations
The interface between IPWorks and the external SS7 nodes uses the standard SS7 protocol. IPWorks does not provide any extra security enhancement for the SS7 protocol.
8 Formal Syntax
This section refers to specification where the formal syntax notation is defined. It also describes any deviations from the specification, if applicable.
For information about the formal syntax notation, see the following specification:
- AINGR: Switch - Service Control Point (SCP)/Adjunct Interface- GR-1299-CORE Issue 10, Reference [15]
9 Related Standards
Following standards state the related standards and explain any deviations from them:
- Local Number Portability (LNP) Capability Specification: Service Provider Portability - GR-2936-CORE, Issue 3
- AINGR: Switching Systems- GR-1298-CORE, Issue 10
- AINGR: Switch - Service Control Point (SCP)/Adjunct Interface- GR-1299-CORE, Issue 10
- Switching and Signaling Generic Requirements for Toll-Free Service Using AIN- GR-2892-CORE, Issue 1
- CCS Network Interface Specification (CCSNIS) Supporting toll-Free Service Using AIN - GR-2902-CORE, Issue 1
- Telcordia Technologies Research Specification of Signalling SystemNumber 7- GR-246-CORE, Issue 10
10 Standard Compliance Statement
Following Statement Of Compliances are related to the SS7 interface:
- IPWorks 6.0 SoC to GR-1298,Switching Systems
- IPWorks 6.0 SoC to GR-1299,Switch-SCP/Adjunct Interface
- Functional Specification SCCP
- Function Specification MTPL3&M3UA
Reference List
| IPWorks Library Documents |
|---|
| [1] Trademark Information. |
| [2] Glossary of Terms and Acronyms. |
| [3] Typographic Conventions. |
| PCAT and Other Ericsson Document |
|---|
| [4] IPWorks Statement of Compliance - Telcordia GR-246, Issue 10, T1.111, 18/174 02-AVA 901 16 |
| [5] IPWorks Statement of Compliance - Telcordia GR-246, Issue 10, T1.112, 19/174 02-AVA 901 16 |
| [6] IPWorks Statement of Compliance - Telcordia GR-246, Issue 10, T1.114, 20/174 02-AVA 901 16 |
| [7] IPWorks Statement of Compliance - Telcordia GR-2936, Issue 3, 22/174 02-AVA 901 16 |
| [8] IPWorks Statement of Compliance - Telcordia GR-2892, Issue 1, 21/174 02-AVA 901 16 |
| [9] IPWorks Statement of Compliance - Telcordia GR-1298, Issue 10, 16/174 02-AVA 901 16 |
| [10] IPWorks Statement of Compliance - Telcordia GR-1299, Issue 10, 17/174 02-AVA 901 16 |
| [11] Functional Specification SCCP, 155 17-CAA 901 437 |
| [12] Function Specification MTPL3&M3UA, 155 17-CAA 901 0180 |