cs1 core inap new

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

i770 00828 0300–VHBE ALCATEL UNIVERSITY

HANDOUT

ALCATEL IMPLEMENTATION OF ETSICS1 CORE INAP

Edition : 02

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

iiALCATEL UNIVERSITY 770 00828 0300–VHBE

The Alcatel University put in a great effort to give you this document. In case you have anyremarks, do not hesitate to send us your comments.

Our Training Directory describes all training programmes and modules this document (andothers) is used in.

This document was especially written for use during class instruction. The contents of this document is generic. It deals with concepts and principles, rather thanwith the latest releases of and modifications to the product delivered to the customers.

International audiences use this document. It is therefore written in a clear, concise andabove all, consistent language.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

iii770 00828 0300–VHBE ALCATEL UNIVERSITY

TABLE OF CONTENTS

1. THE BASIC CALL STATE MODEL 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. OPERATIONS USED DURING A SIMPLE IN CALL INITIATED BY THE SSP . . 112.1 InitialDP 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Connect 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 Continue 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4 RequestReportBCSMEvent 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5 EventReportBCSM 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6 ReleaseCall 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7 ResetTimer 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.8 Activity test 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.9 Operations related to information for a specific call. 19. . . . . . . . . . . . . . . . . .

2.10 Cancel 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.11 Special circumstances 20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. OTHER OPERATIONS USED DURING A CALL 21. . . . . . . . . . . . . . . . . . . 3.1 CollectInformation 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 InitiateCallAttempt 22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4. SRF CONNECT PROCEDURES 23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Overview of used operations 23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 IP integrated in SSP or directly attached to it (case A). 24. . . . . . . . . . . . . . .

4.3 The SRF is attached to the SSP but can communicate directly to the SCP (caseB) . 25

4.4 The EstablishTemporaryConnection operation 26. . . . . . . . . . . . . . . . . . . . . . 4.4.1 The assisting SSF receives the ConnectToResource 26. . . . . . . . . . . . .

4.5 The AssistRequestInstructions operation 27. . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6 IP integrated or directly attached to an assisting SSP (case C) 28. . . . . . . .

4.7 Case D 29. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.8 The hand–off procedure 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5. SENDING ANNOUNCEMENTS AND COLLECTING INFO 33. . . . . . . . . . 5.1 Operations used to exchange info with the service user 33. . . . . . . . . . . . . .

5.1.1 PlayAnnouncement (PA) 33. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 SpecializedResourceReport 34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3 PromptAndCollectUserInformation (P&C) 34. . . . . . . . . . . . . . . . . . . . . . . 5.1.4 Cancel 36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Disconnection of the SRF 36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3 Scenarios 37. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6. TRAFFIC MANAGEMENT 43. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 CallGap 43. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

ivALCATEL UNIVERSITY770 00828 0300–VHBE

6.2 Service Filtering 44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Activate Service Filtering 44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 ServiceFilteringResponse 45. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7. CHARGING RELATED OPERATIONS 49. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Charging scenarios 49. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2 SendChargingInformation 50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3 FurnishChargingInformation 51. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4 ApplyCharging & ApplyChargingReport 52. . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.5 An example of the operator specific info available in the charging related operations55

8. CHARGING SCENARIOS 61. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Scenario 1 – Charging completely done in a charging point outside the SSP. . 61

8.2 Scenario 2 – charging completely done in the SSP. 62. . . . . . . . . . . . . . . . . .

8.3 Scenario 3 – Charging done in as well the SSP as a charging point outside the SSP63

8.4 Determination of Charging Information 64. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9. OVERVIEW OF THE OPERATIONS 67. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10.SCENARIOS 71. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11. THE ALCATEL ADDED OPERATIONS 77. . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 AlcFree 77. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11.2 AlcJoin 77. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11.3 AlcSplit 77. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

1.

1770 00828 0300–VHBE ALCATEL UNIVERSITY

1. THE BASIC CALL STATE MODEL

The Basic Call State Model

The BCSM identifies Points In basic Call and connections processing (PICs) or CCFactivities, Detection points (DPs) that indicate PICs at which transfer of control between callcontrol and the Service Control Function can occur, transitions between PICs and finallyevents from and to PICs.

Following figure outlines the BCSM functionality.

Figure 1 : The BCSM components

PIC i

DP a

Transition

Event m...

Event n

Events associatedwith a transition

.

.

.

.

PIC j

DP b

Functional separation is made between the originating half BCSM and terminating halfBCSM, each of which is managed by a functional separate BCM in the SSF/CCF. This canbe the same BCM in one switch or a separate BCM in another switch. ”O” and ”T” is prefixedto certain originating and terminating DP names.

Originating BCSM

Following figure illustrates the originating portion of calls of the BCSM.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED


2ALCATEL UNIVERSITY 770 00828 0300–VHBE

Figure 2 : Originating BCSM

1. O_Null & Authorize Origination_Attempt

2. Collect_Info.

3. Analyse_Info.

1 Orig. Attempt_Authorized

2 Collected_Info.

4. Routing & Alerting

3 Analysed_Info.

5. O_Active

7 O_Answer

6. O_Exception

4

5

Route_Select_Failure

6

O_Call_Party_Busy

O_No_Answer

Route_Busy

10

O_Abandon

9

O_Disconnect

8

O_Mid_Call

Transition

Detection point (DP)

Point in call (PIC)

The description for each of the PICs in the originating half of the BCSM are described below.

1.O_Null & Authorize_Originating_Attempt : this PIC has following functions:

� the interface (trunk/line) is idle and supervision is performed,

� an indication is given from an originating party to place an outgoing call (off hook, N7 IAM(=Initial Address Message), etc.) and the authority/ability to place the call is verified.

2.Collect_Information : this PIC has following functions:

� initial information package/dialling string (service code, prefixes, etc.) are being collectedfrom the originating party and are examined to detect end of dialling (no further actionsare required if the en bloc signalling method is used i.e. N7 IAM message),

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� the support function of the SSF/CCF to collect subsequent digits according to the featurecode (trigger criteria).

3.Analyse_Information : this PIC has following functions:

� the information of DP2 is analyzed and/or translated according to the numbering plan todetermine routing address and call type (e.g. local, transit or international IN exchangecall); this determines the location of the SSF.

4.Routing & Alerting : this PIC has following functions:

� the routing address and call type are interpreted and the next route is selected (with thedirectory number a path is set–up to the physical port),

� authority of originating party to place this particular call is being verified,

� the call is being processed by the terminating half BCSM; continued processing of callset–up (e.g. ringing) is taking place.

5.O_Active : this PIC has following functions:

� the connection is established between originating and terminating party and aaccount/charging data may being collected and call supervision is being provided.

6.O_Exception : this PIC has following functions:

� default handling of the exception condition is provided to ensure no resources remaininappropriate allocated (error information to SCF closing the relationship SSF/SCF,SCF/SRF, etc.).

Terminating BCSM

Following figure illustrates the terminating portion of calls of the BCSM.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 3 : Terminating BCSM

7. T_Null & Authorize Termination_Attempt

8. Select_Facility & Present_Call

12Term. _Attempt_Authorized

10. T_Active

15

11. T_Exception

17

T_Disconnect16

T_Mid_Call

T_Abandon

18

9. T_Alerting

T_Answer

14

13

T_Busy

T_No_Answer

The description for each of the PICs in the terminating half of the BCSM are describedbelow.

7.T_Null & Authorize_Terminating_Attempt : this PIC has following functions:

� the interface (trunk/line) is idle and supervision is performed,

� an indication is given of an incoming call received from the originating half BCSM andauthority to route this call to the outgoing party is being verified.

8.Select_Facility & Present_Call : this PIC has following functions:

� a particular available resource is being selected and the terminating resource is beinginformed of an incoming call (ringing, line seizure, Q.931 set–up message(ISDN), IAMmessage).

9.T_Alerting : this PIC has following functions:

� an indication is sent to the originating half BCSM that the terminating party is alerted;continued processing of call set–up and waiting for the call to be answered.

10.T_Active : this PIC has following functions:

� an indication is sent to the originating half BCSM that the terminating party has answeredand the connection is established between originating and terminating party and callsupervision is being provided.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



11.T_Exception : this PIC has following functions:

� default handling of the exception condition is provided to ensure no resources remaininappropriate allocated (error information to SCF closing the relationship SSF/SCF,SCF/SRF, etc.).

BCSM Detection Points

Certain basic call and connection events may be visible to IN service logic. DPs arethe points in call processing at which these events are detected. DPs for the BCSM areidentified in previous chapters and shown in following figures.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 4 : O–BCSM PICs and DPs

DP1: Originating AttemptDP2: Collected InfoDP3: Analyzed InfoDP4: Route Select FailureDP5: O–Called busyDP6: O–No AnswerDP7: O–AnswerDP!: O–MiddCallDP9: O–DisconnectDP10: O–Abandon

ÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇ


Null

Waiting for terminatingend response


Active

PIC 1

DP 1

PIC 2

DP 2

PIC 3

DP 3

PIC 4

PIC 6

PIC 5

DP 7DP 4

DP 5

DP 6

DP 10

DP 8

ÇÇÇÇÇÇÇÇ

DP 9

Point In Call

Detection Point

Q.71 or Q.931 state

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 5 : T–BSCM PICs and DPs

PIC 7

PIC 11

DP 12

PIC 8

PIC 9

PIC 10

DP 16

DP 15

Q.71 or Q.931State

