How Core Network is Interfaced with Intelligent Network Platform:

Prepared by

Saad Ullah Sheikh

Huawei Technologies Co.,Ltd.

Core Network Engieer

Both Fix Core and Mobile Core Network Switches and MSC have to act as a Service Switching Point to Interwork with Intelligent Network to provide a wide range of Application services.

Normally a core Network engineer knows a lot about ISUP/MAP signaling but less information about TCAP and INAP tracing as a result when some IN service fail it is found difficult to trouble shoot the problem on part of Core Network.

Knowing essentials of INAP and TCAP signaling is thus found important to highlight

The MTP is mandatory to signaling transmission as it is passed through every time the signaling is transferred by any switching node. Therefore, in the case of signaling transmission failure, you should check first whether an MTP device is normal and correctly configured.

INAP, CAP and MAP are all functioning of SCCP over TCAP and transferring their signaling by the use of same TCAP primitive, so correct TCAP configurations are a prerequisite for normal transmission of INAP/CAP/MAP.

At the application layer, INAP, CAP and MAP interact respectively with INAP, CAP and MAP of the opposite office, and they are independent from each other in signaling transmission.

At service layer, since Application Layer depends on Below layers to work correctly so MTP layer down can cause Application layer down also

MTP

INAP

MAP

SCCP

BSSAP

ISUP

Service layer

TUP

MTUP

CAP

TCAP

TCAP configuration in SSP Switch

Since TCAP is borne over SCCP Layer so Configuration of SCCP is mandatory in a SSP

1. SCCP signaling : DPC +SSN

In order to transfer INAP signaling between nodes A and E where they have no direct route to each other but route exists via Nodes B,C,D if we adopt SSN+DPC mode of SCCP Such a message will not be transferred to the SCCP layer in the node B,C,D instead, it is transferred out at the MTP layer transparently. To achieve it, you must label the message with the destination signaling point of Point E and design an MTP route to Point K. So, much work should be done at Point A for MTP data configuration.

2. SCCP Signalling :DPC+GT:

In order to transfer INAP signaling between nodes A and E where they have no direct route to each other but route exists via Nodes B,C,D if we adopt GT+DPC mode then the message can reach Point E, through any point B,C,D .Once a message reach B,C or D it is sent to the SCCP where GT translation is performed and then the MTP DPC is changed. After that, the SCCP sends the message to the next node. The message format may be as shown on the left. In DPC+GT mode every Node must support GT translation to route the call.

Constituents of TCAP

Dialog: A dialog contains TCAP messages sent between two TC users during signaling transmission for an application service.

Primitive: A primitive consists of many TCAP messages. No matter how the user layer changes, it is borne on these primitives.

The component primitive: It is designed for the data at the user layer, whereas the Dialog primitive: is used to indicate the start, continuing, end or abortion of a dialog.

The component primitive is dependent on the dialog primitive, but a dialog primitive may not contain component primitives, for example, tc_u_abort

Dialog Primitive:

A. TC_begin

It marks the start of a dialog. This message contains:

1. Source address (or calling address, different from the Calling in a call service) It shows from which entity the message is sent. Apart from it, you can get the GT of SSP to know the device sending this message.

2. Application context Different application contexts correspond to different operation types. For example, you can determine that the message relates to a CAP operation reported by the MSC/SSP, an ARI operation reported by the AIP, an Execute operation or an MAP ATI through application context.

B.TC_continue The first issued tc_continue contains more source address (address of SCP) and application context than the others. It means a successful service trigger and the dialog proceeds.

C. TC_end It marks the end of a dialog. A tc_end message can be sent with the component primitive or independently. You can judge whether it carries the component primitive by viewing the value of componentPresent. If not, a dialog can be ended on the receipt of this message, otherwise until the component primitive is received.

D. TC_u_abort

This message is sent or received by the SCP. Cause values for the SCP sending this message are as follows:

Abort a call when the SCP is overloaded: abortReason = 1;The SCF finds that dialog IDs repeat: abortReason = 4;

E. TC_p_abort

This message may be sent by the entity passed by rather than the opposite entity. For this message received by the SCP, it is certainly sent from the SAU on the following conditions:

