In Call Flow

Core INAP in MSC/VLR/SSP andHLR

dn98797611Issue 5-2 en

# Nokia CorporationNokia Proprietary and Confidential

1 (64)

MSCDOCM12NEDM12 Product Documentation

The information in this documentation is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This documentation is intended for theuse of Nokia's customers only for the purposes of the agreement under which the documentationis submitted, and no part of it may be reproduced or transmitted in any form or means without theprior written permission of Nokia. The documentation has been prepared to be used byprofessional and properly trained personnel, and the customer assumes full responsibility whenusing it. Nokia welcomes customer comments as part of the process of continuous developmentand improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, orperformance of the mentioned hardware or software products cannot be considered binding butshall be defined in the agreement made between Nokia and the customer. However, Nokia hasmade all reasonable efforts to ensure that the instructions contained in the documentation areadequate and free of material errors and omissions. Nokia will, if necessary, explain issueswhich may not be covered by the documentation.

Nokia's liability for any errors in the documentation is limited to the documentary correction oferrors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL(INCLUDING MONETARY LOSSES), that might arise from the use of this documentation or theinformation in it.

This documentation and the product it describes are considered protected by copyrightaccording to the applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

Other product names mentioned in this documentation may be trademarks of their respectivecompanies, and they are mentioned for identification purposes only.

Copyright © Nokia Corporation 2003. All rights reserved.

2 (64) # Nokia CorporationNokia Proprietary and Confidential


Core INAP in MSC/VLR/SSP and HLR

Contents

Contents 3

List of tables 4

List of figures 5

Summary of changes 7

1 Core INAP in MSC/VLR/SSP and HLR 91.1 Core INAP in MSC/VLR/SSP and HLR overview 121.2 Call-related Core INAP service switching functions 121.2.1 Core INAP basic call state models 131.2.2 Core INAP BCSM modelling of call scenarios 211.2.3 Triggering in IN 261.2.4 IN user interaction 301.2.5 Call-related Core INAP parameters 311.2.6 Special Core INAP DPs 361.2.7 Feature interworking in Core INAP 371.3 Call-unrelated Core INAP service switching functions 371.3.1 IN Mobility Management 381.3.2 IN Short Message Service 391.3.3 IN Supplementary Services Management 421.3.4 Call-unrelated Core INAP parameters 441.4 Core INAP charging and statistics 451.5 Core INAP � related alarms and clear codes 45

2 Connecting SSP and SCP 492.1 Example of connecting SSP and SCP 53

3 Managing MSC/SSP triggering 553.1 Creating MSC/SSP triggers and service sets 553.2 Connecting MSC/SSP service sets to trigger receiving points 56

Glossary 61



3 (64)

Contents

List of tables

Table 1. Core INAP in MSC/VLR/SSP and HLR overview 12

Table 2. LegIDs for OBCSM 20

Table 3. LegIDs for TBCSM 20

Table 4. Alarms related to Core INAP 46

Table 5. Clear codes related to IN services 46




List of figures

Figure 1. SSP environment 10

Figure 2. IN protocol stack 11

Figure 3. OBCSM for PBX/Trunk-originating calls 15

Figure 4. OBCSM for mobile-originating and forwarded calls 16

Figure 5. TBCSM for PBX-terminating calls 17

Figure 6. TBCSM for mobile-terminating calls (in the VMSC) 18

Figure 7. TBCSM for mobile-terminating calls (in the GMSC) 19

Figure 8. Mobile/PBX/PSTN-originating call 22

Figure 9. PBX-terminating call 22

Figure 10. Mobile-terminating call in GMSC/VMSC 23

Figure 11. PBX call forwarding in the MSC 24

Figure 12. Call forwarding in the GMSC/VMSC 25

Figure 13. SSP-SCP connection and triggering 50



5 (64)

List of figures




Summary of changes

Summary of changes

Changes between document issues are cumulative. Therefore, the latest documentissue contains all changes made to previous issues.

Changes made between issues 5�2 and 5�1

No contents changes.


Editorial corrections.


The name of the document has been changed from Core INAP guide for MSC/VLR/SSP and HLR to Core INAP in MSC/VLR/SSP and HLR . The chapternames and structure of the document have been modified.

Chapter Core INAP guide for MSC/VLR/SSP and HLR overview

The chapter has been removed.

Chapter Core INAP basic call state models, section Core INAP originatingcall state model

TgKey information has been added to PIC 2 in figures OBCSM for PBX/Trunk-originating calls and OBCSM for mobile-originating and forwarded calls . Noteon CLIR has been added.

Chapter Core INAP basic call state models, section LegID numbers

DP15 T_Answer has been added.

Chapter Triggering in IN

Structure of chapter has been modified: Core INAP trigger management andCore INAP triggering criteria added.

Chapter Call-related Core INAP parameters

The following parameters have been added: acr_bef_erb_edp9,answer_from_free_ann and dedicated_in_event_code. The time_trh_checkparameter has been removed.



7 (64)

Summary of changes

Chapter Core INAP charging and statistics

Most of the charging information has been moved to Charging documentation.

Chapter Core INAP � related alarms and clear codes

This chapter replaces Troubleshooting in IN.

Chapter Managing MSC/SSP triggering

This is a new chapter. It includes information about activating triggers, creatingtriggers and service sets, and connecting service sets to trigger receiving points.

Appendix A. References

References chapter has been removed.




1 Core INAP in MSC/VLR/SSP and HLR

The information provided here is meant for operators of the DX 200 Exchangewho use the Core INAP facilities in the MSC/VLR/SSP and the HLR.

Intelligent Network (IN) is a major tool for the operators for creating additionalvalue for circuit-switched telecommunication services as it enables rapidcommissioning of new services and flexible control of existing services. Thisgoal is achieved by moving the service control out of the telephone exchange intoan external entity, the service control point (SCP) containing a database andservice logic programs (SLP).

The IN concept utilises the network elements of the mobile network and INentities. New hardware elements are generally not required as the serviceswitching function is implemented entirely with software.

The SSP environment figure presents the supported interfaces.



9 (64)


Figure 1. SSP environment

Service Switching Point in IN

The Service Switching Point (SSP) enables subscribers to access IN servicesfrom anywhere in the network. The SSP recognises the service requests andcommunicates with the SCP to carry out the requested service. As the SCPcontrols the services, it is possible to implement new services in the networkwithout making changes in the SSP software.

The MSC/SSP contains the following functional entities:

SMSC

SCP

CoreINAP

CoreINAP

MAP

MAP