Detection point

PIC

DP 17

DP 18

DP12: Terminating AttemptDP13: T–Called bustDP14: T–No AnswerDP15: T–AnswerDP16: T–Mid CallDP17: T–DisconnectDP18: T–Abandon

ÇÇÇÇÇÇÇÇ

ÇÇÇÇÇÇÇÇ

ÇÇÇÇÇÇÇÇÇÇÇÇ

ÇÇÇÇÇÇÇÇ

Null

Call present

Call received

Active

ÇÇÇÇÇÇ

A DP can be armed in order to notify an IN service logic that the DP was encountered, andpotentially to allow IN service logic to influence subsequent call processing. If a DP is notarmed then the SSF/CCF continues call processing without SCF involvement. Four types ofDPs are identified:

Trigger Detection Point – Request (TDP–R),

Trigger Detection Point – Notification (TDP–N),

Event Detection Point – Request (EDP–R),

Event Detection Point – Notification (EDP–N).

DPs are characterized by four attributes:

a) Arming/disarming mechanism: A DP may be statistically or dynamically armed. TDP arestatically armed and disarmed by the operator of the SSF. EDP are dynamically armed bythe SCF within the context of a call–associated IN service control relationship.

b) Criteria: It is the condition that has to be met in order to notify the SCF that the TDP wasencountered (not applicable for EDP). This criteria can be based on individual lines/trunks,groups (Centrex) or offices (PABXs).

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



c) Relationship: If a DP is armed and the criteria is met, then the SSF may have a INrelationship with the SCF for the purpose for call/service processing. It is of two kinds:

� control based relation if the SCF is able to influence call processing,

� monitor based relation if the SCF is not able to influence call processing.

d) Call processing suspension: The SSF may suspend call processing to allow the SCF toinfluence subsequent call processing. When it does, it sends an information to the SCFrequesting instructions and waits for an answer. When it does not, the SSF notifies the SCFthat it had encountered a DP and does not expect an answer.

BCSM DP processing

DP processing involves:

� traffic management

� determining if DP criteria are met

� handling service logic interaction when invoking new instances of service (IN or not) logic

� formulating information flows to send to one or more SCFs

Following figure depicts DP processing for each DP type.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 6 : DP processing for each DP type

Servicelogic

FIM– traffic management– feature interactions– message formulation

Trigger notification

Trigger requestinstructions

Respondinginstruction

& request forEDP–Ra)

Event requestinstructions

Respondinginstruction

& request forEDP–Na)

Event notification

DP processingTrigger criteria

DP not armed

Performinstruction

& armEDP–R

TDP–N

TDP–R

EDP–R

Performinstruction

& armEDP–N

EDP–N

DP

ResumeDP

DP

ResumeDP

DP

DP

BCSM PICDP–R arming

INIT–PIC

DP

DP

BCSM PICDP–N arming

INIT–PIC

DP

ResumeDP

DP–N armed

Basic call processfunction (BCSM PIC)

CCF SSF SCF

BCM

DP Detection pointTDP Trigger detection pointEDP Event detection pointR/N Request/notificationPIC Point in call

DP–R armed

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

2. OPERATIONS USED DURING A SIMPLE IN CALL INITIATED BY THE SSP


2. OPERATIONS USED DURING A SIMPLE IN CALL

INITIATED BY THE SSP

An SSF can be activated via different possibilities :

� If the CCF indicates that an armed TDP, related to a possible IN call is encountered.Then the SSF must perform following actions:

– check if call gapping or service filtering mechanisms are active. If service filtering isactive, the call is counted and the SSF instructs the CCF to release the call.

– check if the SCF is accessible.

– determine if DP criteria are met.

If the previous steps allow it and if the DP is a TDP–R ,an InitialDP must be sent to theSCF. The SSF must wait for further instructions of the SCF before continuing.

� If the SSF receives from the SCF the InitiateCallAttempt related to a new transaction. This will be handled in a separate chapter.

2.1 InitialDP

Via this operation the SSF initiates the dialogue with the SCP for this call. It is sent after thefirst TDP–R is met.

If Call gapping and Signalling N7 overload are not there for the call, then the InitialDPoperation is sent.

InitialDPArg ::= SEQUENCE {

serviceKey [0] ServiceKey ,

calledPartyNumber [2] CalledPartyNumber OPTIONAL,

callingPartyNumber [3] CallingPartyNumber OPTIONAL,

callingPartysCategory [5] CallingPartysCategory OPTIONAL,

cGEncountered [7] CGEncountered OPTIONAL,

iPSSPCapabilities [8] IPSSPCapabilities OPTIONAL,

iPAvailable [9] IPAvailable OPTIONAL,

locationNumber [10] LocationNumber OPTIONAL,

originalCalledPartyID [12] OriginalCalledPartyID OPTIONAL,

highLayerCompatibility [23] HighLayerCompatibility OPTIONAL,

serviceInteractionIndicators [24] ServiceInterActionIndicators OPTIONAL,

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



additionalCallingPartyNumber [25] AdditionalCallingPartyNumber

OPTIONAL,

forwardCallIndicators [26] ForwardCalllIndicators OPTIONAL

bearerCapability [27] BearerCapability OPTIONAL,

eventTypeBCSM [28] EventTypeBCSM OPTIONAL

redirectingPartyID [29]RedirectingPartyID OPTIONAL,

redirectionInformation [30]RedirectionInformation OPTIONAL,

}

The service key is used to address the correct application within the SCF.Previously in the Alcatel INAP operations , the SSN at SCCP level was used to address acorrect application.

CGencountered indicates the type of call gapping if encountered.

The original calledparty Id can be necessary for instance in the case of forwarding.

The location number conveys the geographical area address for mobility services.It is required when the calling party number doesn’t contain any information about thegeographical location of the calling party.This is required when for instance origin dependent routing is applied and the calling party isa mobile subscriber.

The forward call indicators specify if the call will be treated as a national or internationalcall.And also the signalling capabilities of the network access , the preceding network connectionand the succeeding network connections.

The eventTypeBCSM indicates the armed DP event that caused the InitialDP operation.

IP available indicates if an IP is attached and available at the SSP (IP available or IP notavailable). This will later influence the scenario for sending announcements to thesubscribers. See the chapter about SRF connect procedures.

IPSSP capabilities indicates which SRF resources are supported within the SSP andavailable. It is defined by the network operator.

We will encode the IPSSPCapabilities as an octet string of 4 bytes. Every bit represents acapability, so maximum 32 capabilities can be indicated..Every bit is called a Basic Function.If the Basic Function bit is 0, then the capability is not available.The use of it is market dependent.A Basic function can for instance indicate a set of announcements available.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



2.2 Connect

The SCF orders the SSF to perform call processing actions to route or forward a call to aspecified destination.As indicated in the parameters of the operation, the SSF can use calling party information,such as dialled digits.Also existing setup information, such as a list to a trunkgroup can be used for this purpose ifprovided by the SCF.

The connect parameters are the following :

ConnectArg ::= SEQUENCE {

destinationRoutingAddress [0] DestinationRoutingAddress,

alertingPattern [1] AlertingPattern OPTIONAL,

correlationID [2] CorrelationID OPTIONAL,

cutAndPaste [3] CutAndPaste OPTIONAL,

originalCalledPartyID [6] OriginalCalledPartyID OPTIONAL,

routeList [7] RouteList OPTIONAL,

scfID [8] ScfID OPTIONAL,

serviceInteractionIndicators [26] ServiceInteractionIndicators OPTIONAL,

callingPartyNumber [27]CallingPartyNumber OPTIONAL,

callingPartysCategory [28]CallingPartysCategory OPTIONAL,

redirectingPartyID [29]RedirectingPartyID OPTIONAL,

redirectionInformation [30]RedirectionInformation OPTIONAL,

}

The destinationRoutingAddress can also include a correlation Id and SCF Id if it is used inthe context of an hand–off procedure.Then the separate parameters ”correlation ID and SCP ID” shouldn’t be used.

The scfId indicates the SCF identifier such that the assisting SSF knows to which SCF thecollected info must be sent. (See the chapter about SRF connect procedures)

The correlation id is used by the SCF to associate the AssistRequestInstructions from theassisting SSF with the InitialDP from the initiating SSF.

The ”routeList” is used to select an outgoing trunkgroup.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Alcatel added some parameters to the Connect operation to support backward compatibilitywith the Alcatel INAP protocol.

� doNotJoin [99] IMPLICIT NULL OPTIONAL,

� legIdA [98] LegId DEFAULT (2),

� legIdB [97] LegId DEFAULT (1),

� callingPartyPNP [96] OCTET STRING(SIZE(4..8)) OPTIONAL,

� calledPartyPNP [95] OCTET STRING(SIZE(4..8)) OPTIONAL,

� callingPartyBCGIdentity [94] OCTET STRING(SIZE(7)) OPTIONAL,

� reservedTrunk [93] ReservedTrunkIndicator DEFAULT {0},

� genericNumberSet [92] IMPLICIT SEQUENCEgenericNumber[0] IMPLICIT OCTETSTRING(SIZEx))} OPTIONAL

� originatingPTNXIdentity [90] IMPLICIT INTEGER(1..32000) OPTIONAL,

� originatingPTNXIdentity [90] IMPLICIT INTEGER(1..32000) OPTIONAL,

In order to detect a route select failure after a Connect, it is necessary to explicitly arm the”Route Select Failure” EDP via the RequestReport BCSM Event before sending a Connect.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