1. The SAU detects that a dialog is set up without a message delivered. 2. Errors occur on this message when it is sent to the SAU. When the SCP receives this message, you should first check whether the SAU generates an alarm or a log. But generally, whether abnormalities occur in previous signaling process is confirmed at first.

F.TC_notice

This message is received by the message sender by the remind of some configuration errors or absence. That is, the messages sent before the receipt of this message are not transferred to the destination. You should check every transmission link especially the SAU.

You can refer to ITU_T Q714 for the explanation to each cause value. For example: 00 0A CB 00 00 B2 10 00 00 B2 10 01 This message is very short and the cause value is the bytes (01) after the dialog ID.

Component primitive

A. TC_invoke

1. This message is a commonly-used component primitive carrying CAP, INAP or MAP messages. It contains operation type (4 types), invokeID, operation ID and specific operations.

2. Knowing operation ID means the corresponding message ID at application layer is obtained, that is, what operation will be performed. Note that different application protocols may have the same ID, for example, “22” is the operation ID of releaseCall of CAP and SendRoutinginfo of MAP. Combined with tc_begin, this message can be used to determine the message ID. Of course, it is easier to judge if you know the entity that sends the dialog. For example, if tc_invoke and IDP correspond to the same dialog ID, it is certain that they are sent from the MSC/SSP and the message is CAP ReleaseCall. If this message is sent to the HLR, it must be MAP SRI.

B.TC_result_lThis primitive is used to get the operation result. Its operation ID is the same with that of tc_invoke.

Most of the response messages is transferred by tc_invoke. For example, the PA with its operation ID of 47 corresponds to SRR operation (operation ID of 49). When a response message matches an operation ID according to specifications, it can be transferred over this primitive (such as (Play Collection) PC and (Activation Test) AT).

C.TC_u_errorWhen signaling transmission fails, you should check whether this primitive is generated and analyze its cause value if it is.

Example: 00 0F 13 00 00 07 71 00 00 07 71 06 00 04 01 00 00 (cause value: 4)

D.TC_u_rejectThis primitive is generated to reject an operation when the TC user receives an incorrect working order. It contains a rejection cause code.

What is a DP:

In order to Act as a SSP a core network switch must provide function of TDP(Trigger Detection point) ,when ever a Intelligent service prefix is dialed if the DP is configured the SSP will trigger the service and transfer the INAP signalling to the Intelligent Network platform for further IN service flow.

For IN Interworking we use DP2 (Collected info) DP3(Analyzed info)

During IN service flow SSP and SCP interact by triggering a DP and returning result to the other side as a response

Inorder to trigger an IN service we only need to configure GT4 and the type of DP triggered are specified as shown in the diagramme below

(Diagramme taken from SCP Trouble Shooting Guide)

A. In addition, this figure gives an illustration of call handling process. For example, if a call connection is established (O_Active), the call data is transferred to the DP9 (onhook), when calling party aborting the call or route selection failure will not occur.

B. The “hole” defined by the specifications is called DP. The SCP instructs the MSC/SSP about what DP information it needs to know, and therefore the MSC/SSP will report to the SCP when call data is transferred to these DPs

O_Null & Authorise _Origination_

Attempt_Collect_Info

DP2

O_Exception

DP9

DP7

Collected_Info

O_Answer

Basic Call transition

Transition beyond Basic Call

DP4

DP5

DP6

O_Disconnect

O_Active

Route_Select_ Failure

O_Busy

O_No_Answer

DP10

O_Abandon

& Alerting

Analyze, Routing

DP50 O_Not_Reachable

CAMEL Detection Point: DP Type

Description:

DP12Terminating_Attempt_Authorised

TDP-R Indication that the T-CSI is analysed.

DP 13 T_Busy EDP-N, EDP-R

Indication that a busy indication is received from the destination exchange

DP 14 T_No_Answer EDP-N, EDP-R

Indication that an application timer associated with the T_No_Answer DP expires

DP15 T_Answer EDP-N, EDP-R

Call is accepted and answered by terminating party

DP17 T_Disconnect EDP-N, EDP-R

A disconnect indication is received from the terminating party or from the originating party.

DP 18 T_Abandon EDP-N A disconnect indication is received from the originating party during the call establishment procedure