trunksignalling(e.g. ISUP

CoreINAP

CoreINAP

CoreINAP

CoreINAP

MAP

MAP

External SRP

HLR AC EIR

VLR

MSC SSP

VLR

MSC SSP

ISUP ISUP

SCP




. Call Control Function (CCF) offers the basic call handling functionalitiesfor the Service Switching Function (SSF) by means of the Basic Call StateModel (BCSM).

. The SSF communicates with the Service Control Function (SCF) by usingthe Intelligent Network Application Part (INAP) protocol and with theCCF by using an internal interface. The SSF interprets the instructionsfrom the SCF and commands the CCF to perform the required action. TheCCF also informs the SCF of the call events if requested by the SCF.

. Specialised Resource Function (SRF) takes care of the user interactionsrequested by the SCP, such as announcements and DTMF digit collection.

Figure 2. IN protocol stack

Core INAP applications (for example, SSF and SCF) use an SS7 protocol stackcontaining the following layered structure:

. Core Intelligent Network Application Part (Core INAP)

. Transaction Capabilities (TC)

. Signalling Connection Control Part (SCCP)

. Message Transfer Part (MTP)

Core INAPmessage set

INAP

TC

SCCP

MTP

SSF

Core INAPmessage set

INAP

TC

SCCP

MTP

SCF

Core INAP

SSP SCP



11 (64)


The physical layer implementation is based on the 64 kbit/s signalling time slotsin a 2 Mbit/s PCM link.

Both sides of the applications' communication link are able to negotiate and havethe same capabilities (Application Context negotiation mechanism). Thismechanism enables successful information transfer between implementationswith varying capabilities (for example, in a multivendor environment).

1.1 Core INAP in MSC/VLR/SSP and HLR overview

Table 1. Core INAP in MSC/VLR/SSP and HLR overview

Core INAP descriptions and referentialmaterial

Core INAP instructions

Call-related Core INAP service switching functions. Core INAP basic call state models. Core INAP BCSM modelling of call scenarios. Triggering in IN. IN user interaction. Call-related Core INAP parameters. Special Core INAP DPs. Feature interworking in Core INAP

Connecting SSP and SCP. Example of connecting SSP and SCP

Managing MSC/SSP triggering. Creating MSC/SSP triggers and service sets. Connecting MSC/SSP service sets to trigger

receiving points

Call-unrelated Core INAP service switching functions. IN Mobility Management. IN Short Message Service. IN Supplementary Services Management. Call-unrelated Core INAP parameters

Core INAP charging and statistics

Core INAP � related alarms and clear codes

1.2 Call-related Core INAP service switching functions

For an overview of Core INAP see Core INAP in MSC/VLR/SSP and HLRoverview .




1.2.1 Core INAP basic call state models

The SSF creates an interface to the exchange's call control by means of which theSCF can control call handling. The functioning of call control is described in theBasic Call State Model (BCSM), which is a simplified model of the differentphases of call handling procedures in the MSC or GMSC. The DX 200 MSCimplementation contains the call models for both the originating and terminatingsides.

Note

The same principles apply to CAMEL. However, note the followingterminological differences:

. SSF (Core INAP) �> gsmSSF (CAMEL)

. SCF (Core INAP) �> gsmSCF (CAMEL)

See CAMEL basic call state models .

The components of the BCSM are called Points in Call (PIC), Detection Points(DP), transitions and tasks executed within PICs. A call is modelled in a BCSMas a sequence of these components.

A detection point is a point where call processing is suspended and the phase ofthe call may be reported to the SCF and where instructions from the SCF can bereceived. In a DP, the suspended CCF gives the control to the SSF, which firstchecks if the DP is armed and if the triggering criteria are met. If triggeringoccurs, the SCF may instruct the SSF to change the normal flow of PICs. Iftriggering does not occur, the SSF instructs the CCF to continue call processingnormally to the next PIC.

There are two kinds of detection points, Trigger Detection Points (TDP) andEvent Detection Points (EDP). A statically armed DP (TDP) is armedpermanently. A dynamically armed DP (EDP), on the other hand, is armed by therequest of the SCF during the execution of a service.

An initial inquiry to the SCF is invoked in the TDP, that is, a dialogue betweenthe SSF and the SCF will be started. In the TDP, the processing of the call issuspended until the SSF receives instructions from the SCF. During the dialogue,the SCF can request the SSF to report about the call events by monitoring theEDPs. The SCF also determines whether it only observes events (EDP-N,notification) or if the SSF must wait for a response to the reported event (EDP-R,request).



13 (64)


The relationship between the SSF and the SCF is controlling when either anarmed TDP-R is encountered or when there are one or more dynamically armedEDP-Rs. The relationship is monitoring if there are only dynamically armedEDP-Ns or pending reports. Instructions are not expected from the SCF.

The dialogue between the SSF and the SCF takes place either on the incoming oroutgoing side call control. It cannot be switched from side to side during the call,and the SCF cannot directly monitor or control the procedures on the other side.For example, the SCF cannot set the detection points of the TBCSM underobservation if the dialogue is started on the originating side.

For instructions on how to connect the SSP and the SCP see Connecting SSP andSCP .

Core INAP originating basic call state model

The functions of the incoming call control are described in the OBCSM. In INcalls the SCP may change the normal proceedings. On the originating side, thefollowing BCSMs are implemented: mobile, trunk, PBX and forwarding.

The notes in the BCSM figures are as follows:

. Note 1: whether DP2 is mapped from DP2a or from DP2b depends on thePRFILE parameter 002:419.

. Note 2: if DP2 is mapped from DP2a, then the actions in PIC 2 after DP2aare performed at the beginning of PIC 3.

. Note 3: CLIR handling is done after DP1.




Figure 3. OBCSM for PBX/Trunk-originating calls

PIC 1 O_Null Setup reception, creation of the BCSM.

Get incoming circuit group data, Save TgKey received from circuit group(Trunk calls)

Get PBX data, save TgKey received from PBX data (PBX calls)

CLI screening in PBX-originating call

DP1

PIC 2 Collect_info, see Note 1, see Note 3

Collection of additional digits

DP2a

Short Number AnalysisPre-analysis (for dialled digits)

Save the TgKey received from the Extended preanalysis.

DP2b

DP2

Pre-analysis (for SCP given numbers)

Priority analysis

Short Number Analysis (PBX calls)

CHA attribute analysis, ROU attribute analysis (save possible trigger)

Central Memory analysis to the B-number

Save the TgKey received from the Central Memory.

DP3

Seizure of the outgoing circuit from RMA PIC 4

Start Outgoing CC, Reception of the ACM

Reception of the Answer

DP7

Start the Charging PIC 5

Speech state O_Active

A or B clears the call, stop the charging

A/B clears the call in the speech state

DP9

Clearing actions:

function analysis

Internal Actions

charging information to the SCP

Clearing actions: PIC 6

stop the charging O_Exception

EOS-analysis


DP10

DP8

Only charging limit warning

DP received from the EOS:

DP4 RouteSelectFailure

DP5 Busy

DP6 NoAnswer

Collect info

Collect info

Connect

Connect

Collect info

Connect

PIC 3

Analyse_info

Routing&Alerting

Error condition (not theclearing indicated by A)

A clears, stop thecharging

See Note 2



15 (64)


Figure 4. OBCSM for mobile-originating and forwarded calls

DP1

PIC 2 Collect_info, see Note 1, see Note 3

Collection of additional digits

DP2a

Short Number AnalysisPre-analysis (for dialled digits)

Save the TgKey received from the Extended preanalysis.

DP2b

DP2

Pre-analysis (for SCP given numbers)

CHA attribute analysis, ROU attribute analysis (save possible trigger)

Central Memory analysis to the B-number

Save the TgKey received from the Central Memory

DP3

Barring analysis for MO calls PIC 4

Start Outgoing CC, Reception of the ACM

Reception of the Answer

DP7

Start the Charging PIC 5

Speech state O_Active

A or B clears the call, stop the charging


DP9

Clearing actions:

function analysis

Internal Actions



stop the charging O_Exception

EOS-analysis


DP10

DP8

USSD or charging limit warning

DP received from the EOS:

DP4 RouteSelect Failure

DP5 Busy

DP6 NoAnswer

Collect info

Collect info

Connect

Connect

Collect info

Connect

PIC 1 O_Null

Setup reception, creation of the BCSM

Save the TgKey received from VLR or HLR (EOS for CFUs)

Priority analysis, reservation of speech channel

MOC attribute analysis, Origin analysis

PIC 3

Analyse_Info

Routing&Alerting

See Note 2






Core INAP terminating basic call state model

The functions of the outgoing call control are described in the TBCSM. On theterminating side, the following BCSMs are implemented: mobile, gateway andPBX. The VMSC and the GMSC have separate models but both implement DPsfrom 12 to 18.

Figure 5. TBCSM for PBX-terminating calls

DP12

DP16


Get PBX data

Save the TgKey received from PBX data

Possible CLI enquiry

Start PBX signalling or.. PIC 8

PIC 7

T_Null

..create new leg if "Connect" from SCP Select_Facility

Reception of ACM & Present Call

Reception of the Answer PIC 9

T_Alerting

DP depends on the cause:

DP13 Busy

DP14 NoAnswer

DP15

Speech state

PIC 10

T_Active

A or B clears the call


DP17DP18

Clearing actions: Internal Actions

function analysis

Reports to SCP


T_Exception

Stop charging of the released party


Connect





17 (64)


Figure 6. TBCSM for mobile-terminating calls (in the VMSC)

TDP12 in the VMSC can be set to TDP12 before paging when DP12 has beendefined in the trigger data, or to TDP26 after paging, with the Trigger and ServiceSet Handling MML.

DP12

DP16


VLR Enquiry

Save the TgKey received from the VLR


Start outgoing signalling, if B free or.. PIC 8

PIC 7

T_Null

..create new leg if "Connect" from SCP Select_Facility

Reception of ACM & Present Call


T_Alerting


DP13 Busy

DP14 NoAnswer

DP15

Speech state PIC 10

T_ActiveA or B clears the call


DP17DP18


function analysis

Reports to SCP


T_Exception

Stop charging of the released party

USSD or charging limit warning

Start the charging

Connect

DP12

Paging

DP12






Figure 7. TBCSM for mobile-terminating calls (in the GMSC)

TDP12 in the GMSC can be set to TDP12 before the result of the second HLRinquiry when DP12 has been defined in the trigger data, or to TDP26 after theresult of the second HLR inquiry, with the Trigger and Service Set HandlingMML.

DP12

DP16


Save the TgKey received from the HLR Enquiry


PIC 8

PIC 7

T_Null

Select_Facility

& Present Call


T_Alerting


DP13 Busy

DP14 NoAnswer

DP15

Speech state PIC 10

T_ActiveA or B clears the call


DP17DP18


Reports to SCP


T_Exception

Stop charging


Start the charging

Connect

Make the second HLR Enquiryif required

DP12

Create new leg if "Connect"from SCP

Reception of ACM





19 (64)


LegID numbers

LegIDs are numbered in the following way:

Table 2. LegIDs for OBCSM

OBCSM Incoming lineLegID

Outgoing lineLegID

DP1 Originating_Attempt_Authorized 01 -

DP2 Collected_Info 01 -

DP3 Analyzed_Info 01 -

DP4 Route_Select_Failure 01 -

DP5 O_Called_Party_Busy 01 -

DP6 O_No_Answer 01 -

DP7 O_Answer 01 02

DP8 O_Mid_Call 01 02

DP9 O_Disconnect 01 02

DP10 O_Abandon - -

Table 3. LegIDs for TBCSM

TBCSM Incoming lineLegID

Outgoing lineLegID

DP12 Terminating_Attempt_Authorized 02 01

DP13 T_Called_Party_Busy 02 01

DP14 T_No_Answer 02 01

DP15 T_Answer 02 01

DP16 T_Mid_Call 02 01

DP17 T_Disconnect 02 01




Table 3. LegIDs for TBCSM (cont.)

TBCSM Incoming lineLegID

Outgoing lineLegID

DP18 T_Abandon 02 01

For information on other call-related Core INAP service switching functions seeCall-related Core INAP service switching functions .


1.2.2 Core INAP BCSM modelling of call scenarios

BCSMs are used to model call scenarios. For each scenario, the BCSMs drawnwith a solid line indicate that the relationship with the SCF can take place and isrelevant in this case. The BCSMs drawn with a dashed line indicate that therelationship with the SCF is not relevant or possible in this case.

In some cases these models may have an allocation to physical nodes differentfrom that shown. However, the physical separation of the logic functions showndoes not impact the modelling.

Core INAP may be applied simultaneously and independently for each partyinvolved in a call. This is not shown in these scenarios.

Subscribers other than those being served by Core INAP may be either PSTN/PBX subscribers or other GSM subscribers.

Mobile/PBX/PSTN-originating call

The OBCSM for the call from A to B (labelled "O(A-B)") is invoked if an activetrigger, or triggers, is detected by the originating CCF. One or more relationshipswith SCFs can be created. The SCFs may be in the same or different SCPs.



21 (64)


Figure 8. Mobile/PBX/PSTN-originating call

PBX-terminating call

The TBCSM for the call from A to B (labelled "T(A-B)" in the figure below) isinvoked if an active trigger, or triggers, is detected by the terminating CCF. Oneor more relationships with SCFs can be created. The SCFs may be in the same ordifferent SCPs.

Figure 9. PBX-terminating call

SCF

INAP relationship

MSCSSF/CCF

A-Party

O(A-B) T(A-B)

B-Party

SCF

INAP relationship

MSCSSF/CCF

A-Party

O(A-B) T(A-B)

B-Party




Mobile-terminating call in GMSC/VMSC

The gateway and visited TBCSMs for the call from A to B (labelled "GT(A-B)and VT(A-B)") are invoked if an active trigger, or triggers, is detected by theterminating CCFs. One or more relationships with SCF (1) will be created fromthe gateway TBCSM, and one or more relationships with SCF (2) can be createdfrom the visited TBCSM.

The relationships with SCF (1) and SCF (2) may exist simultaneously. The tworelationships are treated independently in the service logic.

The SCF (1) and SCF (2) may be in the same or different SCPs.

The gateway TBCSM and visited TBCSM may also be in the same MSC. In thiscase the PSTN terminating and PSTN originating CCFs are not created.

The triggers cannot be detected by the roaming originating or PSTN terminatingCCFs.

Figure 10. Mobile-terminating call in GMSC/VMSC

PBX call forwarding in the MSC

The TBCSM for the call from A to B (labelled "T(A-B)") is invoked if there is anactive trigger, or triggers, for the B-party. One or more relationships with SCF (1)can be created.

SCF (1)

INAP relationship

GMSCSSF/CCF

A-Party

O(A-B) GT(A-B)

B-PartyRoam O PSTN T

INAP relationship

VMSCSSF/CCF

PSTN O VT(A-B)

SCF (2)



23 (64)


A new call leg to a C-party is created if a PBX call forwarding supplementaryservice forwards the call to C or if an INAP service in a controlling relationshipwith T(A-B) performs INAP-based call forwarding by using the Connectoperation. In these cases, O(B-C) is invoked for the forwarding party with the B-party originating triggers.

One or more relationships with SCF (2) can be created, if an active trigger, ortriggers, is detected by the forward originating CCF.

The relationships with SCF (1) and SCF (2) may exist simultaneously. The tworelationships are treated independently in the MSC. The BCSM T(A-B) andBCSM O(B-C) are linked by an internal interface.

SCF (1) and SCF (2) may be in the same or different SCPs.

Figure 11. PBX call forwarding in the MSC

In this forwarding case, the B-party is also specified as 'surrogate' in the figure.This should clarify and remind of the fact that the T(A-B)- and O(B-C)-BCSMsand the connected INAP relationships are acting on behalf of the forwarding (B-)subscriber, although the B-party is not connected in the call.

Call forwarding in the GMSC/VMSC

The TBCSM for the call from A to B (labelled "T(A-B)") is invoked if there is anactive trigger, or active triggers, for the B-party. One or more relationship withSCF (1) can be created.

SCF (1)

INAP relationship (2)

MSCSSF/CCF

A-Party

O(A-B) T(A-B)

C-Party

O(B-C) T(B-C)

B-Party"surrogate"

SCF (2)





A new call leg to a C-party is created if a GSM call forwarding supplementaryservice forwards the call to C or if an INAP service in a controlling relationshipwith T(A-B) performs an INAP-based call forwarding by using the Connectoperation. In these cases, O(B-C) is invoked for the forwarding party with the B-party originating triggers.

One or more relationships with SCF (2) can be created if an active trigger, ortriggers, is detected by the forward originating CCF.

The relationships with SCF (1) and SCF (2) may exist simultaneously. The tworelationships are treated independently in the GMSC/VMSC. The BCSM T(A-B)and BCSM O(B-C) are linked by an internal interface.

The SCF (1) and SCF (2) may be in the same or different SCPs.

Figure 12. Call forwarding in the GMSC/VMSC

In this forwarding case, the B-party is also specified as 'surrogate' in the figure.This should clarify and remind of the fact that the T(A-B)- and O(B-C)-BCSMsand the connected INAP relationships are acting on behalf of the forwarding (B-)subscriber, although the B-party is not connected in the call.



SCF (1)


GMSC / VMSCSSF/CCF

A-Party

O(A-B) T(A-B)

C-Party

O(B-C) T(B-C)

B-Party"surrogate"

SCF (2)




25 (64)


1.2.3 Triggering in IN

The SSF starts a dialogue with the SCF on the basis of a trigger . Each IN servicehas its own trigger which contains the data needed to initiate and execute the INservice. For information about triggering criteria see Core INAP triggeringcriteria . For information on CAMEL triggering see Triggering in CAMEL .

The point in the set-up phase where the call control can find a trigger is called atrigger receiving point. A trigger receiving point contains a service set, which cancontain several triggers. When the SSF finds the service set, it saves all thetriggers in it to the internal data structures of the SSP. A trigger can be connected,for example, to the incoming circuit group data. In such a case, the trigger isenabled for a call as soon as call control has received the call from the trunkcircuit, and fetched the circuit data.

Triggering (starting the IN service) may occur when the detection point specifiedin some saved trigger is met. In case several triggers have been activated for somedetection point, several services may be started. It is possible to define prioritiesto triggers to determine what service is started first. Feature InteractionManagement (FIM) introduces the multiple point of control functionality thatallows several SLPs to control the same BCSM at the same time. Thus, it ispossible to have multiple IN service initiations/requests in a single detection pointand multiple simultaneous controlling connections to the SCP. FIM providesstrict rules for arranging and manipulating the services located in a singledetection point.

When triggering takes place, the trigger is disabled. This means that the same INservice is not initiated twice in the same call, provided that, in some triggerreceiving point, the trigger in question is not received again. Note that the pointwhere the call receives a trigger and the actual triggering point are not necessarilythe same.

The DX 200 SSP implements all incoming side detection points with theexception that DP1 cannot be used later in the same call. Thus, DP1 cannot be anevent detection point. On the outgoing side, DP12 cannot be an event detectionpoint.

Triggers are combined into service sets (trigger groups). A trigger key identifiesand points to one service set. Thus, the three elements involved in triggering aservice are: triggers, service sets and trigger keys.




Core INAP trigger management

Triggers can be handled in the MSC and the HLR through the MML interface.When a trigger is created, it is given a name, a number and the detection pointwhere triggering occurs. All the trigger and service set names must be unique.Triggers and service sets are located in the Trigger Information File (TGIFIL),which contains 2000 records.

You can create triggering data with MML commands in the following order:

1. Create a trigger.

2. Connect the trigger to a service set.

3. Connect the service set to a trigger receiving point. The commands useddepend on the receiving point to which the service set is connected.

Several triggers can be connected to one trigger receiving point by using the sameservice set.

Triggering must be removed in the reverse order. A trigger cannot be deleted if itis included in a service set. A service set cannot be deleted if a trigger keyreferring to it has been defined in the MSC/SSP. However, a service set can bedeleted from the MSC/SSP even though it has been defined for a subscriber in theHLR. If the service set does not exist, alarm 2654 (no service package for CoreINAP trigger key) is generated during the call set-up in the SSP.

In the DX 200 SSP, the trigger can be connected to the following data structures:

. incoming circuit group data

. subscriber data

. digit analysis result

. additional information on the destination or subdestination (=additionalinformation on the analysis result)

. PBX data

. routing attribute analysis data

. extended preanalysis

The trigger is set as the digit analysis result, for example, in IN services which areinitiated when the subscriber calls a service number. If the trigger is set asadditional information on the destination, a trigger is obtained in addition to thenormal (for example, outgoing call) routing result.



27 (64)


Several triggers can be connected to the trigger receiving points, the datastructures. In some calls, triggers can be received from different receiving points.In case several triggers have been activated for some detection point, severalservices may be started. To prevent error situations, the number of triggerings perBCSM has been limited.

See Managing MSC/SSP triggering for information on creating triggers.

Core INAP triggering criteria

Trigger data in the SSF contains information for the initiation and usage of the INservice. When a detection point is met, the SSF checks if the DP is armed as aTrigger Detection Point (TDP) and the conditions for triggering exist. If they do,the SSF starts communicating with the SCF, which may instruct the SSF toproceed with call handling. Any of the Capability Set 1 (CS-1) detection pointscan be armed as TDPs.

The following data can be related to any trigger:

. Trigger name and/or index identifies the trigger.

. Service key identifies the service.

. Trigger detection point identifies the DP in which the IN service isinitiated.

. Trigger priority determines the order in which request-type triggers arehandled if there is more than one trigger in a single DP.

. TBCSM type determines whether triggering should take place in theGMSC, VMSC or both of them.

. Trigger status determines whether the trigger is active or inactive.

. Failure operation determines how the call is treated in case the IN servicefails.

. Application context determines whether the application context isnegotiated when the SCP communication starts.

. Application protocol determines the application protocol used.

. FIM-related parameters determine the handling of multiple controllingservices/service requests.

. SS7 stack selection determines what TC and SCCP stacks are used.

. SCP address location determines the location of the SCP address (insidetrigger data or call data).

. Global title is the address of the SCP.




The following trigger conditions can be used, for example:

. Number of digits determines the minimum number of address digits thathave to be collected before triggering.

- Reach for Number of Digits is an additional trigger condition whichdefines the number of additional address digits that are collectedbefore triggering.

. Matching digit string is used to define a digit string which the receiveddigits, that is, the called party number or the beginning of it must match fortriggering to occur. The type of number (TON) must also match.

. Unmatching digit string is used to define a digit string that will becompared to the called party number or the beginning of it. Triggering cantake place if the digit string does not match the called party number. Thetype of number (TON) must also match.

. Matching calling party is used to define a digit string which the callingparty number or the beginning of it must match for triggering to occur.

. Unmatching calling party is used to define a digit string that will becompared to the calling party number or the beginning of it. Triggering cantake place if the digit string does not match the calling party number.

. Matching vlr address is used to define a digit string which the VLRaddress or the beginning of it must match for triggering to occur.

. Unmatching vlr address is used to define a digit string that will becompared to the VLR number or the beginning of it. Triggering can takeplace if the digit string does not match the VLR address.

. Cause code condition checks the internal cause code and allows triggeringif the cause of the call matches the condition.

. Time-out allows triggering if the called party does not answer within thetime that has been defined.





29 (64)


1.2.4 IN user interaction

The SRP assists the SSP in end-user interaction. The SRP functionality includes,for example, giving announcements (in different languages) and collectingDTMF dialling. It is possible to connect an external SRP to the basic MSC/SSPplatform and thus concentrate the SRP functions to a single point. The externalSRP complements the integrated internal announcement device (VANG) in theMSC/SSP.

IN announcements given from the internal announcement device can consist offixed-content parts and variable-content parts. Announcements like this are calledvariable-content announcements. Other announcements can be given with otherannouncement devices supported by the MSC.

The SCP is able to control the use of the internal or external announcementdevice. The same announcement device is used both in call gapping and normalMSC announcements.

The external SRP is connected to the SSP directly or through the network. TheCore INAP protocol is used between the SCP and the external SRP. The ISUPprotocol is used between the SSP and the SRP. For the MSC/SSP-IPcommunication, feature ISUP Interface to External IP is needed in the MSC/SSP.See Feature 743: ISUP Interface to External IP, Feature Description for furtherinformation.

USSD in Core INAP

The MidCall detection point allows both the calling and called subscriber in theVMSC to interact through a user-network interface during the active call phase.This means that the subscriber can start a new service logic or interact with theexisting service logic to request some service feature. The MidCall-specificinformation received from the subscriber is forwarded to the SCP.

To detect a MidCall DP, the starting characters (digits 0..9, * and #) of thereceived Unstructured Supplementary Service Data (USSD) string will beanalysed in the USSD analysis tree. You can use the commands of the CUcommand group in the MSC to create, delete, and interrogate the MidCall-relatedUSSD analysis in the USSD analysis tree.

You have to create a function analysis for the MidCall cause code (ussd_to_ccf_c= D6H). The result has to be MidCall DP.






1.2.5 Call-related Core INAP parameters

The MSC/SSP contains definitions that affect the IN service activation or theSSF-SCF relationship.

You can handle the Core INAP related parameters by using the commands of theWO command group.



charging_pulse_limit (001:0002)

Use this parameter to set the charging pulse limit for observation of long calls.When the threshold values are exceeded, intermediate charging is generated.

call_time_limit (001:0004)

Use this parameter to define the time limit for observation of long calls. Theaccuracy of the counter is +/- 1 minute. When the threshold values are exceeded,intermediate charging is generated.

default_chrg_zone (001:0044)

Use this parameter to define the default charging zones in IN calls. If the SCP hassent the SendChargingInformation (SCI) operation to the OBCSM with e-parameters, but does not provide the zone to be used, this value is stored in theCDR as the zone value.

intermediate_charging (001:0075)

Use this parameter to specify if intermediate charging is performed in varioussituations. If an intermediate CDR is generated, an intermediateApplyChargingReport is sent to the SCF.

rec_pulse_buffering (001:0076)

Use this parameter to determine when the metering pulse message (if used) has tobe reported to the SCF with the EventNotificationCharging operation, if the SCFhas requested the report with the RequestNotificationChargingEvent operation.The possible values are: 0H (send immediately) or any other value between 1H-00FFH (send after receiving the number of pulses defined, or at the end of the callif the limit is not reached before).



31 (64)


default_chrg_zone_b (001:0077)

Use this parameter to define the default charging zone of the called subscriber (B-subscriber). If the SCF sends new e-parameters with the SCI operation for B-subscriber charging in the TBCSM, but does not provide the zone to be used, thisdefault value is stored in the CDR as the zone value. This value should not be thesame as the zone value normally used in the MSC.

default_chrg_zone_b_roam (001:0078)

Use this parameter to define the default charging zone of the roaming calledsubscriber (B-subscriber). If the SCF has sent new e-parameters with the SCIoperation for B-subscriber charging in the G-BCSM, but does not provide thezone to be used, this default value is stored in the ROAM CDR as the zone value.This value should not be the same as the zone value normally used in the MSC.

use_def_zone (001:0085)

Use this parameter to define whether the default charging zone is used as a tariffclass in CDRs and in the accounting counter updates if the SCP has issued an SCIoperation with change percentage or change pulses. The default charging zone isdefined in the parameters 001:0044, 001:0077 and 001:0078.

in1_data_field_length (001:0106)

This parameter defines the length of the DATA field in the IN1 CDR in bytes.Note that you are recommended not to change the value of the parameter.





scp_interface_usage (002:0213)

Use this parameter to define if the SCP interface in the HLR is in use. If the SCPinterface is not in use, the operations initiated by the subscriber are not sent to theSCP.




loc_nbr_to_pstn_allowed (002:0220)

Use this parameter to manage the commissioning of the 'location information tothe PSTN' feature. When this feature activated, the value FALSE (not in use) isgiven to this parameter. This means that you can define the location informationof a cell by using the Base Transceiver Station Handling MML (EP commandgroup), but this information is not sent to the PSTN yet.

When you have created the location information of all cells, you can change theparameter value to TRUE (feature in use). Now the location information is sent tothe PSTN. An alarm will be generated only if the location information has notbeen defined for the cell.

ssf_function_on (002:0289)

Use this parameter to determine whether the SSP may ask call processinginstructions from the SCP. When the value is TRUE, SCP visits are allowed andthe SSP functions normally. If you change the value as FALSE, SCP visits areprevented in calls initiated after this. In other words, the SSP functionality is lostand IN services are not available.

ssf_dp_i_preanalysed (002:0419)

Use this parameter to define whether EDP2 is encountered before or afterpreanalysis. The default value TRUE means that EDP2 is encountered after thepre-analysis. If the value is FALSE, it is encountered before the pre-analysis.Note that if the SCF has sent the CollectInformation (CI) operation in DP1 andarmed DP2 as EDP-R, EDP2 is met before pre-analysis.

ssf_mid_call_ctrl (002:0422)

Use this parameter to determine how the SSP-SCP relationship is treated if theSCP sets a request-type event at a MidCall detection point. If the parameter valueis TRUE, the controlling relationship is handled exactly as defined in Core INAPspecifications. If the parameter value is FALSE, a request-type event at theMidCall detection point does not mean that the relationship is controlling, inother words, another triggering is possible.

inap_ac_in_use (002:0446)

Use this parameter to determine the use of application contexts within the INAPprotocol. When the value is TRUE (default), application contexts are used. Thevalue FALSE means that they are not used.



33 (64)


sccp_segmentation (002:0447)

Use this parameter to determine the use of SCCP (Signalling Connection ControlPart) segmentation within the INAP protocol. When the value is TRUE, theSCCP segmentation is used. The default value is FALSE (SCCP segmentation notused).

ni_and_si_inap_rednbr (002:0501)

Use this parameter to determine the use of the Number Incomplete (NI) andScreening Indicator (SI) parameters in the INAP redirectingPartyID parameter.The value TRUE means that NI and SI are packed into the INAP InitialDPredirectingPartyID and unpacked from the INAP Connect redirectingPartyID.The value FALSE means NI and SI are not used in the INAP redirectingPartyIDparameter.

ssp_sw_level_in_use (002:0596)

Use this parameter to determine whether the software level of the SSP istransferred to the SCP. The value TRUE means that the software is transferred.

cs1_last_op_in_tc_end (002:0599)

Use this parameter to define whether the last operation (ERB-n or ACR) is sentTC_END. The value TRUE means that the last operation is sent in TC_END. Thevalue FALSE means that the operation is sent in TC_CONTINUE.

acr_bef_erb_edp9 (002:0673)

Use this parameter to determine whether the ApplyChargingReport (ACR)operation is allowed to be sent before ERB-R (DP9, DP17) or after ERB-R.When the parameter value is set to TRUE, the parameter determines the sendingof the ACR to the SCP in the Disconnect DP. In case of INAP, when theDisconnect DP is met and armed as an EDP-R, and ApplyCharging is pending,first the ACR of that controlling relationship should be sent to the SCP and then acorresponding EventReport BCSM (ERB).

answer_from_free_ann (002:0732)

Use this parameter to define the handling of charging and statistics in case a callis routed to an announcement as a result of the routing and charging analysis.When a free of charge announcement is desired, the NCB digit analysis parameterfor the call has to be set to NCH (= no charging).




Be default, the call routed to an announcement is compiled to statistics as asuccessful call. The O_Answer DP is reported to the SCP and the threshold isconsumed. However, the Answer message is not sent to the incoming signallingwhen the announcement starts. The call CDR is not generated unless the operatorhas defined that CDRs should be produced for free calls.

Alternatively, the call routed to an announcement is compiled to statistics as anunsuccessful call. The O_Abandon/O_Exception DP is reported to the SCP andthe threshold is not consumed. The Answer message is not sent to incomingsignalling when the announcement starts. The UCA CDR can be produced.

The call routed to an announcement can also be compiled to statistics as asuccessful call. The O_Answer DP is reported to the SCP and the threshold isconsumed. The Answer message is sent to incoming signalling with the free ofcharge indication if the sending of free ANM is supported and allowed by theIP0FIL (Incoming signalling file) ANMF parameter. The call CDR is notproduced unless the operator has defined that CDRs should be produced for freecalls as well.

scp_int_wait_tone_tsl (007:0051)

Use this parameter to specify the time slot number of the tone which the callingsubscriber hears while an announcement is played to the called subscriber, orwhile DTMF characters are collected from the called subscriber. Theannouncement or the character collection is ordered by the SCP.

in_interface_rel_in_fai (007:0081)

Use this parameter to determine if it is possible to continue setting up a call incase an error occurs in the IN interface. The parameter is used only when an erroroccurs at such an early phase that the actual triggering information has not beenfound yet.

implicit_disarming_cs1 (007:0106)

Use this parameter to determine whether or not implicit disarming of events ispossible. The value TRUE means that implicit disarming is possible.

ssf_mpc_allowed (007:0108)

Use this parameter to determine whether or not the multiple point of controlprinciple is available. The default value is FALSE which means that as long asany controlling IN service is active, a new controlling IN service may not bestarted.



35 (64)


ssf_msdp_allowed (007:0110)

Use this parameter to determine whether multiple controlling IN services can beserved in a single detection point. The default value is FALSE which means thatonly one controlling IN service (EDP-R or TDP-R) can be served in a singledetection point.

dedicated_in_event_code (007:0128)

The parameter determines whether dedicated IN event codes are used in CoreINAP and CAMEL Connect operations. The value TRUE means that dedicatedevent codes are used (1042 in the CAMEL Connect operation, 1043 in the CoreINAP Connect operation). The value FALSE means that the default value 1028 isused.

scp_trans_limit (009:0013)

If the error ratio limit defined in this parameter is exceeded, the urgency level ofthe alarm given correlates with the value of this parameter as follows:

. If the total number of transactions in the SCP during the monitoring periodis below the value of this parameter, a disturbance-type alarm is given.

. If the total number of transactions in the SCP during the monitoring periodis higher than the value of this parameter, a serious-type alarm is given.

scp_err_alarm_limit (009:0014)

Use this parameter to define the alarm limit of the error ratio of the failedtransactions to all transactions in the SCP during the monitoring period.

scp_monitoring_period (009:0015)

Use this parameter to define the monitoring period for the error ratio of the failedtransactions to all transactions in the SCP. The unit is 1 minute. For example, 6(hex) equals a monitoring period of 6 minutes.

1.2.6 Special Core INAP DPs

The end-of-selection analysis is used for analysing a cause code, which identifiesvarious events during a call. The SSP detects some of the detection points(Route_ Select_ Failure, Called_Party_Busy and No_Answer, for example) as aresult of the end-of-selection analysis and the EOS attribute analysis in theOBCSM. In the TBCSM the detection points are hardcoded and thus cannot bemodified.

To handle these DPs, use the commands of the RX and RQ command groups.






1.2.7 Feature interworking in Core INAP

CAMEL

As both Core INAP and CAMEL can exist in the home PLMN of a subscriber,interworking between these features has to be defined. Feature InteractionManagement (FIM) defines the multiple-point-of-control principle, which makesit possible to start both a CAMEL service and a Core INAP service in the sameBCSM and in the same detection point. The priority parameter determines theexecution order of the services to be started in the same detection point. CoreINAP priority can be specified separately for each service. See also Feature 986:Feature Interaction Management (FIM), Feature Description . For more detailedinformation on CAMEL see Feature interworking in CAMEL .

GSM SS services

The general principle is that Core INAP detection points are handled prior to SSinvocation. CCBS is an exception, because the execution order of CCBS andCore INAP can be changed by presetting the trigger files. The execution order ofother GSM and Core INAP services is hardcoded.



1.3 Call-unrelated Core INAP service switchingfunctions




37 (64)


1.3.1 IN Mobility Management

In IN Mobility Management , the IN concept and the IN architecture are appliedto the mobility management transactions, that is, location registration procedures.For example, a home subscriber's service area can be defined with the accuracy ofone location area. Also, the service area of subscribers roaming from otherPLMNs can be defined with the accuracy of one MSC/VLR service area.

The network architecture consists of the MSC/VLR, HLR and SCP. A serviceswitching function Mobility Management Service Switching Function (MM-SSF)carries out the handling of detection points in the network elements. The MM-SSF exists both in the HLR and in the MSC/VLR. The SCP includes a servicecontrol function Mobility Management Service Switching Function (MM-SCF)and service logic programs for the mobility management services.

IN triggering can be done during location updates, that is, when a subscriberchanges the location area or MSC/VLR service area. Triggering in the HLR canoccur when the subscriber changes the PLMN or MSC/VLR service area. Normallocation update, periodic location update and IMSI attach (the MS is turned on)can be triggered separately. This cuts down the number of visits to the SCP, thusenabling the SCP to serve more subscribers. It is possible to define triggeringconditions for IN-MM services. Triggering is not done based on IMSI detach.

Three separate mobility management state models have been defined for the INMobility Management: two for the MSC/VLR and one for the HLR. The modelscontain trigger detection points , at which the control of the location registrationprocedure can be moved from the network element to the SCP. The SCP can thendecide, for example on the basis of the location of the subscriber, whether thelocation registration is accepted or not.

IN Mobility Management brings flexibility to services that are based on restrictedservice areas. With IN Mobility Management the creation and maintenance ofservice areas is IN-based and thus more simple and straightforward to handle.

IN mobility management services can be offered to different subscriber types asfollows:

. subscriber-specific services to the home subscribers. The services areprovisioned in the subscriber data.

. network-specific services to all roaming subscribers on a PLMN basis. Theservices are provisioned in the PLMN-specific file in the VLR. Offeringthe network services to the home subscribers should be avoided if there is arisk of overloading the network elements.




Charging for IN-MM

Charging is carried out by generating a LOCA CDR and an IN CDR.

The Location Update (LOCA) CDR is generated in the MSC for location updates.The LOCA CDR has to include information on the number of IN records (one INCDR per one LOCA CDR), and the LocUp reference to connect the LOCA CDRto the IN CDRs.

The use of the IN CDR is basically the same as in the call-related cases. Thecontent of up to 5 FCI operations is included in the CDR. This information istransparent to the VLR.

Handling IN Mobility Management in subscriber data

You can handle the IN Mobility Management in the subscriber data with thecommands of the MQ command group. To create and modify IN MobilityManagement service data in the HLR, use the MQM command. To delete the data,use the MQD command. To display the IN service parameters, use the MQOcommand.

For more information see Feature 742: IN Mobility Management, FeatureDescription .

For information on other call-unrelated Core INAP service switching functionssee Call-unrelated Core INAP service switching functions .


1.3.2 IN Short Message Service

IN Short Message Service (IN-SMS) allows the operator to create better servicesin the area of restricted mobility, implement new services based on SMS control,and manage the interaction between GSM and IN services. The SMS detectionpoints (MO, MT, Status Report), for example, make it possible to redirect shortmessages to another subscriber or to another MSC. Another application is thatIN-SMS allows the subscriber to prevent short messages from a certain sourceand also to forward incoming short messages to another mobile user.

The triggers defined for the IN-SMS are located in the VMSC. The SCP canrequest the SSP to send a report about the outcome of the SM transfer.



39 (64)


Mobile-originating SMS

In the MO case, the TDP is met after the authentication and ciphering for the MO-SMS has been carried out and the MSC has received the short message from theMS. If the TDP is armed (the TDP data is included in the subscriber data), theMSC/VLR sends an IN service request to the SCP, which can react in severalways. In the following cases, the short message transfer continues:

. The SCP responds with the Continue operation.

The MSC/VLR forwards the original short message to the originalInterworking MSC (IWMSC).

. The SCP responds with the Connect operation.

The SCP may change the destination, that is, both the SMSC address andthe called party address where the message was originally sent. The SCPmay also change other parameters in the short message transfer layerheader, for example, the type of the message.

When the MSC/VLR has received the Connect operation, it changes theSMSC address, if needed. If the SCP has changed the header of the shortmessage, the MSC/VLR inserts the new header into the short message andsends it to the IWMSC.

. The SCP may arm one or both EDPs with the RequestReportBCSMEventoperation.

. The SCP may send FurnishChargingInformation operations related to theConnect or Continue operations.

Short message transfer is rejected if the SCP sends the ReleaseCall operation. Inthis case, the MSC/VLR does not forward the short message to the IWMSC.

Mobile-terminating SMS

In the MT case, the TDP is met at the earliest possible point after the MSC hasreceived the short message from the GMSC, and the subscriber data in the VLRhas been checked. If the TDP is armed (the TDP data is included in the subscriberdata), the MSC/VLR sends an IN service request to the SCP, which can react inseveral ways. In the following cases, the short message transfer continues:

. The SCP responds with the Continue operation.

The MSC/VLR starts paging and forwards the short message to the MS.

The SCP may arm one or both EDPs with the RequestReportBCSMEventoperation.




. The SCP responds with the Connect operation, if the message should bererouted:

- The SCP provides the address of the SMSC. If it does not, the shortmessage is forwarded to the SMSC which originated the message.

- The SCP may change the A-subscriber's address, or send it back tothe SSP unchanged in a MT-Connect operation (MT-VMSC).

- The SCP may arm the EDPs.

- The SCP changes the message header of the short message. TheSCP must change the SMS type from mobile-terminating to mobile-originating before forwarding the message to the specified IWMSC.

- The SCP may change the called number.

Short message transfer is rejected if the SCP responds with the ReleaseCallmessage. The MSC/VLR does not forward the short message to the MS.

Charging for IN-SMS

The subscriber is charged by generating a Mobile-originated Short MessageService (SMMO) CDR, Mobile-terminated Short Message Service (SMMT)CDR, or Short Message Service, Mobile-originated with Forwarding (SMMF)CDR, depending on the case, and the IN CDR when theFurnishChargingInformation operation is received in the VMSC.

In MT-SMS and SR-SMS, the MSC generates the IN CDR and the SMMT CDRif the SCP responds with Continue. If the SCP responds with Connect, the MSCgenerates the IN CDR and the SMMF CDR.

The use of the IN CDR is basically the same as in the call-related cases. Thecontents of up to 5 FCI operations are included in the CDR. The content of thisinformation is transparent to the VMSC. The IN CDR has to include the SMSreference to connect the SMMO, SMMT, or SMMF CDR to the IN CDR.

The SMMO CDR has to include the number of IN records (value 1 means that theTDP is met and the FCI has been received) and the SMS reference. Thecorresponding information is also included in the SMMT CDR.

The SMMF CDR also contains this information, and the forwarded-to number(the changed number of the destination subscriber) and forwarded-to SMSC (thechanged address of the SMSC).

Handling IN SMS in subscriber data

You can handle IN Short Message Services in the subscriber data with thecommands of the MQ command group.



41 (64)


To modify IN SMS service data in the HLR, use the MQT command. To delete thedata, use the MQD command and to output it, the MQO command.

For more information see Feature 910: IN Short Message Service, FeatureDescription .



1.3.3 IN Supplementary Services Management

IN Supplementary Services Management further develops the IN conceptsimplemented to Nokia's SSP for the call-independent transactions. Thefunctionality of IN is applied to supplementary service requests and a state modelis developed in the HLR including one detection point (TDP-R) for thesupplementary service management transactions. With this trigger detection pointthe SCP can control how the subscriber manages his GSM supplementaryservices, although these are implemented in the HLR. It also allows the operatorto manage the interaction between the GSM supplementary services and the INservices.

The TDP can be used independently regardless of the subscriber's roaming in thehome PLMN or abroad because the TDP is situated in the HLR where the SSManagement requests are forwarded. Only the interrogation and the call relatedinvocation requests are handled in the VLR.

If the TDP is armed and the HLR supports the requested service, the HLR startsthe transaction towards the SCP. An armed TDP in this case means that thesubscriber data includes the TDP data, the requested supplementary service hasbeen provisioned to the subscriber, the requested state transition concerning thesupplementary service is acceptable and the conditions for triggering are fulfilled.The triggering condition may be an individual supplementary service (forexample, CFU) or a supplementary service group (for example, conditional CF).

The following transactions cause triggering:

. registration. The subscriber programs specific supplementary informationto enable the operation of a service. Certain services may be activated bythe registration procedure while others may already be active.

. erasure. The subscriber deletes information on a particular service stored ina previous registration(s).




. activation. The subscriber enables a process to run as and when required bythe service concerned, resulting in the active phase. Some services can beeither operative or quiescent (not operative) during the active phaseaccording to whether or not the system is able to invoke or use them.

. deactivation. The subscriber terminates the process started at activation.

When the SCP receives an InitialDP operation indicating an SS-request, it mayrespond to the HLR in the following ways:

. It accepts the SS management request with the Continue operation. In thiscase, triggering serves as a notification of the subscriber activity. Afterreceiving the Continue message, the HLR continues as if triggering had nottaken place.

. It denies the SS management request with the ReleaseCall operation. Therecan, for instance, be a conflicting IN service and the subscriber is notallowed to carry out the action he has requested. If the request is denied,the subscriber sees it as an unsuccessful operation.

. It can send the Connect operation. If the SS management action is aregistration of the forwarded-to number, the SCP may change the receivednumber. The number can be modified (for example, from the short to thelong format) or changed to another number. In other cases this response isnot relevant.

If the checks the HLR makes after receiving the Connect operationsucceed, the number is stored to the HLR database and the SS managementrequest is accepted. If the checks fail, the subscriber's request is rejected.

Handling IN Supplementary Services in subscriber data

You can handle IN Supplementary Services in the subscriber data with thecommands of the MQ command group.

To modify IN-SS data in the HLR, use the MQS command. To delete the data, usethe MQD command and to display it, the MQO command.

For more information see Feature 911: IN Supplementary Services Management,Feature Description .





43 (64)


1.3.4 Call-unrelated Core INAP parameters



in_mm_usage (002:0382)

Use this parameter to determine whether the feature is active or deactive. If it isdeactive, the IN-MM state model is not started in the VLR or in the HLR. Thedefault value is TRUE, which means the feature is in use.

in_ss_usage (002:0493)

Use this parameter to activate or deactivate the feature. The default value isTRUE which means the feature is active.

scp_availability_timer (006:0036)

Use this parameter to set the maximum waiting time for the first SCP response.The time is expressed in multiples of 100 ms, for example, the value 2H meansthe waiting time is 0.2 seconds. The parameter is used both by the VLR and theHLR.

in_mm_for_sms_act_mo (031:0034)

Use this parameter to activate the MO part of the IN short message servicefeature. The parameter also controls the interaction between the IN short messagefeature and CAMEL Phase 3 feature (call-unrelated part). The default valueFALSE means that the IN short message feature is not active and CAMEL Phase3 feature (call-unrelated part) is active.

in_mm_for_sms_act_mt (031:0035)

Use this parameter to activate the MT part of the IN short message servicefeature. The parameter also controls the interaction between the IN short messagefeature and CAMEL Phase 3 feature (call-unrelated part). The default valueTRUE means that the MT SMS function of the IN short message service featureis active.




1.4 Core INAP charging and statistics


Core INAP charging

In GSM networks, the MSC generates charging records which contain thenecessary billing information. These charging records are transmitted to thebilling centre for post-prosessing. IN does not change these charging principles.The MSC/SSP still generates the charging records, but in addition to this, the INservices have the ability to add IN-specific aspects to the charging information. Inpractice, the IN services running in the SCP can utilise the charging controloperations on the Core INAP interface towards the SSP. For more information onCore INAP charging matters, see Charging for IN calls in Core INAP .

Core INAP statistics

It is central to SSP statistics that the functioning of the SCP can be monitored.This means that is must be possible to measure how well both the SCP andindividual services can handle the traffic offered. IN service gapping is used forthis purpose. With IN service gapping, the SCP can restrict the number ofdialogues started by the SSP and thus prevent SCP overload. The restriction of INservices can be measured with the IN service gapping measurement.Gapping isused in Core INAP CS-1, IN-MM, IN-SMS and IN-SS services.

The clear codes in which the IN calls have terminated can be measured with thetrafficability performance measurement.

The proportion of failed SCP connections to all the SCP connections can besupervised with SCP's maintenance supervision.

Feature IN Protocol Measurements is used for creating INAP statistics thatcounts, collects and reports data between the SSP and the SCP. INAP statisticsmonitors the number of different INAP application contexts and operationstowards and from the SCP entities in the SSP/IP.

For more information on statistics see NSS Statistics .

1.5 Core INAP � related alarms and clear codes




45 (64)


Alarms related to Core INAP

If errors or problems occur during the use of the SSP, alarms help you find theproblem area. For example, the following alarms can be issued in possibleproblem situations:

Table 4. Alarms related to Core INAP

Alarm

2718 : UNSUITABLE FCI SIZE

2192 : SERIOUSLY EXCESSIVE ERRORS IN SCP

1190 : EXCESSIVE ERRORS IN SCP

1053 : OVERFLOW IN GAP TABLE

2121 : ERROR IN CHARGING

0654 : MAXIMUM COUNT OF CORE INAP TRIGGERS EXCEEDED

2654 : NO SERVICE PACKAGE FOR CORE INAP TRIGGER KEY

0053 : LONG USER INTERACTION DURATION EXPIRED

Clear codes related to Core INAP

A clear code is the identifier code of the reason to clear a call. A clear code mayalso act as control information in an exchange, ordering the exchange to handle acall in a certain way. Clear codes are internal information of the DX 200 system.

The following table lists clear codes related to IN services.

Table 5. Clear codes related to IN services

Clear code Explanation and possible cause

0016: SUBSCRIBER'S CHARGING CAPACITYEXCEEDED IN THE EXCHANGE

Subscriber's charging capacity has been exceeded in theexchange.

The end of the current threshold is reported to the SCP,there is no credit left in the SCP or no response isreceived.




Table 5. Clear codes related to IN services (cont.)


0B2B: PARAMETER DOES NOT EXIST OR ISNOT IMPLEMENTED

There are illegal parameters in the received networkmessage or the information element of the message isunsupported or unrecognizable.

There is erroneous functionality in the service or a routingproblem.

0B2C: IN APPLICATION PROTOCOL ERROR A message from the intelligent network application hasbeen received at a moment when a message should nothave arrived.

There is erroneous functionality in the service, or a routingproblem.

0B2D: INTELLIGENT NETWORK APPLICATIONRESPONSE TIME-OUT

The IN application does not respond to an operationrequiring an acknowledgement within the time limit.

When the InitialDP operation is sent, it is not routed to theSCP at all or the SCP is not able to respond, for example,the SCP is down or routing information is inadequate orerroneous.

0B2E: MAXIMUM NUMBER OF TRIGGERINGEVENTS IN A CALL HAS BEEN REACHED

The maximum number of triggering events in activating INservices has been reached.

The SSP tries to send more than the maximum number ofInitialDPs in one BCSM.

0B2F: TCAP ERROR An error has occurred in the TCAP connection to the SCP.

There is erroneous routing, congestion in the SCP,uncompatible SW levels in the SCP and/or the SSP.

0B30: ASN1 CODING DECODING ERROR An ASN.1 coding or decoding error has been detected.

There are uncompatible SW levels in the SCP and/or theSSP.

0B31: SELECTIVE CALL CONGESTION HASPREVENTED CALL ATTEMPT

The call attempt has been interrupted by the limit of SCPvisits in connection to the called number or the IN servicekey defined by the SCP.

The CallGapping functionality prevents the sending ofInitialDP, for example, the SCP has reported an overloadsituation to the SSP.

0B32: CALL RELEASE ORDERED INTELLIGENTNETWORK APPLICATION

A call in the SCP or controlled by an internal INapplication is cleared.



47 (64)


Table 5. Clear codes related to IN services (cont.)


There is no active service for the subscriber or conditionsin the service are preventing the call.




2 Connecting SSP and SCP

The SCP and the SSP can be connected either by using direct links or through theSS7 network by using global title addressing.

A signalling point is a network element which sends and receives signallingmessages. A signalling point can operate as a signalling transfer point , whichmeans that signalling traffic goes through the signalling transfer point towards thedestination signalling point. There can be several signalling transfer pointsbetween two signalling end points.

A network element can operate in a maximum of 4 signalling networks. Everynetwork element has a signalling point code in every network it belongs to. Thesignalling point code (the number given to the signalling point) itself can be thesame in each network.

Signalling points are connected with PCM circuits. Each PCM circuit connectedbetween one common channel signalling unit (CCSU) and the SCP forms asignalling link , which provides a reliable message transfer service between twosignalling points. A signalling link set is formed of signalling links connectingtwo signalling points directly.

A signalling route is a chain of signalling link sets and signalling transfer pointswhich the signalling point can use as a path when routing a message towards aspecific signalling point. All signalling routes between a specific SSP and an SCPform a signalling route set .

In this procedure, the SSP and the SCP are connected by using direct links.

The figure SSP-SCP connection and triggering shows an example of this. Otherrelated topics are Creating MSC/SSP triggers and service sets and ConnectingMSC/SSP service sets to trigger receiving points . See also Core INAP basic callstate models .



49 (64)

Connecting SSP and SCP

Figure 13. SSP-SCP connection and triggering


Before you start

There are no special prerequisites. The exchange has to be in use and theequipment has to exist.

Using the SCP requires an exchange termination. If it does not exist, you have tocreate it by using the commands in the Equipment Management (WT) and UnitConnections Handling (WU) command groups.

Steps

1. Create CCS channels to the SCP

a. Create signalling links (NCC).

NCC:<signalling link number>:<external PCM-TSL>:<unit type>,<unit number>:;

b. Create a link set (NSC).

NSC:<signalling network>,<signalling pointcode>,<signalling link set name>:<signallinglink number>,<signalling link code>;

c. Create a signalling route set (NRC).

NRC:<signalling network>,<signalling pointcode>,<signalling point name>,,,:,,,<signallingroute priority>;

d. Allow the use of a signalling link (NLA).

NLA:<signalling link numbers>;

e. Allow the use of the signalling route (NVA).

TREE = 90TRG = FOLLOW-MEGT = NAT, 700

GTT: NAT, 700SPC = 7D0SSN = 0C

SCP1,SCP11

SSP

PCM82, TS1 SPC = 7D0SSN = 0C

SCP

Call

0700-1234




NVA:<signalling network>,<signalling pointcode>:;

f. Activate the signalling links (NLC).

NLC:<signalling link numbers>,<state change>;

g. Activate the signalling route (NVC).

NVC:<signalling network>,<signalling pointcode>::<state change>;

2. Define the SCCP of the SCP, and subsystems for the SCP and the MSC(own signalling point)

a. Create a subsystem in SSP (NFD).

NFD:<signalling network>,<signalling pointcode>,<signalling point parameter set number>:<subsystem number>,<subsystem name>,<subsystemparameter set number>;

If subsystems already exist in the MSC, add a new one (INAP) withthe NFB command:

NFB:<signalling network>,<signalling pointcodes>:<subsystem number>,<subsystem name>,<subsystem parameter set number>,<subsystemstatus test>;

The parameter <subsystem status test> is used to allow orprohibit the subsystem status test. The default value is that thesubsystem status test is allowed.

b. Create a subsystem for SCP (NFD).

NFD:<signalling network>,<signalling pointcode>,<signalling point parameter set number>:<subsystem number>,<subsystem name>,<subsystemparameter set number>;

3. Create global title translations

Create global title modification data if it has not been created (NAA).

NAA:<ss7 standard and global title indicator>:TT=<translation type>,NP=<numbering plan>,NAI=<nature of address indicator>;

a. Create results for global title translation (NAC).

If you want to use the GT address instead of the subsystem number,give the NAC command:



51 (64)


NAC:NET=<primary network>,DPC=<primarydestination point code>,RI=<primary routingindicator>,SSN=<primary subsystem number>:::;

b. Create global title analyses for the results created above (NBC).

(With the ZNAI; command, you can check the national significantnumber 3, SCP's GT address 700 and result record index 1 you havejust created.)

NBC::NAI=<nature of address indicator>:<digits>:<result record index>;

4. Create a new subsystem parameter set

With these commands you can determine whether the SSP sends its ownsignalling point code or the GT address. Note that this also has an effect onthe SS7 stack of the SCP.

a. Create an SCCP subsystem parameter set (OCA).

OCA:<subsystem parameter set number>:<subsystemparameter set name>;

b. Modify the value of the SCCP subsystem parameter set (ownaddress) (OCN).

OCN:<subsystem parameter set number>:<parameternumber>,<parameter value>;

c. Change the subsystem parameter set (NFM).

NFM:<signalling network>,<signalling pointcode>:<subsystem numbers>:<subsystem parameterset number>;

5. Activate the SPC and SSN for the SCP

a. Activate the SPC (created signalling point) (NGC).

NGC:<signalling network>,<signalling pointcodes>:<state change>;

b. Activate the SSN (created subsystem) (NHC).

NHC:<signalling network>,<signalling pointcodes>:<subsystem>:<state change>;

6. Connect the SCCP as a user of the MTP (NPC)

NPC:<signalling network>,<service indicator index>,<service indicator name>:<service existing for STPmessages>:<service existing for user part of ownsignalling point>,<primary process family>,<secondary process family>;




2.1 Example of connecting SSP and SCP

Steps

1. Create CCS channels to the SCP

a. Create signalling links (CCS number 3, PCM circuit 82, time slot 1).

ZNCC:3:82-1:CCSU,0:;

b. Create a link set (signalling network national 0, signalling pointnumber (SCP) 7D0, name SCP11, signalling link code and priority0).

ZNSC:NA0,7D0,SCP11:3,0;

c. Create a signalling route set (name SCP1, signalling link priority 0).

ZNRC:NA0,7D0,SCP11,,,:,,,0;

d. Allow the use of a signalling link (created in step 1.1 above).

ZNLA:3;

e. Allow the use of the signalling route (created in step 1.3 above).

ZNVA:NA0,7DO:;

f. Activate the signalling links (created in step 1.1 above).

ZNLC:3,ACT;

g. Activate the signalling route (created in step 1.3 above).

ZNVC:NA0,7D0::ACT;

2. Define the SCCP of the SCP, and subsystems for the SCP and the MSC(own signalling point)

a. Create a subsystem in SSP (subsystem 0C, signalling point 226,name INAP, signalling network national 0).

ZNFD:NA0,226,0:0C,INAP,0;

If subsystems already exist in the MSC, add a new one (INAP) withthe command:

ZNFB:NA0,226:0C,INAP,0,Y;

b. Create a subsystem for SCP (subsystem 0C, signalling point 7D0,name INAP, signalling network national 0. The command andparameters are the same as in step 1.1 above.).

ZNFD:NA0,7D0,0:0C,INAP,0;

3. Create global title translations

Create global title modification data if it has not been created.

ZNAA:ITU=4:TT=0,NAI=3,NP=1;



53 (64)


a. Create results for global title translation (subsystem 0C, signallingpoint 226, name INAP, signalling network national 0).

ZNAC:NET=NA0,DPC=7D0,SSN=0C,RI=SSN:;

If you want to use the GT address instead of the subsystem number,give the command:

ZNAC:NET=NA0,DPC=7D0,RI=GT;

b. Create global title analyses for the results created above (subsystem0C, signalling point 7D0, name INAP, signalling network national0. The command and parameters are the same as in step 1.1 above.).

(With the ZNAI; command, you can check the national significantnumber 3, SCP's GT address 700 and result record index 1 you havejust created.)

ZNBC::NAI=3:700:1;

4. Create a new subsystem parameter set

a. Create an SCCP subsystem parameter set

ZOCA:2:INAP;

b. Modify the value of the SCCP subsystem parameter set (ownaddress)

ZOCN:2:6,1;

c. Change the subsystem parameter set

ZNFM:NA0,3A1:0C:2;

5. Activate the SPC and SSN for the SCP

a. Activate the SPC (created signalling point).

ZNGC:NA0,7D0:ACT;

b. Activate the SSN (created subsystem)

ZNHC:NA0,7D0:0C:ACT;

6. Connect the SCCP as the user of MTP

(national network 0, service indicator index 3, service indicator nameSCCP, primary process family 10E and secondary process family 10F)

ZNPC:NA0,3,SCCP:Y:Y,208,10F;

For more information on connecting the SSP and the SCP see ConnectingSSP and SCP .




3 Managing MSC/SSP triggering

Each IN service has its own trigger which contains the data needed to initiate andexecute the IN service. You can create triggering as follows:

. Create a trigger.

. Connect a trigger to a service set.

. Connect the service set to a trigger receiving point.

Triggers and service sets are handled with the Trigger and Service Set HandlingMML (RG).

See Triggering in IN for more background information. See also Overlay SSP .For an overview of Core INAP see Core INAP in MSC/VLR/SSP and HLRoverview .

3.1 Creating MSC/SSP triggers and service sets

You can create a trigger usually after a corresponding service logic program hasbeen set in the SCP. For information on how to connect the SSP and the SCP seeConnecting SSP and SCP . You can also modify, interrogate and delete triggers, ifneeded.

Use the following commands:

. RGC � create trigger

. RGM � modify trigger

. RGI � interrogate trigger or service set

. RGD � delete trigger or service set

You can create a service set by giving it a descriptive name and connecting one orseveral triggers to it. You can also modify, interrogate and delete service sets, ifneeded.



55 (64)

Managing MSC/SSP triggering

Use the following commands:

. RGS � create service set

. RGR � modify service set

. RGI � interrogate trigger or service set

. RGD � delete trigger or service set

See the Trigger and Service Set Handling MML (RG) for examples.

See also Managing MSC/SSP triggering for more information on triggers.


3.2 Connecting MSC/SSP service sets to triggerreceiving points

The type of the service set determines to which trigger receiving point it can beconnected. A trigger key refers to one service set and equals the index of thisservice set. Examples of possible receiving points are presented below. Theprerequisite is that the incoming circuit group has already been created.

When you connect service sets to trigger receiving points, you usually give theservice set number. If you cannot recall the number, you can interrogate theservice set data by using the RGI command.

For information on trigger management see Core INAP trigger management . Forinformation on how to connect the SSP and the SCP see Connecting SSP andSCP .

Incoming circuit group data

A service set is connected to the incoming circuit group data usually when all thecalls from a certain incoming circuit group should be triggered.

Use the commands of the RC command group to handle circuit-group-basedtrigger keys.

Subscriber data

A service set is connected to subscriber data usually when supplementary servicesare implemented through IN facilities (call forwarding, direct call, for example).




When the trigger key is added to the subscriber data in the HLR, the informationis automatically updated to the VLR. The trigger key refers only to the service setand contains no other information. It is important that the trigger key refers to anexisting service set number because the HLR cannot check during trigger keyallocation whether the service set exists in the SSP. If the service set does notexist, the alarm 2654 (no service package for Core INAP triggger key) isgenerated during the call set-up in the SSP.

Use the commands of the MQ command group to handle trigger keys for asubscriber.

To view the trigger key that has been allocated for a mobile subscriber in theVLR, use the MVS command.

Digit analysis result

A service set is typically connected to the digit analysis result when IN servicesbased on service numbers are implemented.

Define the trigger key in the digit analysis result. In this case, the SSP does nothave any destination to which the call could be routed if the SCP does not providea new called party number. The call is cleared.

If you want to delete the trigger key/service set from the digit analysis, modify theanalysis by specifying a new destination and subdestination.

To handle the trigger key defined for an IN service number, use the commands ofthe following digit analysis MMLs: Digit Analysis Handling (RD), DigitAnalysis Modification (RM) and Digit Analysis Interrogation (RI). Digit analysishas to be made for all incoming call analysis trees (mobile, PBX, trunk,forwarded).

Additional information on the destination or subdestination (=additionalinformation on the analysis result)

A service set is typically connected to the digit analysis result when IN servicesbased on service numbers are implemented.

Define the trigger key as additional information on the destination orsubdestination. This enables the SSP to route the call even if a new called partynumber is not received from the SCP. You can set a trigger to the call withoutnumber translation. Triggering can also take place later during the call.

If you want to delete the service set from the destination's additional data, enterthe value 0 as the service set number. If you want to delete the service set fromthe subdestination, modify the subdestination by specifying a new subdestination.



57 (64)


To handle the trigger key defined for an IN service number, use the commands ofthe following digit analysis MMLs: Digit Analysis Handling (RD), DigitAnalysis Modification (RM) and Digit Analysis Interrogation (RI). Digit analysishas to be made for all incoming call analysis trees (mobile, PBX, trunk,forwarded).

PBX data

If services are provisioned to a PBX, the subscriber's trigger key is added to thePBX's supplementary service file in the MSC. If the trigger key is in an incomingcircuit group of a PBX, the trigger key is not used. It has to be defined to the PBXsupplementary service file.

Use the commands of the SA command group to handle the trigger keyconcerning a whole PBX.

Routing attribute analysis data

The routing attribute analysis makes it possible to modify the routing based onvarious call-related parameters (such as calling party category). The trigger keycan also be defined as a result of the routing attribute analysis. Use the commandsof the RQ command group.

Extended preanalysis

Extended preanalysis is needed when the input parameters of the preanalysis arenot sufficient for creating the analysis result. Extended preanalysis can be used,for example, to create different routing schemes for dialled numbers whose lengthis 7 or 10 digits, when the length of the number is a decisive factor. Extendedpreanalysis can also be used in cases where the operator can determine that anincoming-circuit-group-dependent trigger key only affects certain subscribers.

Example 1.

Connect a service set to the final result of the extended preanalysis. In thisexample, the category of the A-subscriber is PRIO, which means that triggeringto the SCP is possible.

1. Modify the result of the preanalysis with the RWN command. (In this case,the default preanalysis is modified. Normal preanalysis is modified withthe RWM command.)

ZRWN:MOC,4,123,:::ESTP=5;




2. Create the final result of extended preanalysis with the CWR command.The final result is created to obtain the trigger key. All other parameters arereceived from the result of the preanalysis.

ZCWR:RES1:SSET=20;

3. Finally, create the subanalysis with the CWC command. (It is assumed thatthe default result of analysis DEF1 has already been created.)

ZCWC:NAME,START,5:ACAT=PRIO:RES=RES1,DEFRES=DEF1;

See also Managing Core INAP triggering for more information on triggers.




59 (64)





Glossary

Abbreviations

BCSM Basic Call State Model

CAMEL Customised Applications for Mobile network Enhanced Logic

CC Call Control

CCS Common Channel Signalling

CCSU Common Channel Signalling Unit

CDR Charging Record

CS-1 Capability Set 1

DP Detection Point

EDP Event Detection Point

EDP-N Event Detection Point - Notification

EDP-R Event Detection Point - Request

GMSC Gateway MSC

ICC Incoming Call Control

IN Intelligent Network

INAP Intelligent Network Application Part

IP Intelligent Peripheral

MM-SCF Mobility Management Service Control Function

MM-SSF Mobility Management Service Switching Function

OCC Outgoing Call Control

OBCSM Originating Basic Call State Model

PBX Private Branch Exchange

PIC Point In Call

SCCP Signalling Connection Control Part



61 (64)

Glossary

SCF Service Control Function

SCP Service Control Point

SSF Service Switching Function

SSP Service Switching Point

TBCSM Terminating Basic Call State Model

TDP Trigger Detection Point

USSD Unstructured Supplementary Service Data

Terms

BCSM The BCSM is a high-level finite state machine description of CCF activitiesrequired to establish and maintain communication paths for users.

CCF Entity where the functions for processing a particular call reside.

CCS Common channel signalling is a signalling method in which signallinginformation relating to a multiplicity of circuits or functions or for networkmanagement is conveyed over a single channel by addressed messages.

CS-1 IN Capability Set 1 specifies the first phase of the Intelligent Network platformdefined by ITU-T.

Core INAP Core INAP (Core Intelligent Network Application Part) is an Intelligent Networkprotocol defined by ETSI. It is based on the Capability Set 1 (CS-1) INAPprotocol defined by ITU-T.

DPC The destination point code indicates the signalling point to which the signallingmessage is directed.

DP A detection point is a point in basic call processing at which a processing eventmay be reported to the service control function and processing control can betransferred.

EDP EDP is a detection point which the SCF may arm dynamically in the SSF. Whenan armed EDP is encountered, the SSF reports it to the SCF.

Gapping Gapping sets an upper limit to the output rate of the inquiries allowed towards anSCP. With this control, the number of service requests towards that SCP does notexceed the specified output rate, regardless of the rate of the detected triggers inthe SSP.

GT




A global title is an address used by the SCCP, such as digits dialled by thesubscriber, which does not explicitly contain information that would allowrouting in the signalling network. The SCCP translation function is required.

Implicit disarming Implicit disarming is the method to disarm an event detection point in the INrelationship when a DP is encountered in a BCSM.

IP IP is a physical entity that implements the intelligent network specialized resourcefunction, which includes, for example, DTMF sending and collecting, protocolconversion, speech recognition and synthesized speech provision. The servicelogic program uses the IP to communicate with the subscriber.

MTP MTP is a functional part of a common channel signalling system which transferssignalling messages as required by all the users, and which performs thenecessary subsidiary functions (e.g. error control and signalling security).

MobilityManagement

Mobility management refers to the procedures related to location registration andsubscriber data management when the subscriber is roaming.

OPC OPC indicates the signalling point from which the signalling message was sent.

PIC PIC describes a call control state in the BCSM.

SCF SCF is a functionality located in the Service Control Point. It controls callhandling in the SSP.

SCP The service control point controls call handling in the SSP.

SLP SLP is a program (in the SCP), which implements one or several IN services. OneSLP has one trigger in the IN exchange.

SSF SSF is a set of processes that provide the interaction between a call controlfunction and a service control function.

Service SwitchingPoint (SSP)

SSP is an exchange that implements the service switching functions.

Signalling Channel A signalling channel implements a reliable message transfer between twosignalling points.

SCCP The SCCP provides two different services, the connection-oriented and theconnectionless services for other applications. The SCCP itself uses the MTP as aservice. For example, the connection-oriented service is used for virtualconnections between network elements. The connectionless service enables non-call-related communication between network elements which have to exchangeinformation only for short periods.

Signalling Link



63 (64)

Glossary

A signalling link consists of a signalling data link and a signalling terminalimplementing level 2 functions. The signalling link provides a reliable messagetransfer service between two signalling points.

Signalling Link Set All signalling channels that directly connect two signalling points form asignalling link set.

Signalling Route Signalling Route is a chain of signalling link sets and signalling transfer pointswhich can be used as a path by the signalling point when routing a messagetowards a specific signalling point.

Signalling Route Set Signalling Route Set is a set of all the signalling routes along which messages canbe routed towards a specific signalling point.

STP A signalling transfer point (STP) forwards messages to a destination pointindicated in the address field of the messages. Signalling transfer points functionas links carrying message traffic between signalling points. Signalling transferpoints can also function as signalling points.

SRF The specialised resources function is a set of functions that provide the controland access to resources used in providing services in the intelligent network. TheSRF includes, for example, DTMF sending and collecting, protocol conversion,speech recognition and synthesized speech provision.

Subsystem Subsystem is an SCCP user, identified at a signalling point with a subsystemnumber.

TC TCAP is part of the transaction capabilities that reside in the application layer ofthe OSI protocol references model.

Trigger A trigger is a data structure based on which the SSP starts a dialogue with theSCP.

TDP The TDP is a detection point in a BCSM, which is statically armed in the SSP.When a TDP is met, an IN service specified by the related trigger data may bestarted.

Trigger ReceivingPoint

There are several places in call processing where a trigger key (reference totriggers) can be received. These places are called trigger receiving points. Whenthis trigger key is received, the triggers to which it refers are saved to the internaldata structures of the SSP.




Documents

In Call Flow