2.3 Continue

At some DPs the SSF suspends call processing to wait for SCF instructions.With the Continue operation , the SCF orders the SSF to proceed with call processing at theDP, where it suspended and to go to the next PIC in the BCSM.

The SSF continues call processing without substituting new data from the SCP.

2.4 RequestReportBCSMEvent

The SCF uses this operation to ask the SSF to monitor call–related events and send anotification to the SCF when the event is detected.

The supplied information consists of a list of information. For every event, it contains :

� EventTypeBCSM

� monitor mode

� legID

� dpSpecificCriteria

Possible BCSM event types are :

� originating attempt authorized,

� collected info

� analyzed information

� route select failure

� OCalled Party busy

� O No answer

� O answer

� O Midcall

� O Disconnect

� O abandon

� Terminating attempt authorized

� T called party busy

� T No answer

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� T answer

� T mid call

� T Disconnect

� T abandon

The monitor mode can have 3 values :

� interrupted (0)

� notifyAndContinue (1)

� transparent (2)

Interrupted means that the SSF reports the event received on the indicated leg as arequest. This value is also used to end the monitoring of a previously requested chargingevent.

If the mode is NotifyAndContinue , the event is reported as a notification.This means that the event is also processed on the other leg.

In transparent mode, the SCF is not notified, and the event detected on the indicated leg isalso processed on the other leg..

The dPSpecificCriteria indicates information specific to the EDP to be armed.DpSpecific criteria can be a number of digits or an application timer.The SCF can specify the number of digits to be collected by the SSF for the CollectedInfoevent.When all digits are collected, the SSF reports the event to the SCF.For the No answer event , the SCF can specify a timer. If the user doesn’t answer the callwithin the specified time, the event is reported to the SCP.

After receipt of the RequestReportBCSMEvent operation, the SSF arms the requestedEDPs as indicated.

Requested events are monitored :

� until ended by a transparent monitor mode,

� until the end of the call,

� until the EDPs are detected

� or until the corresponding leg is released.

2.5 EventReportBCSM

This operation is used from SSF to SCF to report a call related event such as busy or noanswer.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



The reporting of these events is previously requested by the SCF via theRequestReportBCSMEvent.

Each of the previously requested events in the RequestReportBCSMEvent is reported in aseparate EventReportBCSM operation.

The event must be an armed EDP.

The information carried by this operation is the following :

� eventTypeBCSM,

� event specific information BCSM

� the Leg id

� and miscellaneous call info (request –> EDP–R or notification –> EDP–N). Thisindicates whether the event report results from a RequestReportBCSMEventRequestwhich monitor mode was ”interrupt” or ”Notify&Continue”

The event specific information can be different for each type of BCSM event :

– collected info the called party number

– analyzed information the called party number

– route select failure cause

– OCalled Party busy cause

– O No answer

– O answer

– O Midcall

– O Disconnect cause

– T called party busy cause

– T No answer

– T answer

– T mid call

– T Disconnect

The leg id indicates the party in the call for which the event is reported.

leg id ”1” indicates the party present at the InitialDP, or the party created with anInitiateCallAttempt.

leg id ”2” indicates the party created with a connect operation.

Default leg id =”1” for CollectedInfo, AnalyzedInformation O–Abandon and T–Abandon.Default leg id =”2” for RouteSelectFailure, O–calledPartyBusy, O–NoAnswer, O–Answer,T–CalledPartyBusy,, T–NoAnswer and T–Answer.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



2.6 ReleaseCall

This operation allows the SCF to instruct the SSF to release an existing call for all involvedparties.This operation can also be sent to an assisting SSF, but only in the case of an hand–offprocedure.The only parameter that can be supplied is a cause.

2.7 ResetTimer

Via this operation, the SCF instructs the SSF to reset certain application timers.This is to avoid timing out in the SSF, for instance used, when announcements are sent andassisting SSFs are used.The supplied info is a timer identity and a timer value.

2.8 Activity test

The ActivityTest is initiated by the SCF to check if a dialogue between SCF and SSF is stillexisting. It is a class 3 operation . If Everything is OK the SSF should send a result.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



2.9 Operations related to information for a specific call.

A SCF can ask an SSF to record specific information about a single call via theCallInformation Request. This specific call information is sent by the SSF to the SCF in theCallInformation Report

CallInformationRequest

ARGUMENT

CallInformationRequestArg

ERRORS{

MissingParameter,

ParameterOutOfRange,

RequestedInfoError

SystemFailure,

TaskRefused

UnexpectedComponentSequence,

UnexpectedParameter,

}

CallInformationReport

ARGUMENT

CallInformationReportArg

Information that can be asked for is for example :

� call attempt elapsed time,

� call stop time,

� call connected elapsed time,

� called address and

� release cause.

2.10 Cancel

A Cancel operation can be initiated by the SCF and sent to the SSF or SRF to cancelprevious sent PlayAnnouncement and PromptAndCollectUserInformation operations.

If the Cancel is used to delete a previously invoked PA or P&C the cancel must include aninvoke id.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



The Cancel operation can also be used to cancel all outstanding requests of the followingoperations :

� EventReportBCSM

� ApplyChargingReport

� CallInformationReport

2.11 Special circumstances

If the calling party abandons the call before it is answered, then the SSF should instruct theCCF to clear the call and ensure that all resources allocated to the call are released.

� If a CallInformationRequest is pending, first a CallInformationReport must be sent.

� If an Abandon DP is armed as an EDP–R, an EventReportBCSM operation must besent. The SSF must wait for instructions of the SCF before continuing.

� If an Abandon DP is armed as an EDP–N, an EventReportBCSM operation must besent. The SSF can terminate.

In any state of the stable call, one of the call parties can disconnect.The following procedures are similar as in the previous case.

� If a CallInformationRequest is pending, first a CallInformationReport must be sent.

� If the Disconnect DP is armed as an EDP–R, an EventReportBCSM operation must besent. The SSF must wait for instructions of the SCF before continuing.

� If the Disconnect DP is armed as an EDP–N, an EventReportBCSM operation must besent. The SSF can terminate.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

3. OTHER OPERATIONS USED DURING A CALL



3.1 CollectInformation

With this class 2 operation , the SCF requests the SSF to prompt a calling party to inputdestination information and collect it according a specific numbering plan.This can for example be used in a VPN call scenario.

An SSF can invoke an initial DP.If the SCP determines that more information from the calling party is required beforecontinuing processing, he can send a CollectInformation operation.

Then the SSF will collect destination information from the calling.This operation uses only the resources of the SSF and CCF to collect additional information,this in contrast to the PromptAndCollectUserInformation operation.

This operation can only be used for a call which is still in set up phase.

The CollectInformation operation is normally associated with a RequestReportBCSMEventoperation to arm DP2 (collected info) and specify the number of digits to be collected.

When the required number of digits are received, DP2 is encountered and anEventReportBCSM will send the received digits to the SCF.

Figure 7 : Collect info procedure

SSP SCPAfter digit analysisCall handling decidesit is an internationalcall and only charging info is required

Initial DP (calledPartyNumber = 00,eventTypeBCSM = DP3)

After analysis,

the SCP decides

that additional

info is requiredRequestReportBCSMEvent (DP2,mode = interrupted, DPspecificcriteria = number of digits)

CollectInformation

The SSP collects the requested info andsends them to theSCP EventReportBCSM (DP2, collectedinfo)

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



3.2 InitiateCallAttempt

Some calls are initiated by the SCP , for example the wake up call. Then the SCP sends the InitiateCallAttempt operation to the SSF to create a new call to onecall party using the addressing information as provided by the SCF.

An EDP–R is armed on answer and also for all call failure events. This is because the SCFinitiated the call and so has to treat the call when one of the events is encountered.

The InitiateCallAttempt shall be sent together with a Continue operation

Figure 8 : Wake up

SSP SCP

InitiatecallAttempt

RequestReportBCSMEvent (DP=answer,mode = interrupted, DPspecificcriteria = number of digits)

EventReportBCSM (DP=answer)

AN ANNOUNCEMENT IS SENT

Release

The InitiateCallAttempt can also be used to support the feature of Call Duration Advice(CDA)

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

4. SRF CONNECT PROCEDURES



The InitialDP operation contains the parameter IPSSPcapabilities, which indicates the SRFfunctions available at the SSP. So the SCP will know whether assisting SSPs are required ornot.

It can be that the help of another SSP is required to communicate to an IP functionality.If the IP functionality is not required for the call anymore, then 2 possibilities exist :

� The call responsibility is returned to the initiating or assisting SSP. This is the case in theassisting procedure .

� The call responsibility is kept in the assisting SSP. This is the case in the hand–offprocedure .

Several possibilities are described in this chapter.

4.1 Overview of used operations

EstablishTemporaryConnection

This operation is used by the SCF to order the SSF to create a connection to aresource (an SRF or an assisting SSF) for a limited period of time. This is used forexample to play announcements, to collect user information. It is for example used inthe assist procedure.

ConnectToResource

This class 2 operation is sent from the SCF to the SSF to connect a call from the SSFto the SRF.

The ConnectToResource operation contains the physical location of the SRF.This is only used in the case that the SSF relays all operations to the SRF and allresponses from the SRF to the SCP.

The ConnectToResource is used if the IP cannot communicate directly to the SCP.

AssistRequestInstructions

This operation is some kind of response to the EstablishTemporaryConnection orConnect (in case of hand–off).