DP 51 T_Not_Reachable EDP-N, Not reachable or call

EDP-R establishment failure event can be determined from the HLR or upon a cause IE in the ISUP release message.

DP Type Description

DP2-Information collecting

TDP-R O-CSI is analyzed.

DP4-route selection failure

EDP-R, EDP-N Call setup fails.

DP5-called busy EDP-R, EDP-N Called busy signal is received.ISUP release gives an explanation to why the called party is unreachable.

DP6-No reply EDP-R, EDP-N No-reply timer expires.DP7-Answer EDP-R, EDP-N The called party receives the call.DP9-Onhook EDP-R, EDP-N The calling or called party hooks

on.DP10-Calling abort EDP-N The calling party hooks on during

call setup process.

Important Messages and Fields of an IN call

1. IDP(initial DP)During IN call handling, the IDP is the first operation reported by the SSP to the SCP. It contains nearly all information required by service logic, and the handling of every IN call starts with this operation. To be simple, the IDP provides as much information needed by service logic as it can for the SCP.

2. ServiceKey:

As we know, each service logic is identified with a sole integer, namely ServiceKey (for example: ServiceKey of PPS: 1, ServiceKey of VPMN: 3). Different service logics offer different functions. Use of service via the MS/Telephone needs correct ServiceKey. When debugging, we could not make a call. After tracing the signaling, we found that the MSC/SSP received tc_u_error with the error code of missingCustomerRecord (value: 6) delivered by the SCP right after it reported the IDP. The possible cause might be that a wrong service was triggered. Therefore, these problems must be confirmed:

Whether ServiceKey contained in IDP is the expected value? Whether ServiceKey reported is identical with that we loaded? Whether this service is activated?

3. CalledPartyNumber:

This parameter is used to identify the called party even if it is forwarded, for example, a called number of ISUP. It is sent only for a mobile-terminated call or a mobile-forwarded call.

Note that this parameter is designed for a mobile-terminated call or a mobile-forwarded call. That is, only the IDP of called party contains this parameter. For a mobile-originated call, it is replaced with calledPartyBCDNumber (introduced in the following parts).

When the attributes of such parameters are wrong, it will lead to call failure. Below follows how to get the attribute of called number according to the stream.

IDP stream is as follows:00 79 10 00 00 00 61 00 00 00 61 00 01 FF 00 0001 00 00 00 00 00 64 30 62 80 01 01 82 09 84 1068 31 16 34 54 81 06 83 09 84 13 68 31 53 13……….………The called number is 86136143451860 and Network Indicator isAccording to the called number, the last 7 bits of second character before the true number is the number attribute. Take 0x84 for an example, its number attribute is 4, which signifies an international number. Usually, an international number begins with the country code, and a national number with the area code. For some special numbers, they are unidentified. In service specifications, there is a demand for number attribute.

4.RRBE (Requesr Report BCSM event) In a BCSM, a call process is composed of a series of states, and between these states there are DPs taken as broken points. DPs is set for different call events. To handle a call, the service logic needs to know some of DPs and instruct the MSC/SSP which DPs needing its attention.

a. The SCP issues orders to the MSC/SSP by this operation. During a call process, the RRBE can be delivered many times and each RRBE can be configured with several DPs. The MO or MT process is allowed to support DP events defined by BCSM.

b. Note: Only one oDisconnect event is delivered for a MO process. But as we know, calling onhook process is completely different from called onhook one. For example, when the called party hooks on, the PA will notice the calling party to make another call, but if the calling party hooks on, the call connection must be released. The RRBE contains the parameter legID (value=1: calling

party; value=2: called party). This parameter must be reported together with others.

c. If this message is not delivered, the service logic may be insensitive to some events during call setup (such as calling abort or called busy) and fail to issue correct orders.

5. CTR:a. As we know, PA or P&C of an MSC is for its exclusive use. To ask the MSC to

play announcement to or collect the number of user, the service logic must deliver this message to the MSC/SSP. When this message is delivered, the MSC/SSP would execute this command in a certain period needing no orders more from the SCP, as a connection has been established between the MS and PA resource. PA or P&C ends until the SCP issues the DFC.