This operation is sent by the assisting SSF or SRF when the initiating SSF has set up aconnection to the SRF or the assisting SSF

The use of these operations will become more clear in the discussion of the differentconnect procedures.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



4.2 IP integrated in SSP or directly attached to it (case A).

Figure 9 : IP integrated in SSF or directly attached to it.

SCFSCP

SRFSSF

CCF

SSP

IP(can be integrated ornon–integrated)

CASE A

In case A, the IP is integrated in the SSP or directly attached to it.The SCP cannot communicate directly with the IP, so all operations exchanged betweenSCP and IP are relayed via the SSP.It can for instance be that the SSP has to do a protocol translation.

Figure 10 : The case A procedure

SCP SSP IP

Connect to ResourceSetup request

Setup response

The dotted lines represent a kind of signalling messages between the SSP and IP.It can be that this signalling is based on TCAP or DSS or another system.If SSP and IP are integrated, the communication between them is of course implementationdependent.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



4.3 The SRF is attached to the SSP but can communicate directly to the SCP(caseB)

Figure 11 : SRF can communicate directly with the SCP

SCFSCP

SRFSSF

CCF

SSP IP

CASE B

In case B the IP is directly attached to the SSP. First the SCF orders the SSP to establish a temporary connection to the IP.Since The IP can communicate directly to the SCP, an additional message to the SCP isrequired to indicate that the IP is ready. This is the Assist Requestinstruction operation. TheSCF can communicate directly with the IP, the relaying function of the SSP is not requiredanymore. Although the SSP can function as an STP.

Figure 12 : The case B procedure

SCP Initiating SSP IP

Establish Temporary Connection(correlation ID = 1, SCFID = 96)

Setup request

Setup response

Assist Request Instructions

(correlation ID = 1, SCFID = 96)

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



4.4 The EstablishTemporaryConnection operation

As shown in the previous and following figures the EstablishTemporaryConnection is usedto create a connection between an initiating SSF and an assisting SSF in the service assistprocedure. It can also be used to create a connection between an SSF and SRF, where theSRF can be separately addressed.

Following parameters are defined for the EstablishTemporaryConnection

� assistingSSPIPRoutingAddress

� correlationID

� scfID

� serviceInteractionIndicators

Only the first parameter is mandatory and it indicates the destination address of the SRF orthe assisting SSF for the assist procedure.Part of this address can be a correlation identity and an SCF identity.

The correlation id is used by the SCF to associate the AssistRequestInstructions with theInitialDP from the initiating SSF.

4.4.1 The assisting SSF receives the ConnectToResource

The following can happen:

� A SCF–SRF operation is received, the assisting SSF should relay this information to therelated SRF.This can be the following SCF–SRF operations

– Play Announcement

– PromptAndCollectUserInformation

– Cancel

� An SRF–SCF operation is received and must be relayed to the SCF. This can be thefollowing SCF–SRF operations

– SpecializedResourceReport

– a return result from a PromptAndCollectUserInformation.

An assisting SSF becomes idle again after the receipt of a bearer channel disconnect fromthe initiating SSF.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



4.5 The AssistRequestInstructions operation

The AssistRequestInstructions is initiated by the assisting SSF or SRF as a reaction to theEstablishTemporaryConnection.The SCF shall ask the initiating SSP to continue the processing of the call in the future.

The SCF Identity provided in the EstablishTemporaryConnection identifies the SCF to whichthe AssistRequestInstructions must be sent.

The Assist Request Instructions from the SRF carries a correlation ID to correlate it with theInitial DP from the initiating SSP.

AssistRequestInstructionsArg ::= SEQUENCE {

correlation ID [0] CorrelationID ,

iPAvailable [1] IPAvailable OPTIONAL,

iPSSPCapabilities [2] IPSSPCapabilities OPTIONAL,

extensions [3] SEQUENCE SIZE(1..numOfExtensions) OF Extensionfield

OPTIONAL

}

The value of the Correlation Id may be supplied by the EstablishTemporaryConnection.

If the AssistRequestInstructions was received from an assisting SSF, the SCP sends aConnectToResource, followed by a PlayAnnouncement or aPromptAndCollectUserInformation.

If the AssistRequestInstructions was received directly from an SRF, the SCP sends directly aPlayAnnouncement or a PromptAndCollectUserInformation operation. So, if the SRF can communicate directly to the SCP, no ConnectToResource is used.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



4.6 IP integrated or directly attached to an assisting SSP (case C)

An assisting SSF is activated after the receipt of a connect from another SSF indicating thatan assist is required.

Then the assisting SSF sends an AssistRequestInstructions to the SCF, and waits forinstructions from the SCF.

Following operations can be received by the assisting SSF from the SCF :

� PromptAndCollectUserInformation

� PlayAnnouncement

� FurnishChargingInformation,

� ApplyCharging,

� SendChargingInformation,

� ConnectToResource,

� ReleaseCall (only used in the hand–off case).

Figure 13 : IP integrated or directly attached to an assisting SSP (case C)

SCFSCP

SRFSSF

CCF

Initiating SSP IP

CASE C

SSF

CCF

Assisting SSP

In case C ,the IP is integrated or directly attached to another SSP (an assisting SSP) thanthe one communicating with the SCP. But the operations to and from the SCP are relayedvia that other SSP, that is the reason why this method is called the ”assist method”.On completion of the interaction with the user for announcement and additional informationcollection, control is returned to the first SSP.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 14 : scenario case C


Establish Temporary Connection

Setup request

Setup response


Assisting SSP

Connect To Resource

4.7 Case D

In case D ,the IP is integrated or directly attached to another node then the SSPcommunicating with the SCP. The SCP can communicate directly with the SRF.An establishment of a transaction to the assisting exchange is not required, so it needn’t bean SSP.On completion of the interaction with the user for announcement and additional informationcollection, control is returned to the first SSP.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 15 : Case D

SCFSCP

SRFSSF

CCF

SSP IP

CASE D

CCF

Exchange

Figure 16 : scenario case D

SCP SSP IP


Setup request

Setup response


Exchange

Setup request

Setup response

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



4.8 The hand–off procedure

Case e describes the hand–off procedure , the configuration is similar as in case c. Thedifference is that in the hand off procedure, after user interaction the control is retained atthe assisting SSF.

Here no Establish Temporary Connection is used, but a Connect operation. This is becauseafter the interaction with the service user and the SRF , the control remains at the assistingSSF.

Figure 17 : scenario case E, the hand–off case


ConnectSetup request

Setup response


Assisting SSP

Connect To Resource

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 18 : The hand off procedure

SCFSCP

SRFSSF

CCF

Initiating SSP IP

CASE E

SSF

CCF

Assisting SSP

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

5. SENDING ANNOUNCEMENTS AND COLLECTING INFO


5. SENDING ANNOUNCEMENTS AND COLLECTING

INFO

5.1 Operations used to exchange info with the service user

5.1.1 PlayAnnouncement (PA)

This operation instructs the SRF to play an announcement.

In the case of an assist procedure with a second SSP or in the case of a separate IP thatcan communicate directly to the SCP, it is used by the SCF after an”AssistRequestInstructions”.

If the IP can communicate directly to the SCP, the PlayAnnouncement is sent after the AssistRequestInstructions.If the SSP or assisting SSP is required to relay info between the SCP and the SRF, thePlayAnnouncement can only be sent after a ConnectToResource operation.

The PlayAnnouncement operation can be used for inband interaction with an analoguesubscriber. In this case the SRF is usually collocated with the SSF for standard tones andannouncements.

The SRF can of course also interact with ISDN subscribers.

Here follow the parameters of the Play Announcement operation.

PlayAnnouncementARGUMENT

PlayAnnouncementArg

ERRORS{

Cancelled,

MissingParameter,

SystemFailure,

UnavailableResource,


UnexpectedDataValue,


}

LINKED{

SpecializedResourceReport

}

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



PlayAnnouncementArg ::= SEQUENCE {

informationTosend [0] InformationToSend,

disconnectFromIPForbidden [1] BOOLEAN,

requestAnnouncementComplete [2] BOOLEAN,

extensions [3] SEQUENCE SIZE(1..numOfExtensions)

OF ExtensionField OPTIONAL

}

InformationToSend ::= CHOICE {

inbandinfo [0] InbandInfo,

tone [1] Tone,

displayInformation [2] DisplayInformation

}

The PlayAnnouncement operation specifies the announcement, tone or display informationto be sent to the subscriber by the SRF.

The operation also contains the parameter : ”disconnectFromIPForbidden”.This parameter indicates whether or not the SRF can be disconnected from the user whenall information is sent.

Another parameter is the RequestAnnouncementComplete. It indicates if aSpecializedResourceReport must be sent to the SCF when all information has been sent tothe end–user.

Note : The current signalling systems don’t provide an indication whether or not info can bedisplayed by the user’s terminal.In case of interaction with an ISDN user 2 consecutive PlayAnnouncement operations are sent.The first contains the display info, the second the inband information.

5.1.2 SpecializedResourceReport

The SRF responds the PlayAnnouncement with a SpecializedResourceReport if in thePlayAnnouncement, an ”requestAnnouncementComplete” parameter is set.


ARGUMENT

SpecializedResourceReportArg

SpecializedResourceReportArg ::= NULL

5.1.3 PromptAndCollectUserInformation (P&C)

This operation is sent from the SCF to the SRF to collect user information.The information to be collected is normally digits.The information to send can again be an announcement, a tone or display information.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



The operation also contains the parameter : ”disconnectFromIPForbidden”.

Note : The current signalling systems don’t provide an indication whether or not info can bedisplayed by the user’s terminal.In case of interaction with an ISDN user , the ”displayInformation” parameter is not used in the”PromptAndCollectUserInformation” operation. Instead the play announcement is used containingthe ”Displayinfo” parameter. This is followed by a P&C operation containing inband information.

If the SCP receives an AssistRequestInstructions operation from an assisting SSF, theConnectToResource and PA or P&C is sent to the assisting SSP.

If the SCP receives the AssistRequestInstructions directly from the SRF, the PA or P&C issent immediately to the SRF.

PromptAndCollectUserInformation

ARGUMENT

PromptAndCollectUserInformationArg

RESULT

ReceivedInformationArg

ERRORS{

Cancelled,

ImproperResponse,

MissingParameter,

SystemFailure,

UnavailableResource,




}

PromptAndCollectUserInformationArg ::= SEQUENCE {

collectedinfo [0] Collectedinfo,

disconnectFromIPForbidden [1] BOOLEAN,

informationToSend [2] InformationToSend,

extensions [3] SEQUENCE SIZE91..numOfExtensions)

OF ExtensionField OPTIONAL

}

Collectedinfo consists of collected digits

ReceivedInformationArg consists also of digits

In the following, we will use as an abbreviation for the PlayAnnouncement operation PA.For the PromptAndCollectUserInformation, the abbreviation P&C will be used.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



The operations ConnectToResource and the first PA or P&C can be carried in 1 N7 TCAPmessage.

5.1.4 Cancel

A Cancel operation can be initiated by the SCF and sent to the SSF or SRF to cancelpreviously sent PlayAnnouncement and PromptAndCollectUserInformation operations.

If the Cancel is used to delete a previously invoked PA or P&C the cancel must include aninvoke id.

5.2 Disconnection of the SRF

In both the PA and the P&C, the parameter ”disconnectFROMIPForbidden ” is present.Via this boolean,the SCF enables or disables the disconnect from the user initiated by the IP.

If the SRF initiated disconnect is not enabled, the SCF asks the SRF to inform it of thecompletion of user interaction .For the PA, this is done by a SpecializedResourceReport,For the P&C the return result is used.

The SCF can explicitly order the disconnect by a DisconnectForwardConnectionoperation.

The SRF disconnect is enabled by the SCF within a PA or a P&C operation via theparameter ”disconnectFromIPForbidden = FALSE”.Then the SRF can disconnect on completion of user interaction.

If the SCF sets the parameter ”disconnectFromIPForbidden” on TRUE, it shall later onexplicitly order the disconnect of the SRF.

If a number of PC or P&A operations are to be executed by the same SRF, the SCF certainlyinhibits the SRF disconnect for all operations except for the last one.The SCF can also inhibit the SRF initiated disconnect for the last PA or P&C.

The SCF either enables the SRF initiated disconnect at the last PA or P&C or the SCF willlater explicitly order the disconnect.

In the case of the assisting SSF, the SRF initiated disconnect is not used.The assisting SSF doesn’t propagate the SRF initiated disconnect to the initiating SSP.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



In fact the DisconnectForwardConnection is used in 2 cases :

� To explicitly disconnect a connection to a SRF, established previously with aConnectToResource operation or an EstablishTemporaryConnection (used to connect acall from the SSF to a specialized resource).

� To clear the temporary connection between an initiating and an assisting SSF.

5.3 Scenarios

Figure 19 : The SSP with integrated SRF, an SRF initiated disconnect

SCP SSP IP


Setup response

PlayAnnouncementPlayAnnouncement

SpecializedResourceReportSpecializedResourceReport

Disconnect

DisconnectFromIPForbidden = FALSE

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 20 : The SSP relays messages between the SCF and SRF, SCF initiated disconnect

SCP SSP IP


Setup response

Prompt&CollectUserInfo

Disconnect

Prompt&CollectUserInfo

P&C return resultP&C return result

DisconnectForwardConnection

DisconnectFromIPForbidden =TRUE

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 21 : Direct SCP–IP information transfer

SCP SSP IP

Establish Temporary ConnectionSetup request

Setup response


Play Announcement

Specialized resource Report

Disconnect

DisconnectFromIPForbidden = FALSE

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



As illustrated in figure 22, the SCP uses the operation ”DisconnectForwardConnection”.If the initiating SSF receives this, it releases the bearer channel connection towards theassisting SSP and SRF.

Figure 22 : SSP Assist/hand–off

SCP SSP IP


Setup request

Setup response


Assisting SSP

Setup request

Setup response

ConnectToResource

P&C(see note 1)

P&C

RR for P&CRR for P&C

DisconnectForwardConnection

Disconnect

Disconnect

Note 1 : Disconnect FromIPForbidden = TRUE.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 23 : Account calling card SSP with integrated SRF

SCP SSP IP


Setup response

P&CP&C

P&C result

Disconnect

DisconnectFromIPForbidden = TRUE

InitialDP

Connect

P&C result

P&CP&C

P&C result

DisconnectFromIPForbidden =FALSE

P&C result

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

6. TRAFFIC MANAGEMENT



Different procedures are foreseen :

� call blocking

� call gapping

� call filtering

6.1 CallGap

Call gapping is a traffic management method where a time period is specified between twoconsecutive calls.

This class 4 operation is initiated by the SCF to reduce the rate at which specific servicerequests are sent to the SCF.The CallGap operation may be received inside as well as outside a call context transaction.

Following parameters can be present in the CallGap operation:

� gap criteria

� gap indicators

� control type

� and gap treatment

The Gap criteria indicate which calls are subject to gapping.Following possibilities exist :

� called address

� service key

� called address and service key

� calling address or location number and service key

The gap indicators specify the duration , during which call gapping for a specified criteria isactive and a gap interval .The gap interval is the minimum time between calls being allowed through.

� gap interval = 0, means that all calls meeting the gap criteria are not rejected, no callgapping is applied,

� gap interval = –1, means that all calls meeting the criteria are to be rejected

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� other values indicate an interval in milliseconds.

� Duration = 0, indicates gapping to be removed,

� Duration = –1, indicates infinite duration,

� Duration =– 2, network specific duration.

� Other values indicate a duration in seconds.

The control type is the reason for activating call gapping.At the moment two possibilities are identified :

� SCP Overloadedand

� manually initiated

SCP overload indicates that an automatic congestion detecting mechanism in the SCPdetected the problem.

Manually initiated indicates that the management center initiated call gapping.

Gap treatment indicates how calls stopped by the gapping mechanism must be treated.Different possibilities are :

� Sending information : inband info , tone or textual info

� release cause

� or both

If the congestion level changes new call gap operations can be sent with the same activegap criteria but with a new gap interval.

6.2 Service Filtering

6.2.1 Activate Service Filtering

The ActivateServiceFiltering operation is a class 1 operation initiated by the SCP.It is used for televoting or mass call services.After receiving this operation, the SSF handles calls to specified destinations withoutsending queries to the SCP for every detected call.

The relevant counters and announcements can be located at the SSF.The operation initializes the specified counters in the SSF.

The ActivateServiceFiltering may only be received outside a call context transaction.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



6.2.2 ServiceFilteringResponse

Via this operation, the SSF can send the values of the counters to the SCF in reaction to apreviously received ActivateServiceFiltering .

Figure 24 : Service filtering

SCP SSP

ActivateServiceFiltering ( filteringCharacteristics = 3 calls,nbr of counters =1,service key)

ServiceFilteringResponse

IN call, counted &released

IN call, counted &released

IN call, allowed

Initial DP

The ActivateServiceFiltering contains following information about how filtered calls aretreated :

ActivateServiceFilteringArg ::= SEQUENCE {

filteredCallTreatment [0] FilteredCallTreatment,

filteringCharacteristics [1] FilteringCharacteristics,

filteringTimeout [2] FilteringTimeout,

filteringCriteria [3] FilteringCriteria,

startTime [4] DateAndTime,

}

The parameter filteredCallTreatment contains following information :

� Charging approach for filtered calls. This is network operator specific.

� Announcements, tones or display information to be sent to the calling party. At the end ofsending this information, the call is released,

� the number of counters used,

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� the release cause used for call release to be applied to filtered calls.

The maximum number of counters is the number of counters to be allocated as well as thenumber of destinations included in service filtering.If several destination addresses are provided in filtering criteria, one counter is assigned perdestination address. This is only possible if filtering criteria are specified via calledaddresses.The numbers to be filtered are from calledAddressValue up to and including calledAddressValue + maximum number of counters –1.

The parameter filteringCharacteristics indicates the severity of the filtering and the point intime when the ServiceFilteringResponse will be sent.It determines whether ”interval ” or ”number of calls” is used.

Interval : After expiration of the interval timer following actions can occur on arrival of anew call ,an Initial DP can be sent together with a ServiceFilteringResponse.– The interval timer is started again.Interval = 0 means no filtering is applied, new calls result in an Initial DP.Interval = –1 means no Initial DP or Service Filtering Response.Otherwise, the interval is specified in seconds.

number of calls : Every nth call causes an InitialDP and a ServiceFiltering Response.This happens if the sum of all counters assigned to one service filtering entity equalsNumber of Calls.

Filtering Timeout indicates the duration of the filtering.If the time expires a ServiceFilteringResponse is sent and service filtering is stopped.It can be done via specifying a ”duration” or via specifying a ”stop time”.