b. serviceInteractionIndicatorsTwo in this message. This parameter is not indicated in GSM specifications causing some problems such as number collection failure, generation of common bill during PA. CMCC has defined the value of this parameters in different situations. Please refer to documents. The basic rule is as follows:

c. Value= notRequired(1), if PA is required only d. Value=Required(0), if P&C is required or the AIP is involvede. This message is delivered when PA or P&C is required and a connection between

the MS and PA resource has not been established.6. ETC Different from the CTR, the ETC is used to connect with PA or P&C resource of AIP. When the connection is established, there is a speech path between the MSC/SSP and the AIP via ISUP. This message contains the following parameters:

a. assistingSSPIPRoutingAddress: It indicates the GT code of AIP so that the MSC/SSP can sends signaling to the target AIP.

b. correlationID: It is designed by the SCP manufacturer. Currently, Huawei’ SCP provides logic FSM number. Received this message from the MSC, the AIP reports it to the SCP via ARI, and the SCP locates the logic FSM handling the call by this parameter.

c. scfID: It represents the GT of SCP (8613740441 for example). This parameter is not defined in GSM specifications but described in documents issued by CMCC. At present, bare-bone coding is adopted (tag+len+BCD).

d. serviceInteractionIndicatorsTwo: It is the same with that described for CTR. This message is delivered only when the AIP is required to play announcements and a connection has not been established between the MS and AIP’s resource base.

7.ARI and DFC:AssistRequestInstructions

a. It is used by the AIP to communicate with the SCP after receiving IAI/IAM from the MSC so that the SCP can deliver PA/P&C order in time.

Note: The dialog IDs of ARI and IDP are different as the ARI contains the parameter of tc_begin.

Disconnect Forward Connection a. When PA or P&C is not needed, the SCP delivers DFC to the MSC/SSP for disconnection between the user and specialized resource. b. It contains no parameters, so it is suitable when a connection is established via

CTR or ETC.

8. PA:a. The SCP delivers this message to request the MSC/SSP or the AIP to play

announcement but not collect the number. b. Important parameters:elementaryMessageID: It represents the ID of a speech message. With this parameter, the SCP is able to give an instruction of which announcement will be played. It is an integer of 4 bytes. Defined by CMCC, this parameter consists of service feature code (almost the ServiceKey), language type and speech number. c. Definition of Elementary Message ID:

ServiceKey Language type Reserved Service announcement No.

bit 31 24 23 22 21 16 15 024~31bit: ServiceKey22~23bit: Language type (00: mixed language, 01: Putong Hua, 10: English, 11: dialect)21~16bit: Reserved0~15bit: Service announcement No. Example: For a speech message ID of 0x140007F, the ServiceKey is 1, language type is of Putong Hua and the service announcement No is 127.In addition, it may include several speech message or announcement variables. numberOfRepetitions: maximum announcement times of this messageduration: duration of announcementInterval: interval between two repeated announcementsdisconnectFromIPForbidden: After announcement, the MSC/SSP or AIP releases the connection to the MS by itself when the value of this parameter is “false”. When the parameter value is “True”, the MSC/SSP or AIP needs the instruction from the SCP before releasing the connection. For continual delivery of several PA/P&C, this parameter must be configured to “True” to maintain the connection until the last PA/P&C order is issued (configured to “false”). requestAnnouncementComplete: decide whether the MSC/SSP or the AIP is required to report to the SCP after announcementThe return result of PA is SRR.

9.P and C:Prompt & Collect user information The SCP instructs the MSC/SSP or AIP of playing announcement and collecting the digits the user pressed. P&C parameters include prompt code and requirements for information collection

10. AC:

The charging point is set in the SCP for an IN, so the SCP must know the call duration. Therefore, the SCP sends this message to the SSP to instruct it of getting ready for charging. This message is delivered with related charging information figured out by the SCP according to the home and visited location of user. When the called party answers the call, the SSP starts to collect charging information.

Important parameters:maxCallPeriodDuration: maximum call duration allocated by the MSC/SSP

a. The MSC/SSP reports an ACR when the time is up, but it still maintains the call connection until the SCP issues an instruction (allocating another call duration or releasing the call connection). Why is this parameter necessary? Supposing that the call duration reaches 1 hour, an abnormality occurs at the last time segment. With this parameter, charges to first 45 minutes’ conversation can still be executed, otherwise, charging information generated during that 1 hour will be lost. This parameter can be used to prevent the user sharing an account from overdrawing.