REMARK !

The ActivateServiceFiltering and the ServiceFilteringresponse are also used to supporttelevoting.

The filtering criteria specify which calls are filtered.The filtering can be based on :

� a service key,

� a calling address value,

� a calledAddressValue,

� or a location number.

The location number identifies the geographical area from which the call to be filteredoriginates.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



To change the parameters of an existing service filtering entity, the SCF sends a secondActivate Service Filtering with the same filtering criteria.

The ServiceFilteringResponse operation is used to report the values of counters specified inthe ActivateServiceFiltering.

ServiceFilteringResponsearg ::= SEQUENCE {

countersValue [0] CountersValue,

filteringCriteria [1] FilteringCriteria,

extensions [2] SEQUENCE SIZE91..numOfExtensions) OF Extensionfield

OPTIONAL

}

The filtering criteria parameter is used to address the concerned SLP instance. It consists of a service key alone or a service key together with a called address.

After sending a ServiceFilteringResponse, the service filter counters are reset.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

7. CHARGING RELATED OPERATIONS



7.1 Charging scenarios

With the introduction of IN, charging capabilities will be extended.

Charging processes can be activated in the SSP, in the SCP or both.

So, it can be that charging processes in the SSP and the SCP have to interwork viaexchanging operations.

Charging of IN calls follows the following structure, this is :

� Charge Determination

� Charge Generation

� Charge Registration

� On–line Charge Information provision

� Charge Output

� Off–line charging billing and accounting

The Charge Analysis (Determination) defines

� the charge party (calling line, IN subscriber or both),

� the level of charge,

� the items to be charged,

Charge Generation generates charge pulses, charge related signalling or charge relatedinfo for the off–line process.

Charge Registration updates the charging meters or creates call records or both.

On–line Charge Information provision , provides charging pulses or signalling informationon the user/network interface during the call.

The charge output process puts data on magnetic tapes or datalinks for furtherprocessing.

The introduction of Intelligent Networks with its resulting split of functionality over separatephysical entities has placed additional requirements on the charging of such calls.

Several operations are defined for communicating charging related information between theSCF and the SSF.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



7.2 SendChargingInformation

The SCF uses this operation to instruct the SSF on the charging information to be sent bythe SSF to a local exchange.

Some examples where the SCP input can be required to determine charging in the localexchange are :

� The charging in the local exchange must be inhibited.

� The local exchange explicitly asks to determine the traffic at a remote site.

� Advice of Charge (AOC).

The SSF can transfer this information via signalling or charging pulses.In the local exchange, this information can be used to update the charge meter or to create astandard call record.

For example, the SCF can via this operation instruct the SSF to initiate the PSTN or ISDNcharging functions according to the given charging level.

The supplied information is operator specific.For instance following information can be supplied :

� the charge level,

� charge pulses,

� charge messages.

Figure 25 : The use of the SendChargingInformation

Local Exchange IAM SSP

SCP

Initial DP(1) SendChargingInfo(2)

Connect(3)

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



SendChargingInformationArg ::= SEQUENCE {

sciBillingChargingCharacteristics [0] SciBillingChargingCharacteristics,

legID [1] LegId

}

The sciBillingChargingCharacteristics is network operator specific.It contains signalling related specific charging info, it can in signalling messages be mappedto the corresponding parameters.

The parameter contains signalling related specific charging information. It is passed throughby the SSF to signalling where it can be mapped to the corresponding parameters.

It can also be used to request the sending of the “No charge” indicator to the involvedsignalling. This condition is to be mapped on the appropriate signalling message, e.g. ISUPACM. If the PIC is passed to pass this “No charge” indicator, a negative reply to thisoperation (Task refused) will be transferred to the SCP.

7.3 FurnishChargingInformation

The SCF asks via this operation the SSF to generate, register a call record or to includesome info in the default call record. It provides the parameters to influence the charging inthre SSP.This registered call record is intended for off–line charging of the call.

The FurnishChargingInformation can be used at the beginning of a call to start chargegeneration.But it can also be invoked at the end of a call or connection configuration.If such additional FurnishChargingInformation operations are used, it is best to arm anEDP–R to be able to apply it before the termination of the call record generation.

The supplied information by this operation is the FCIBillingChargingCharacteristics.Its content is network operator specific.An example is given :

FCIBillingChargingCharacteristics ::= CHOICE{completeChargingRecord [0] OCTET STRING,

correlationID [1] CorrelationID,

scenario2Dot3 [2] SEQUENCE {

chargeParty [0] LegID OPTIONAL,

chargelevel [1] OCTET STRING OPTIONAL,

chargeItems [2] Set Of atrribute OPTIONAL

}

}

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Which element out of the CHOICE is taken depends on the scenario (see further)

An FCI operation is always linked to a connection section and a FCI can only be receivedduring (or is related with) the call set–up. When the connection section releases, thecorresponding charge record has to be closed.

This way of working solves the problem where a FCI is received for an announcement andafterwards another FCI is received for the connection to the B–party. When the transfer ofthe announcement is requested a ConnectToResource or similar operation is receivedtogether with the FCI. When the announcement session is finished the SCP will transfer aDisconnectForwardConnection (or similar) operation or the SRF will disconnectautomatically (depending on the value of the disconnectFromIpForbidded parameter)resulting in the closure of the corresponding charge record.

Examples are: FCI received together with a ConnectToResource operation: The FCI isactive until a DisconnectForwardConnection is received or until the SRF releases theconnection.

An FCI cannot be used by the SCP to ask a send him a call record at the end of the call.

7.4 ApplyCharging & ApplyChargingReport

This operation is used for interacting from the SCF with the SSF charging mechanisms. TheApplyChargingReport operation provides the feedback from the SSF to the SCF.

As several connection configurations may be established during a call, a possibility exists forthe ApplyCharging to be invoked at the beginning of each connection configuration, for eachparty.

ApplyCharging

ARGUMENT

ApplyChargingArg

ERRORS{

MissingParameter,

UnexpectedComponentSe-quence,




SystemFailure,

TaskRefused

}

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



ApplyChargingArg ::= SEQUENCE {

aChBillingChargingCharacteristics [0] AChBillingChargingCharacteristics,

sendCalculationToSCPIndication [1] BOOLEAN DEFAULT FALSE,

partyToCharge [2] LegID OPTIONAL

}

The ApplyChargingArg specifies which charging related information is required from theSSF. Also specified is the conditions under which an ApplyChargingReport is sent.Its contents is network operator specific

Examples of charging related information to be provided by the SSF are :

� bulk counter values,

� costs,

� tariff change and time of change,

� time stamps,

� durations and so on.

An additional parameter is the ”partyToCharge” . It is the party in the call to which the ApplyCharging applies.

The sendCalculationToSCPIndication parameter indicates whether ApplyChargingReportoperations are expected from the SSF.

The AC operation received from the SCP can also indicate the actions to be performed onan active call. The SCP can in this way supervise the charging related aspects of the calland indicate to the SSP following information :

� Maximum call cost in currency or maximum call duration in seconds. These parametersare exclusive. The SSP starts the supervision immediatly after the B–party has answered.

� Warning to be given to the served party at a specified time before the release of the call.

� How to release the call,

� Time interval between sending of ACR.

The ApplyChargingReport operation reports the specific charging events as asked by theSCP and sends the requested information.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



ApplyChargingReport

ARGUMENT

ApplyChargingReportArg

ERRORS{

MissingParameter,

UnexpectedComponentSe-quence,




SystemFailure,

TaskRefused

}

The Apply ChargingReportArg contains the information requested for in the ApplyCharging.

The contents is operator specific

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



7.5 An example of the operator specific info available in the charging relatedoperations

FCIBillingChargingCharacteristics [0] IMPLICIT SEQUENCE SIZE (1 OF ??)) OF