b. tariffSwitchInterval: tariff switch interval Different charging rates may be adopted before or after a specific point of time (for example: 50% discount after 23:00). This message is sent to the MSC for information of time left before that specific point of time, so the MSC can allocate call duration reasonably. This message is not required for a free call or a call not charged by the SCP. Otherwise, it must be delivered upon the call setup or during the conversation.

11. ACR and FCI:The SSP sends to the SCP Apply Charging Report to help the SCP charge a user.

Important parameters:timeInformation: time informationThis parameter represents accumulated time after a reference point (answering point or tariff switch point). It contains tariff switch information. CallActive: whether the calling or called party hooks onWhen the calling or called party hooks on, the SCP delivers ReleaseCall to end the call and release MSC resources directly without receiving ERB event. FurnishChargingInformation This parameter is used to instruct the MSC/SSP of sorting bills. When charging of user at the opposite office is taken over by the SCP, bills generated by the SCP are used for settlement, but the opposite office still generates bills. Therefore, these bills must be sorted out. For example: “800130” is delivered for VPMN services for bill sorting. Bill sorting: FCI is used as the sorting flag in MO process, while genericNumber with the sorting flag of 60 is delivered in Connect for a MT call. Question: Why not use FCI as the sorting flag for a MT call?

12. Continue and connect:Continue The SCP delivers this message to the SSP to continue the suspended call. The SCP delivers this message to the MSC/SSP to continue a call when such parameters as calling number do not change.

Connect When calling or called number changes, this message is sent to the MSC/SSP for information of changes.

Important parameters:destinationRoutingAddress: called number

In such cases that the service logic changes the number B dialed to number C or a user makes a call by dialing “17951+called number”, the service logic delivers only the changed number (number C or called number) to the MSC. The changed number is described by this parameter. Same as the description of calledPartyNumber, the number attributes contained in this parameter always cause errors in the opposite office. Of course, these errors may not occur as the number attribute has been specified in current service specifications.

13.Event Report BCSM 1. The SSP uses this message to report the SCP of call events reserved by the SCP

sending RRBE. 2. Configured with Forward Pending, this message can be used to report forwarding

events and T-busy as defined by new service specifications.

14. Release Call The SCP delivers this message to the SSP to release call resources and end a call.

15. Specialized Resource Report This message is reported to the SCP after PA to inform it of announcement end.

16. ActiveTest 1 When an IN call is set up, the SCP sends this message to the SSP every 6 minutes

to confirm a normal communication. If the SCP does not receive an acknowledgement message from the SSP, it releases all call resources.

2 By the use of this message, resource suspension will not occur.

17. ATI:When the SCF is processing services, it needs to know part of user information such as user state and location. MAP Phase II+ provides AnyTimeInterrogation to meet such a condition. As a result, the SCF can query the state and location of a subscriber at any time by the use of ATI to implement time and cell based charging. User information here includes: 1) User state (Subscriber State) 2) Location (LocationInformation)

1 If the user information is stored, the HLR will return an ATIRes. Otherwise, it sends ProvideSubscriberInfo to the VLR.

2 Currently, to get location information is the most important for service application (when the IDP does not report location information in MT process). Such parameters as vlr_number, locationNumber and cellIdOrLAI are returned.

3 This operation is a dialog initiated by the SCP and the dialog ID is different from that of IDP. It is sent to the HLR the MS registered in. (The GT code is obtained through HLR information provided by the MS, so HLR addressing information needs not be configured in the SCP.)

18 .SRI:1 .This interface between the SCP and the HLR is not defined in specifications. However, the MSRN is needed for some services. So, the SCP pretends to be the MSC and sends SRI to the HLR. 2. The HLR returns the MSRN or forwarded-to number. The MSRN is used to obtain the visited area code or during RBT service implementation for connection. 3. This operation is a dialog initiated by the SCP and the dialog ID is different from that of IDP. It is sent to the HLR the MS registered in. (The GT code is obtained through HLR information provided by the MS, so HLR addressing information needs not be configured in the SCP.)