SEQUENCE {

chargeRecordIdentifier [0] IMPLICIT INTEGER (1..127) DEFAULT 1,

chargeAction [1] IMPLICIT ENUMERATED {

networkChargeRecordGenerationRequest (1),

serviceChargeRecordGenerationRequest (2),

chargeChange (3),

suspendCharging (4),

resumeCharging (5),

stopCharging (6) } DEFAULT networkChargeRecordGeneration Request,

controllingParty [2] IMPLICIT INTEGER (1..127) DEFAULT 1,

–– This parameter contains the value of the leg identity controlling the charge request.

–– When this leg identity releases the involved charge record shall be closed.

callPartToBeCharged [3] IMPLICIT ENUMERATED {

callingSSP (1),

sSPCalled (2),CallingCalled (3) } DEFAULT sSPCalled,

additionalChargeRecordStorageReference [4] IMPLICIT INTEGER (1..200)

OPTIONAL,

–– It specifies indirectly the file reference in which the charge record is to be stored in

––addition to the normal storage treatment.

doNotGenerateChargePulses [5] IMPLICIT BOOLEAN DEFAULT TRUE,

–– TRUE : Generate pulses if so populated in SSF

–– FALSE : Do not generate pulses, even if pulse generation is populated in SSF

chargeRecordTreatment [6] IMPLICIT OCTET STRING (SIZE(1)),callingPartyServiceNumber [9] CallingPartyNumber OPTIONAL,

–– This parameter is treated depending on the availability of the calling party number in

–– the SSP.

–– This parameter is stored in the charge record without any processing in case the

–– calling party number is still available in the SSP. In case the calling party number is

–– not available anymore in the SSP, this parameter is stored in the charge record

–– and it is used by the SSP in case charge determination is to be performed in

–– the SSP .

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



calledPartyServiceNumber [10] CalledPartyNumber OPTIONAL,

–– This parameter can be used to store the identity of the called party in the charge record

translatedPartyNumber [11] CalledPartyNumber OPTIONAL,

chargedPartyIdentityIndicator [12] INTEGER (1..127) DEFAULT 2,

surcharge [13] IMPLICIT SEQUENCE (SIZE (1 OF ??)) OF

SEQUENCE {

surchargeValue [1] IMPLICIT INTEGER (0..255),

surchargeType [2] IMPLICIT INTEGER (1..127) } OPTIONAL,

–– 1 = local currency, 2 = tariff units

chargeClass [14] IMPLICIT INTEGER (1..1000) OPTIONAL,

–– A numeric value defining the charging to be performed, defined in function of all

–– charging influencing parameters and comprising switchover moments

chargeRateModulator [15] IMPLICIT SEQUENCE OF

SEQUENCE {

chargeRateModulatorValue [1] IMPLICIT INTEGER (0..255),

chargeModulatorType [2] IMPLICIT INTEGER (1..3) } OPTIONAL,

–– Rate Modulator (1) in %,Currency (fee) Modulator (2) in %,Tariff Table index (3)

actualInitialTariffUnits[16] IMPLICIT INTEGER (0..255) OPTIONAL,

–– This parameter contains the tariff units to be added when the charging becomes

–– active.This parameter is valid before the switchover time.

nextInitialTariffUnits [17] IMPLICIT INTEGER (0..255) OPTIONAL,

–– This parameter contains the initial tariff units after the specified switchover time.

actualTariffUnits [18] IMPLICIT INTEGER (0..63) OPTIONAL,

–– This parameter contains the tariff units to be used before the switchover time.

nextTariffUnits[19] IMPLICIT INTEGER (0..63) OPTIONAL,

–– This parameter contains the tariff units to be used after the specified switchover time.

actualTimeInterval [20] IMPLICIT INTEGER (0..32767) OPTIONAL,

–– This parameter contains the time interval in 1/10 sec accuracy,The value is valid

–– before the specified switchover time.

nextTimeInterval [21] IMPLICIT INTEGER (0..32767) OPTIONAL,

switchoverTime [22] IMPLICIT INTEGER (0..1440) OPTIONAL,

startChargingPattern [24] IMPLICIT ENUMERATED {

immediately (1),

answerReceived (2) } DEFAULT answerReceived,

stopChargingPattern [25] IMPLICIT ENUMERATED {

suspend (1),

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



release (2) } DEFAULT release,

callType [26] IMPLICIT ENUMERATED {

circuitSwitched (1),

packetSwitched (2) } DEFAULT circuitSwitched,

chargeRecordType [27] IMPLICIT ENUMERATED {

detailledBilling (1),

bulkBilling (2) } DEFAULT detailedBilling,

chargeMeterIdentity [28] IMPLICIT ENUMERATED {

bulkBillingMeter1 (1),


...

bulkBillingMeter15 (15) } OPTIONAL,

transparentChargeParameter1 [29] IMPLICIT OCTET STRING (SIZE(1..20)) OPTIONAL,

detailedBillingChargeRecordType [45] IMPLICIT INTEGER (1..32) DEFAULT 1 }

applyCharging OPERATION

ARGUMENT

–– The sendCalculationToSCPIndication parameter indicates that

ApplyChargingReport operations

–– are expected from the SSF. This parameter shall always be set to TRUE.

–– The PartyToCharge parameter indicates the party in the call to which the

ApplyCharging

–– operation should be applied. If it is not present, then it is applied to the A–party.

SEQUENCE {

aChBillingChargingCharacteristics [0] IMPLICIT SEQUENCE SIZE (1 OF 100)) OF

SEQUENCE {

chargeRecordIdentifier [0] IMPLICIT INTEGER (1..127) DEFAULT 1

chargeAction [1] IMPLICIT ENUMERATED {

networkChargeRecordGenerationRequest (1),

serviceChargeRecordGenerationRequest (2),

chargeChange (3),

suspendCharging (4),

resume charging (5),

stop charging (6) } DEFAULT networkChargeRecordGenerationRequest

controllingParty [2] IMPLICIT INTEGER (1..127) DEFAULT 1,

callPartToBeCharged [3] IMPLICIT ENUMERATED {

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



callingSSP (1),

sSPCalled (2),

CallingCalled (3) } DEFAULT sSPCalled

additionalChargeRecordStorageReference [4] IMPLICIT INTEGER (1..200)

OPTIONAL,

–– It specifies indirectly the file reference in which the charge record is to be

stored in addition

–– to the normal storage treatment.

doNotGenerateChargePulses [5] IMPLICIT BOOLEAN DEFAULT TRUE,

–– TRUE : Generate pulses if so populated in SSF

–– FALSE : Do not generate pulses, even if pulse generation is populated in SSF

chargeRecordTreatment [6] IMPLICIT OCTET STRING (SIZE(1)),

–– Layout: see description in this document

callingPartyServiceNumber [9] CallingPartyNumber OPTIONAL,

–– This parameter is treated depending on the availability of the calling party

number in the SSP.

calledPartyServiceNumber [10] CalledPartyNumber OPTIONAL,

–– This parameter can be used to store the identity of the called party inthe charge record

translatedPartyNumber [11] CalledPartyNumber OPTIONAL,

chargedPartyIdentityIndicator [12] INTEGER (1..127) DEFAULT 2,

surcharge [13] IMPLICIT SEQUENCE (SIZE (1 OF ??)) OF

SEQUENCE {

surchargeValue [1] IMPLICIT INTEGER (0..255),

surchargeType [2] IMPLICIT INTEGER (1..127) } OPTIONAL

chargeClass [14] IMPLICIT INTEGER (1..1000) OPTIONAL,

chargeRateModulator [15] IMPLICIT SEQUENCE OF

SEQUENCE {

chargeRateModulatorValue [1] IMPLICIT INTEGER (0..255),

chargeModulatorType [2] IMPLICIT INTEGER (1..3) } OPTIONAL,

actualInitialTariffUnits[16] IMPLICIT INTEGER(0..255) OPTIONAL,

nextInitialTariffUnits [17] IMPLICIT INTEGER (0..255) OPTIONAL,

actualTariffUnits [18] IMPLICIT INTEGER (0..63) OPTIONAL,

nextTariffUnits[19] IMPLICIT INTEGER (0..63) OPTIONAL,

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



actualTimeInterval [20] IMPLICIT INTEGER (0..32767) OPTIONAL,

nextTimeInterval [21] IMPLICIT INTEGER (0..32767) OPTIONAL,

switchoverTime [22] IMPLICIT INTEGER (0..1440) OPTIONAL,

chargeLimit [23] IMPLICIT SEQUENCE SIZE (1..??) OF

SEQUENCE {

chargeLimitType [01] INTEGER (1..127),

–– This parameter contains the type as follows

––1 = local currency

––2 = time in seconds

––3 = pulses

chargeLimitValue [02] INTEGER (1..32000),

startChargingPattern [24] IMPLICIT ENUMERATED {

immediately (1),

answerReceived (2) } DEFAULT answerReceived,

stopChargingPattern [25] IMPLICIT ENUMERATED {

suspend (1),

release (2) } DEFAULT release,

callType[26] IMPLICIT ENUMERATED {

circuitSwitched (1),

packetSwitched (2) } DEFAULT circuitSwitched,

chargeRecordType[27] IMPLICIT ENUMERATED {

detailledBilling (1),

bulkBilling (2) } DEFAULT detailedBilling,

chargeMeterIdentity [28] IMPLICIT ENUMERATED {



...

bulkBillingMeter15 (15) } OPTIONAL,

transparentChargeParameter1 [29] IMPLICIT OCTET STRING (SIZE(1..20)) OPTIONAL,

detailedBillingChargeRecordType [45] IMPLICIT INTEGER (1..32) } DEFAULT 1,

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

8. CHARGING SCENARIOS



The following scenario’s will be possible for the charging of IN Calls :

� scenario 1: Charging completely done in a charging point outside the SSP via non–INcharge record.

� scenario 2: Charging completely done in the SSP via IN charge records.

� scenario 3: Charging done in as well the SSP as a charging point outside the SSP:

– via non–IN charge record in charging point outside SSP.

– via IN charge record(s) in the SSP.

The choice between the different scenario’s is IN service dependent.

For each service, the charged parties should be available in the SCP service script, resultingin clear instructions for the charging.

Note : The charging point outside the SSP is situated in a previous exchange, in relation tothe involved SSP, or in the same exchange where the SSF function is located

8.1 Scenario 1 – Charging completely done in a charging point outside theSSP.

The charging point outside the SSP knows, by charge determination that local chargingapplies. The charging point can generate and determine charging autonomously, but canrequest input from IN.

The charging point will request the sending of charging information by the SSP and thenon–IN charge record has to be generated according to the received charging information.The charging information is market dependent and will not be discussed further.

The charging request has to be passed via the existing parameters of the InitialDP, forexample the ForwardCallIndicator can be used.

The SCP upon receipt of the charging request, will request the transfer of aSendChargingInformation operation via the SSP. The SSP has to map the contents of theSCI operation to an information element of the involved signalling system (e.g. ISUP)

Note: As an alternative, the SCP can request the transfer of the SCI without any request from thecharging point (decision is again market dependent).

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 26 : Charging completely done in a charging point outside the SSP

Chargingpoint

non–In charge record

SSP

Charging information request(1)

Charging information reply(4)

SCP

InitialDPwith chargingrequest(2)

SendCharginginformation(3)

� Advice Of Charge Supplementary Service (AOC).

As the charging point will be able to generate the AOC, all parameters of the AOC canbe determined by taking the received charging information reply together with the localcharging information into account.

� Homemeter. The charging point has all the information to address the homemeter (sameas for AOC)

8.2 Scenario 2 – charging completely done in the SSP.

The service definition specifies that for the charging, IN charge records have to begenerated by the SSP.

In this case the non–IN charging point knows, during charge determination that no chargingapplies locally.

The SCP service script has to request the generation of IN charge records .

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 27 : Charging completely done in the SSP

SSP

SCP

Furnish ChargingandApplyCharging

non–IN charging point

taxfree record is pos-sible

ApplyChargingreport

� Advice of Charge Supplementary Service (AOC).

As the non–IN charging point will not be the charging exchange, it will have to requestto the SSP the sending of all parameters related to the AOC. The AOC request ispassed to the SCP which in turn will reply the AOC information.

The AOC request is only related to the charging of the calling line (owner of theaccess). The non–IN charging point shall process/generate the charging parametersrequired for AOC. The non–IN charging point shall have the possibility to generate atax free record in which the number of pulses charged to the subscriber will be put.

� Homemeter

The same principle as for AOC is applicable. The non–IN charging point shall calculatethe required charging information to be transferred to the homemeter. In other words,charging of the call will be performed in the SSP and in parallel in the non–IN chargingpoint in case Homemeter or AOC is required. The non–IN charging point shall have thepossibility to generate a tax free record in which the number of pulses charged to thesubscriber will be put.

8.3 Scenario 3 – Charging done in as well the SSP as a charging point outsidethe SSP

The service definition specifies that both the non–IN charging point as well as the SSP shallgenerate charge records. As an example the non–IN charge record can be used to chargethe access and possible the use of the service and the IN charge record(s) generated in theSSP can be used to charge the service provider.

In this case the non–IN charging point knows during charge determination that chargingapplies locally. The non–IN charging point can request the sending of the charginginformation as is done for scenario 1.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



The SCP has to reply via

� The Send Charging Information operation the charging information for the non–INcharging Point (see scenario 1)

� The Apply Charging or Furnish Charging operation the request to generate a IN chargerecord in the SSP (see scenario 2)

Figure 28 : Charging done in as well the SSP as a charging ppoint outside the SSP

Chargingpoint

non–In charge record

SSP

Charging information request(1)

Charging information reply(4)

SCP

InitialDPwith chargingrequest(2)

SendCharginginformation(3) ApplyCharging

orfurnishCharging

� dvice Of Charge Supplementary Service (AOC)

The same principles apply as specified in scenario 1.

(AOC only for non–IN charge record. In other words, AOC for all charges to be paid bythe owner of the physical access).

� Homemeter

The same principles apply as specified in scenario 1.

8.4 Determination of Charging Information

� In case the SCP or the non–IN charging point cannot determine the charging informationspecific market dependent activities are to be performed. These activities can result inreleasing the call, with a congestion tone, specific announcement or the call handling cancontinue as for charge free calls.

� The Charging Information Request and Advice Of Charge Request are passed vianational defined ISUP mechanisms (indicators, parameters, messages) and are notfurther described in this document.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� The Charging Information Reply and AOC reply are passed via national defined ISUPmechanisms (parameters, messages). They contain a tariff class and optionally a chargemodulator. The charge modulator is only applicable on the time interval (rate) or currency.Selection between time interval and currency depends on the used charging strategy andis as such market dependent.

The coding of the ISUP details are market dependent and are not further described in thisdocument.

In case Home Meter or CoinBox is treated, if a ”currency modulator ” is received, the call isreleased.

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

9. OVERVIEW OF THE OPERATIONS



InitialDP SSP –> SCP Class 2 0

AssistRequestInstructions

SSP or SRF –> SCP Class 2 16

EstablishTemporary-Connection

SCP –> SSP Class 2 17

DisconnectForward-Connection


ConnectToResource SCP –> SSP Class 2 19

Connect SCP –> SSP Class 2 20

ReleaseCall SCP –> SSP Class 4 22

RequestReportBCSMEvent


EventReportBCSM SSP –> SCP Class 4 24

CollectInformation SCP –> SSP Class 2 27

Continue SCP –> SSP Class 4 31

InitiateCallAttempt SCP –> SSP Class 2 32

ResetTimer SCP –> SSP Class 2 33

FurnishChargingInformation


ApplyCharging SCP –> SSP Class 2 35

ApplyChargingReport

SSP –> SCP Class 2 36

CallGap SCP –> SSP Class 4 41

ActivateServiceFiltering


ServiceFilteringResponse


CallInformationReport


CallInformationRequest


SendChargingInformation

Class 2 46

PlayAnnouncement SCP –> SSP Class 2 47

PromptAndCollectUserInformation




Cancel SCP –> SSP Class 2 53

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Activity Test SCP –> SSP Class 3 55

ALCFree SCP –> SSP Class 2

ALCJoin SCP –> SSP Class 2

ALCSplit SCP –> SSP Class 2

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



Figure 29 : Alcatel Operations

ETSI CS1 Protocol Alcatel INAP Protocol

Operations used in a normal call flowINITIAL DP PROVIDE INSTRUCTION

Charging

CONNECT CREATE

FURNISH CHARGING UPDATE (charging)APPLY CHARGING UPDATE (charging)APPLY CHARGING REPORT UPDATE (charging report)SEND CHARGING INFORMATION

INITIATE CALL ATTEMPT CREATE (without related leg)

REQUEST NOTIFICATION BCSM EVENT MONITOREVENT REPORT BCSM EVENT

COLLECT INFORMATION–

–GENERATE SIGNAL

Connection of Announcements / Receive End User Info.

CONNECT TO RESOURCE SEND / RECEIVEPLAY ANNOUNCEMENTSPECIALISED RESOURCE REPORT SEND / RECEIVE RESULTPROMPT AND COLLECT USER INFORMATIONPROMPT AND COLLECT USER INFORMATION RESULT SEND / RECEIVE RESULTESTABLISH TEMPORARY CONNECTION –ASSIST REQUEST INSTRUCTION –

Traffic Management

ACTIVATE SERVICE FILTERING –SERVICE FILTERING RESPONSE –

CALL GAP –– UPDATE (WINDOW)– UPDATE (BLOCKING)

Others

CANCEL

RELEASE CALL

RESET TIMERJOINALC JOINSPLITALC SPLITFREEALC FREE

SEND / RECEIVE

SEND / RECEIVE

Mass Calling

ACTIVITY TESTACTIVITY TEST

CALL INFORMATION REQUESTCALL INFORMATION REPORT

––

–

TRANSFER CONTROL

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED



� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

10. SCENARIOS


10.SCENARIOS

Figure 30 : A normal call scenario

SCP SSP

Connect

FurnishChargingInformation

InitialDP

Release

ApplyCharging

RequestReportBCSMEvent

EventReportBCSM

ApplyChargingReport

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

10. SCENARIOS



SCP SSP

Connect to Resource

P&CDisconnectFromIPForbidden = TRUE

InitialDP

Connect

P&C result

P&CDisconnectFromIPForbidden =FALSE

P&C result

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

10. SCENARIOS


Figure 32 : Wake up call SSP has an integrated SRF

SCP SSP

RequestReportBCSM event (T_Answer from B)

Initiate Call Attempt

PlayAnnouncement

ConnectToResource

EventReportBCSM

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

10. SCENARIOS


Figure 33 : Televoting or mass calling

The service filtering is to be reported every Nth call and is based on some dialled number

SCP SSP

Activateservicefiltering (starttime,stoptime,every nth call)

PlayAnnouncement

InitialDP

ServiceFilteringResponse (counters = 0)

DIALOGUE IS ENDED

ServiceFilteringResponse (counters, N–1 calls have been filtered)

ConnectToResource

ReleaseCall

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

10. SCENARIOS



SCP SSP IP


Setup response

P&CP&C

P&C result

Disconnect

DisconnectFromIPForbidden = TRUE

InitialDP

Connect

P&C result

P&CP&C

P&C result

DisconnectFromIPForbidden =FALSE

P&C result

� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

10. SCENARIOS


� 2

000

ALC

AT

EL

BE

LL N

.V. A

LL R

IGH

TS

RE

SE

RV

ED

11. THE ALCATEL ADDED OPERATIONS


11.THE ALCATEL ADDED OPERATIONS

11.1 AlcFree

This operation is used by the SCP to release one or more legs related to a call.The parametes present i this operation are :

� the leg id

� the release cause

� and the parameter Immediate execution.

11.2 AlcJoin

This operation is used by the SCP to join a leg with another leg in the same TCAP dialogue.The parametes present in this operation are :

� the leg id A

� the leg id B

� and the parameter Immediate execution.

11.3 AlcSplit

This operation is used by the SCP to request the SSP to separate a leg previouslyconnected to a call or all legs connected to a call, the CallId is discardedd when the last 2legs of a call are split.

cs1 core inap new

Documents

tax free record

normal storage

charging applies

sspnonin charge

nonin charge

charge record

network operator

nonin charging