111757820 CS 1 INAP Call Flowv0 1 Scribd

(1)

CS-1 INAP Call Flow

(2)

Table of Content ... 2

0.0 References ... 6

0.1 Glossary ... 6

1.0 Introduction ... 8

1.1Assumptions...8

2.0 Basic Call State Model (BCSM) ... 9

1.2Originating BCSM for CS 1...10

1.3Terminating BCSM for CS-1...15

3.0 Trigger and Detection Point ... 18

1.4Detection Point...18

1.5Arming Mechanism...19

1.6Criteria...19

1.7Trigger...21

1.8DP Processing...21

4.0 INCM Service Plane ... 23

5.0 Access Network for IN Services ... 26

(3)

6.0 Freephone or TollFree Service ... 27 1.9Service Description...27 1.10Service Function...28 1.11Charging...28 1.12Scenarios...29 OSCP...38

8.0 Premium Rate Service ... 40

1.13Service Description...40 ... 40 1.14Service Function...40 1.15Scenarios...42 OSCP...51

9.0 Virtual Card Calling (VCC) ... 53

1.16Service Description...53 1.17Service Function...54 1.18Scenarios...55 OSSP...57 OSCP...57 TSSP...57 B Party...57 B Party...59 ...60

10.0 Account Card Calling (ACC) ... 64

(4)

1.21Scenarios ...66 OSSP...67 OSCP...67 TSCP...67 B Party...67 OSSP...74 OSCP...74 TSCP...74 B Party...74 OSSP...79 OSCP...79 TSCP...79 ...80

11.0 Virtual Private Network ... 80

1.22Service Description...80 1.23Service Function...81 1.24Scenarios...82 12.0 Televoting ... 88 1.25Service Description...88 13.0 Timer Values ... 90 14.0 INAP Operations ... 93 Page 4 of 159

(5)

1.26List of INAP CS-1 Operations...93 1.27Message Description...95

(6)

1. ITU-T Recommendation Q.1218 Intelligent Network : Interface Recommendation for Intelligent Network

2. Intelligent Network Capability Set 1, Core Intelligent Network Application Protocol (INAP), Part 1 : Protocol Specification (ETS 300 374-1)

0.1 Glossary

BCSM Basic Call State Model

CAMEL Customised Application Mobile Enhanced Logic CDR Call Detail Record

CS-1 Capability Set 1 CS-2 Capability Set 2

DP Detection Point

ETSI European Telecommunications Standards Institute FSM Finite State Machine

GUI Graphical User Interface IN Intelligent Network

INAP Intelligent Network Application Protocol IP Intelligent Peripheral

ISDN Integrated Services Digital Network ISUP ISDN User Part

ITU-T International Telecommunications Union–Telecommunications Standardisation Sector IVR Interactive Voice Response

MTP Message Transfer Part

PC Point Code

POTS Plain Old Telephony Service PRI Primary Rate Interface

PSTN Public Switched Telephone Network SCCP Signaling Connection Control Part SCP Service Control Point

SLP Service Logic Program

SRF Specialised Resource Function

SS7 Signaling System 7 (also known as CS-Common Signaling) Page 6 of 159

(7)

SSN SubSystem Number SSP Service Switching Point STP Signaling Transfer Point

TCAP Transaction Capabilities Application Part

(8)

This document attempts to capture technical information related to CS-1 IN services implementation for easy reference of the user. It serves to provide an overall understanding about the SSP capabilities needed, INAP protocol, and possible ways of implementing the various CS-1 IN services.

1.1 Assumptions

1. The call flows shown in the document assume “Fixed service” being offered to the subscribers, and not necessarily the

“Wireless Local Loop” service.

2. SRF relay mode is used with IP residing in same SSP.

(9)

2.0 Basic Call State Model (BCSM)

The BCSM is used to describe the actions in a SSP (FSC/MSC) during call origination, forwarding or terminating.

It identifies the points in basic call processing when the service logic in SCF is allowed to interact with basic call control capabilities in SSP. Components identified to describe a BSCM:

– Transition

– Detection Point (DP) – Point in call (PIC)

(10)

1.2 Originating BCSM for CS 1

(11)

9 7 5 3 1 2 6 10 8 T1136230-91/d005 4 O_Abandon 6. O_Exception Route_Select_Failure O_Called_Party_Busy O_No_Answer O_Disconnect O_Mid_Call O rig. Attempt_Authorized Collected_Info. Analysed_Info. O_Answer 1. O_Null & Authorize Origination_Attempt

2. Collect_Info.

3. Analyse_Info.

4. Routing & Alerting

5. O_Active

Transition

Detection Point (DP)

Point In Call (PIC)

FIGURE 4-3/Q.1214 Originating BCSM for CS-1

(12)

From To

Origination_Attempt_Authorized DP Collect_Information PIC Analyse_Information PIC Routing_&_Alerting PIC Collected_Information DP Collect_Information PIC Analyse_Information PIC Routing_&_Alerting PIC Analysed_Information DP Collect_Information PIC Analyse_Information PIC Routing_&_Alerting PIC Route_Select_Failure DP O_Exception Collect_Information PIC Analyse_Information PIC Routing_&_Alerting PIC O_Called_Party_Busy DP O_Exception Collect_Information PIC Analyse_Information PIC Routing_&_Alerting PIC O_No_Answer DP O_Exception Collect_Information PIC Analyse_Information PIC Page 12 of 159

(13)

Routing_&_Alerting PIC

O_Answer DP O_Active PIC

O_Midcall DP _Active PIC

O_Disconnect DP O_Null_&_Authorize_Origination_Attempt PIC Collect_Information PIC

Analyse Information PIC Routing_&_Alerting PIC

O_Abandoned DP O_Null_&_Authorize_Origination_Attempt PIC O_Null_&_Authorize_Origination_Attempt PIC Origination_Attempt_Authorized DP

Collect_Information PIC O_Exception O_Abandon DP

Collected_Information DP Analyse_Information PIC O_Exception

O_Abandon DP

Analysed_Information DP Routing & Alerting PIC Route_Select_Failure DP

O_called_Party_Busy DP O_No_Answer DP O_Answer DP O_Abandon DP Analyze_Information PIC O_Exception Page 13 of 159

(14)

O_Disconnect DP O_Exception

O_Exception O_Null_&_Authorize_Origination_Attempt PIC

(15)

1.3 Terminating BCSM for CS-1

T 1 1 3 6 2 4 0 - 9 1 / d 0 0 6 1 3 1 4 1 2 1 8 1 5 1 6 1 7 1 1 . T _ E x c e p t i o n 8 . S e l e c t _ F a c il i t y & P r e s e n t _ C a l l 9 . T _ A l e r t in g 1 0 . T _ A c t i v e 7 . T _ N u l l & A u t h o r i z e T e r m in a t i o n _ A t t e m p t T _ A b a n d o n T _ D i s c o n n e c t T _ M i d _ C a l l T _ C a ll e d _ P a r t y _ B u s y T _ N o _ A n s w e r T e r m . _ A t t e m p t _ A u t h o r i z e d T _ A n s w e r T r a n s i t i o n D e t e c t i o n P o i n t ( D P ) P o i n t I n C a l l ( P I C ) F I G U R E 4 - 4 / Q . 1 2 1 4 T e r m i n a t i n g B C S M f o r C S - 1 Page 15 of 159

(16)

Termination_Attempt_Authorized DP Select_Facility & Present_Call PIC T_Busy DP Select_Facility & Present_Call PIC

T_Exception

T_No_Answer DP Select_Facility & Present_Call PIC T_Exception

T_Answer DP T_Active PIC

T_Midcall DP T_Active PIC

T_Disconnect DP T_Null & Authorize_Termination_Attempt PIC T_Abandoned DP T_Null & Authorize_Termination_Attempt PIC T_Null & Authorize_Termination_Attempt PIC Termination_Attempt_Authorized DP

Select_Facility & Present_Call PIC T_Busy DP T_Abandon DP T_Answer DP T_Alerting PIC

T_Alerting PIC T_No_Answer DP

T_Answer DP T_Abandon DP

T_Active PIC T_Midcall DP

T_Disconnect DP T_Exception

(17)

T_Exception T_Null & Authorize_Termination_Attempt PIC

(18)

1.4 Detection Point

Certain basic call events maybe visible to the Service Control Function in IN. The Detection Points are the points in call at which these events are detected. Table below lists the detection points available (DP1-DP10 for originating while DP12 – DP18 for terminating).

DP no. Detection Point Name

DP1 Origination Attempt_Authorized DP2 Collected_Information DP3 Analysed_Information DP4 Route_Select_Failure DP5 O_Called_Party_Busy DP6 O_No_Answer DP7 O_Answer DP8 O_Mid_Call DP9 O_Disconnect DP10 O_Abandon DP11 Reserved DP12 TerminatingAttemptAuthorized DP13 T_Called_Party_Busy DP14 T_No_Answer DP15 T_Answer DP16 T_Mid_Call DP17 T_Disconnect DP18 T_Abandon Table

A DP can be armed in order to notify the SCF that the DP was encountered, and potentially to allow the SCF to influence

subsequent handling of the call. If the DP is not armed, the processing entity continues the processing without SCF involvement. Table below shows the types of DP identified.

(19)

DP type Arming

mechanism Criteria IN service relationship Suspension Service feature examples

TDP-R Static Specific to

DP Initiates control relationship Yes All

TDP-N Static Specific to

DP

Initiates and terminates monitor relationship

No Televoting, call logging

EDP-R Dynamic None Within context of existing control

relationship Yes Call distribution, call rerouting distribution

EDP-N Dynamic None Within context of existing control or

monitor relationship No Charging for any service feature, call logging, call queueing

Table BCSM DP types

1.5 Arming Mechanism

The mechanism by which the DP is armed. A DP may be statically armed or dynamically armed. There are two types of trigger mechanism:

• dynamically armed

Triggers are armed by the service logic in SCP on a per call basis. These are called Event Detection Point-Request (EDP-R) & Event Detection Point-Notification(EDP-N).

• statically armed

Triggers that are armed in the provisioning process in SSP. These are called Trigger Detection Point-Request (TDP-R) & Trigger Detection Point-Notification (TDP-N).

1.6 Criteria

Criterias are the conditions that must be met in order for the SSF to request instructions from the SCF. For TDPs, Detection Point Criteria must be met before the SSP can notify SCP that the DP was encountered.

Table below shows the various possible DP criteria that can be assigned at the SSP: Legend

X Applicable

- Not applicable

(20)

DP

DP Criteria 1 2 3 4 5 6 7 8 9 1

0 11 12 13 14 15 16 17 18

Class of Service _X _O _O _O _O _O _O _O _O _O _X _O _O _O _O _O _O

Specific Digit String (Note 1) – X X O O O O O O O – – – – – – –

Feature Code (Note 1) _– _X _X _O _O _O _O _O _O _O _– _– _– _– _– _– _–

Prefixes (Note 1) _– _X _X _O _O _O _O _O _O _O _– _– _– _– _– _– _–

Access Codes (Note 1) _– _X _X _O _O _O _O _O _O _O _– _– _– – – – –

Called Party Number (Note 1) – X X O O O O O O O – – – – – – –

Facility Information (Note 2) – – X – – – X X – – – – – X X – –

Feature Activation (Note 3) – – X X X X X X X X – – X X X X X

Cause – – – X X – – – X X – X – – – X X

Specific abbreviated dialling string (Note 1) – – X O O O O O O O – – – – – – –

Specific Calling Party Number (Note 4) X O O O O O O O O O X O O O O O O

Nature of Address – – X O O O O O O O – – – – – – –

Bearer Capability (Note 5) X O O O O O O O O O O O O O O O O

Trigger Assigned X X X X X X X X X X X X X X X X X

Specific B-channel Identifier O O O O O O O O O O – – O O O O O

NOTES

1. Same type of trigger requiring analysis of a specific number of received digits. The analysis can be based on the complete number of received digits or can be based on a predefined number of digits starting from the most significant digit of the received information. The inclusion for these criteria for DP 2 is due to the change in the originating BCSM.

2. A match on the Facility Information Element contained in a signalling message as defined in DSS1 and ISUP.

3. In a local exchange only. The BCSM has to analyse (if facility is allowed, stored as Class of Service attribute) the received information and has to initiate an IN trigger if required. A feature activation/indication can be available at DP 1-10 in the originating BCSM for a party served by an ISDN interface and can be available at DP 8 in the originating BCSM for a party served by a non-ISDN line. A feature activation/indication can be available at DP 14-18 in the terminating BCSM for a party served by an ISDN interface and can be available at DP 16 in the terminating BCSM for a party served by a non-ISDN line.

(21)

4. The analysis should not be based on the complete calling party number, it shall be based on a predefined number of digits, starting from the most significant digit of the calling party number.

5. Interpretation of Bearer Capability as optional for DP 2-18 needs further clarification (e.g. DP 1 mandatory means DP 12 mandatory). Further, B-channel selection does not appear as a DP-criteria in the table because specific selection of B-B-channel by the user is for further study: the network can override user selection of B-channel to be used.

If a criteria is marked with an “X” for a Detection Point, then this means that a conditional TDP which is armed at the Detection Point may require the criteria as listed in the table to be satisfied before informing the SCF that the TDP was encountered, e.g. a conditional TDP at DP 1 may require the class of service criteria to be satisfied before the SCF is informed that the TDP was encountered.

If a criteria is marked with an “O” for a Detection Point, then this means that it is implementation dependent if the criteria specific information is still present at that DP because not all suppliers may retain this information for the duration of the call/attempt. If the information is still present, the treatment is the same as a criteria marked with a “X”.

1.7 Trigger

The trigger item is defined as a single set of DP criteria and the associated information that an SSF/CCF uses to determine if the criteria is met and how to process the trigger. The trigger item consists of trigger type, DP criteria, and the SCF routing

information. The trigger items are assigned to users by management process. An SSF should use the SCF routing information to format and route the messages to the appropriate SCF application. The SCF may use existing MTP/SCCP capabilities to route to the SCF.

1.8 DP Processing

With reference to ITU-T Q1214 Section 4.2.2.7, DP processing should be performed according to the following rules:

Rule 1: At any DP, a specific trigger condition can only trigger one service logic program instance (SLPI) at a time.

Rule 2: At any DP, processing of notifications – EDP-N and TDP-N – has higher priority than processing of requests – EDP-R and

TDP-R. If several notifications exist, EDP-R and TDP-R are processed when all notifications have been processed.

Rule 3: If a DP is both armed as EDP and TDP, then the EDP processing has higher priority than the TDP processing since the EDP

has been armed in an already existing SSF-SCF relationship.

(22)

(23)

4.0 INCM Service Plane

The Services & Service Features are visible in INCM Service Plane. Type A Services, Single Ended & Single Point of Control:

• Only one party at a time, to which the Service applies. No service intraction problem.

• Only one SCP at a time, no SCP interaction. Type B Services :

• Multiple subscribers, having own services maybe interacting with each other.

• Multiple SCPs, maybe interacting as well.

• Multiple bearer involved.

CS-1 supports only Type A services like:

1. Number Translation, providing flexible routing and numbering:

• Abbreviated Dialing

• Call forwarding

• Hunting lists

• Freephone

• Premium Rate

• Universal Access Number

• etc

1. Alternate Billing, providing flexible charging

• Credit Card Calling

• Account Card calling

• Split charging

• Premium Rate

• Etc

2. Screening, providing flexible restriction

• Originating Screening

• Terminating Screening

• Security Screening, to grant network access

(24)

• Televoting

• VPN

• Call Completion to Busy Subscriber (Automatic Call Back)

• Etc

CS-1 defines a set of service features:

1. Numbering : Abbreviated dialing, Private Numbering, One Number

2. Routing : Call forwarding, Time dependant, Origin dependant or A location dependant, Follow me diversion 3. Charging

4. Access/Validation

5. Restriction : Call Gapping, Closed user group, Screening(originating,terminating) 6. Customisation : Profile management, Custom announcement/ringtone

7. User Interaction

8. Others : Call queuing, Call Hold, Call Completion to Busy Subscriber (Automatic Call Back) CS-2 supports only Type A services like:

1. Internetwork Services

• Internetwork Freephone, the served user may have several phones to be reached with a single number, regardless of the serving network

• Internetwork Televoting, the calling party can be in another network

• Global Virtual Network Services, VPN over multiple network

• Internetwork Rate indicator Fwd/Bwd, across multiple network, ability to show the cost of the call in forward or backward direction

• Inetrnetwork card validation

2. Mobility Services, Non Call Related services –

(25)

• user authentication,

• user registration,

• IMSI Attach/Detach,

• SMS, voice messages,

• handover, if network quality falls under a threshold 3. Multiparty Services

4. Enhanced User Interaction

(26)

5.0 Access Network for IN Services

The diagram below shows the access networks for the various IN services. The fixed IN services can be invoked by the subscribers and other users via any of these networks.

Page 26 of 159 VMS ILT/SSP SCP (INAP) SRF INAP INAP ISUP DIU E1(V5.2) Other Mobile Service Provider Network BSNL/ MTNL Fixed Line Fixed Network

(27)

6.0 Freephone or TollFree Service

1.9 Service Description

Freephone service allows a service customer to offer a Local Toll-Free number to their service users. The service users who are the general public (subscribers or subscriber of other network operator) can make toll free calls using the freephone service number, the charges for which are picked-up by the called party, who is the service customer.

Freephone uses 7 digits number with 1600 dialing prefix. The service is offered by the operator to its service customers who are corporate organizations. Each corporate customer has a unique freephone service number for the public to access. This service customer/ subscriber can choose to be reached with a single number, based on the service call flow he defined.

The service provider according to the customer requirements performs Freephone service parameterization/customization. Basic features of the call flow includes:

 Time of Day routing.

 A-number routing. (define Grade of Service based on the calling subscriber identity and membership to certain organization)  User selection routing.

 Hunt option (top of the list, most idle, next after previous answer)

 Playing of announcements (to keep the caller informed and advised of the option within a call flow.)

Since IVR prompts are service customers specific, IVR functionality should be supported by the Customer’s PABX or Call Centre functionality. The operator should provide only one level of announcement functionality and does not support deep tree IVR functionality.

Calls can be accessed from all parts of the country (payphone, fixed line phone and mobile phone) with the system having the intelligence to route the call to its nearest destination based on the calling party number. Mobile service user will probably be responsible for the airtime charges whilst the service customer will be responsible for fixed line charges. International access is possible and it depends on operator’s implementation.

Freephone Service applies to speech calls only.

Page 27 of 159

EndMessage {ReleaseCall (cause = NormalUnspecified)}

(28)

When the toll free service is invoked, the FSC/SSP analyzes the called party number and determines that it is a Freephone call and routes it to the Freephone service logic in the SCP for further call processing. In SCP, the called party, calling party information together with service key is analysed and if the criterias are met, the call is completed and all the charges are applied to the called party. Freephone service employs specific dialed digit pattern (1-600-XXX-XXXX being a common plan).

Statically Armed Freephone Trigger

Triggers for Freephone service are not armed on a per subscriber basis, but are switch (or office) based. Following criterias maybe used to provision in the SSP :

– Specific digit string (DP2 or DP3) – Prefix (DP2 or DP3)

Either way, the number defined in these criterias are usually the first few digits of the actual freephone number (eg. 1600) but not the complete digit string of the freephone number.

1.11 Charging

Offline-charging method is used whereby the CDRs generated at the SSP will be processed to bill both the service users and service customers in the manner below:

1. Service users – free of charge. This can be done based on the called party number (1600 XXXX XXX) in the CDR.

2. Service customer – monthly charge and service usage charge. Service usage charge can be done based on the called party number (1600 XXXX XXX), cause value and the duration of the call.

Page 28 of 159

(29)

1.12 Scenarios

6.1.1 Scenario 1: Unsuccessful TollFree Call (Barring based on Service Provider’s predefined incoming

Blacklist number at the service level)

Description:

Usually, the freephone number is accessible from all types of phones from any operator. However, sometimes there might be a need to block access to freephone service from a certain type of phones, eg. payphone or operator assisted calls. These kind of calls can be differentiated because they have specific value in calling party category field of the ISUP IAM message.

The service logic should have the functionality to allow the network operator to defined a certain list of calling party number or calling party category that is barred from accessing the operator’s freephone service. When the caller makes the call, he hears an invalid tone played by the switch indicating that it is not a valid call. This is achieved by the SCP by sending a INAP ReleaseCall message to the SSP with certain cause value. The default value of the cause code is Normal Unspecified (31) which corresponds to a 3 beep tone.

There is no charge incurred for the call, both for the service user and the service customer.

Call Flow:

The following diagram shows the IN call flow for this scenario.

Page 29 of 159

EndMessage {ReleaseCall (cause = NormalUnspecified)} ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)}

(30)

Page 30 of 159

O-SSP

T-SCP

B Party

A Party

BeginMessage {InitialDP (serviceKey, callingPartyNumber, calledPartyNumber, callingPartyCategory)}

initiate a Freephone call (eg. dial 1600 123456)

DP: Collect_Information or AnalysedInformation

TT: Specific Digit String or Prefix = 1600

OSCP

Based on serviceKey, freepone service logic is invoked.

Verify callingPartyNumber or callingPartyCategory is in Service provider’s incoming blacklist

ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)} ContinueMessage { SpecialisedResourceReport (}

(31)

6.1.2 Scenario 2: Unsuccessful TollFree Call (Barring based on Service Customer’s predefined incoming

blacklist number)

Description:

Each service customer has its own group of desired/privilege customers and undesired customers. The service customer may wish to have different call routing treatment for different kinds of caller. For the undesired callers, they may want to play an

announcement to block the actual routing of the call to its destination.

Therefore, the service logic should have the functionality to allow each of the service customer to define its own list of incoming blacklist numbers. When the caller makes the call, the service logic recognizes the calling party’s number and plays an

announcement to the caller, eg. “Sorry, you are not allowed to call this number”

There is no charge incurred for the caller (or service user), but the service customer needs to pay for the duration of the announcement call as the call is considered successful call with normal call completion (based on cause code).

Call Flow:

Page 31 of 159 ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)} ContinueMessage { SpecialisedResourceReport (} ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)}

(32)

Page 32 of 159

O-SSP

T-SCP

B Party

A Party

O-SCP

ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)}

Verify that the callingPartyNumber or

callingPartyCategory is not in Service provider’s incoming blacklist

The service logic search for the corresponding service customer record in DataBase based on calledPartyNumber

Verify that the callingPartyNumber is in Service subscriber’s incoming blacklist

Establish bearer connection to IP Start announcement A disconnects the call

ContinueMessage { SpecialisedResourceReport (} ENDMessage { DisconnectForwardConnection (),ReleaseCall} DP: oDisconnect TT: oDisconnect ContinueMessage {ReportBCSMEvent(oDisconnec t)}

At the end of announcement, the SCP instructs the SSP to end the call and disconnect the connection with the SRF.

If the caller hangs up before the end of announcement, the SCP instruct s SSP to disconnect the connection with the SRF. ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)} ContinueMessage { SpecialisedResourceReport (}

(33)

6.1.3 Scenario 3: Unsuccessful TollFree Call (routing to announcement based on Service Customer’s

predefined time dependant routing at the service customer’s level)

Description:

Dependant on the individual service customer who owns the particular freephone number, the routing of the calls, when to play announcement or route to which destination number varies. Usually, a service customer will need to play different Welcome announcement depending on the time of the call. When it is non-office hour, the service customer will select a pre-recorded “Out of office hour” announcement to request the caller to call on the next day.

Therefore, the service logic should have the functionality to allow each of the service customer to define its own non-office hour and announcement. When the caller makes the call, the service logic recognizes that it is during the non-office hour of that particular freephone service customer and plays an announcement to the caller, eg. “Thank you for calling. Our office is closed. Please call again on the next working day.”

There is no charge incurred for the caller (or service user), but the service customer needs to pay for the duration of the call announcement as the call is considered successful call with normal call completion (based on cause code).

Call Flow:

Page 33 of 159 DP: O_CalledPartyBusy TT: O_CalledPartyBusy; DP: O_NoAnswer TT: O_NoAnswer ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)} ContinueMessage { SpecialisedResourceReport (}

(34)

Page 34 of 159 DP: O_CalledPartyBusy TT: O_CalledPartyBusy; DP: O_NoAnswer TT: O_NoAnswer

O-SSP

T-SCP

B Party

A Party

O-SCP

Based on serviceKey, freepone service logic is invoked. Verify that the callingPartyNumber or

The service logic search for the corresponding service customer record in DataBase based on

calledPartyNumber

Verify that the callingPartyNumber is not in Service subscriber’s incoming blacklist

Verify that the time of the call is not during office hour as defined by the service subscriber

Play “Non-office hour” announcement

If the caller hangs up before the end of announcement, the SCP instruct s SSP to disconnect the connection with the SRF.

(35)

6.1.4 Scenario 4: Successful TollFree Call from Privilege Callers

Description:

Each service customer has its own group of desired/privilege customers and undesired customers. The service customer may wish to have different call routing treatment for different kinds of caller. For the privilege callers, service customer may want to get the Customer Service Representative to attend to their needs immediately. Also, these CSR could be the selected group who has special language fluency or has more skills.

Therefore, the service logic should have the functionality to allow each of the service customer to define its own list of origin dependent routing and time dependant routing. When the caller makes the call, the service logic recognizes they are the privilege callers and immediately route the call to the serving CSR, without even playing the Welcome announcement. Calls are distributed to a number of different destination numbers according to two distribution methods. In the first method (percentage distribution) the service subscriber specifies a percentage of total calls for each destination and the calls are distributed evenly according to this plan on a call-by-call basis. In the second method, (distribution every n-th call) the service subscriber can specify distribution of calls every n-th call to different destination number. Also, when one number is busy/no answer, the service logic will route call to the next available destination number defined in Line hunting. Possible Line Hunting mechanisms are top of the list, most idle, next after previous answer.

There is no charge incurred for the caller (or service user), but the service customer needs to pay for the duration of the call as the call is considered successful call with normal call completion (based on cause code).

Call Flow:

Page 35 of 159

DP: O_CalledPartyBusy TT:

O_CalledPartyBusy; DP: O_NoAnswer

(36)

Page 36 of 159

BeginMessage {InitialDP (serviceKey, callingPartyNumber,

calledPartyNumber)} initiate a Freephone call

(eg. dial 1600 123456)

TT: Specific Digit String = 1600

Dynamically set EDP-R O_Called_Party_Busy O_No_Answer

Dynamically set EDP-N O_Answer DP: O_CalledPartyBusy TT: O_CalledPartyBusy; DP: O_NoAnswer TT: O_NoAnswer ContinueMessage {EventReportBCSM(oCalledPartyBusy/oNo

Asnwer)} Start Hunting/Call Forward to the

next destination number defined

call setup completed and voice path established

The service logic search for the corresponding service subscriber’s record in DataBase based on

calledPartyNumber

Verify that the time of the call is during office hour as defined by the service subscriber

Translates the service number to actual destination number based on origin dependent and time dependent routing

The intended number is selected based on call distribution mechanism based on key quota/ percentage/nth call

Monitor call for busy / no answer/overflow/answer ContinueMessage { RequestReportBCSMEvent (bcsmEvent), Connect (destinationRoutingAddress)} ContinueMessage { Connect (destinationRoutingAddress)} DP: O_Answer TT: O_Answer ENDMessage {EventReportBCSM(oAnswer)}

(37)

6.1.5 Scenario 5 : Successful TollFree Call from Normal Callers

Description:

For a normal freephone caller who is not the privilege callers of the service subscriber, a Welcome Announcement is played to them before the routing of calls. Possibly, they are prompt with a choice menu for them to select which department or service they are requesting from the service subscriber. Afterwhich, the service logic will route the call according to the digit input by the caller.

Therefore, the service logic should have the functionality to allow each of the service customer :

• To define the Welcome message to be played

• to define its own list of origin dependent routing and time dependant routing. Calls are distributed to a number of different destination numbers according to two distribution methods. In the first method (percentage distribution) the service subscriber specifies a percentage of total calls for each destination and the calls are distributed evenly according to this plan on a call-by-call basis. In the second method, (distribution every n-th call) the service subscriber can specify

distribution of calls every n-th call to different destination number.

• To define line hunting/call forward. When one number is busy/no answer, the service logic will route call to the next

available destination number defined in Line hunting. Possible Line Hunting mechanisms are top of the list, most idle, next after previous answer.

Call Flow:

(38)

Page 38 of 159

callingPartyCategorycalledPartyNumber)} initiate a Freephone call

(eg. dial 1600 123456)

ContinueMessage

{ PromptAndCollectUserInformation Result/Error ()}

Dynamically set EDP-N O_Answer

call setup unsuccessful ContinueMessage {

ConnectToResource (resourceAddress), PromptAndCollectUserInformation Request (digits),

RequestReportBCSMEvent}

Verify that the callingPartyNumber or callingPartyCategory is not in Service provider’s incoming blacklist

The service logic search for the corresponding service subscriber’s record in DataBase based on calledPartyNumber

Play Welcome Announcement Establish bearer

connection to IP Start announcement

When digit input is received or PAC application timer (T pc) expires, service logic starts the following:

Translates the service number to actual destination number based on origin dependent and time dependent routing The intended number is selected based on call distribution mechanism based on key quota/ percentage/nth call Monitor call for busy /no answer/overflow/asnwer ContinueMessage

{ DisconnectForwardConnection (), RequestReportBCSMEvent (bcsmEvents), Enter digit

Repeat Prompt And Collect ‘n’ times if necessary

(39)

Page 39 of 159

O-SSP

T-SCP

B Party

A Party

OSCP

ContinueMessage {

Connect (destinationRoutingAddress)}

call setup completed and voice path established DP: O_Answer TT : O_Answer ContinueMessage {ReportEventBCSM(oAswer)} DP: O_CalledPartyBusy TT : O_CalledPartyBusy; DP: O_No_Answer TT : O_No_Answer ContinueMessage {ReportEventBCSM(oCalledPartyBusy or

(40)

8.0 Premium Rate Service

1.13 Service Description

Premium Rate service allows a service customer/provider to offer a Local Premium Rate number with different kinds of service at an extra charge to their service users. The operator calculates the service provider's share of the call charges.

Premium Rate uses 7 digits number with 1900 dialing prefix. The service is offered by the operator to its service customers who are corporate organizations. Each corporate customer has a unique Premium Rate service number for the public to access. This service customer can choose to be reached with a single number, based on the service call flow he defined.

Basic features of the call flow includes:

 Time of Day routing.

 A-number routing. (define Grade of Service based on the calling subscriber identity and membership to certain organization)  User selection routing.

 Hunt option (top of the list, most idle, next after previous answer)

 Playing of announcements (to keep the caller informed and advised of the option within a call flow.)

Since IVR prompts are service customers specific depending on the service offered by the service provider (Audiotext), IVR functionality should be supported by the Customer’s PABX or Call Centre functionality. The operator should provide only one level of announcement functionality and does not support deep tree IVR functionality.

Calls can be accessed from all parts of the country (payphone, fixed line phone and mobile phone) with the system having the intelligence to route the call to its nearest destination based on the calling party number. Mobile service user will probably be responsible for the airtime charges in addition to the premium rate charge of the call. International access is possible and it depends on operator’s implementation.

Premium Rate Service apply to speech calls only.

1.14 Service Function

Page 40 of 159

(41)

When the toll free service is invoked, the FSC/SSP (or ILT) analyzes the called party number and determines that it is a Premium Rate call and routes it to the Premium Rate service logic in the SCP for further call processing. In SCP, the called party, calling party information together with service key is analysed and if the criterias are met, the call is completed and all the charges are applied to the called party. Premium Rate service employs specific dialed digit pattern (1-900-XXX-XXXX being a common plan).

Statically Armed Premium Rate Trigger

Triggers for Premium Rate service are not armed on a per subscriber basis, but are office based. Following criterias maybe used to provision in the SSP :

– Specific digit string (DP2 or DP3) – Prefix (DP2 or DP3)

Either way, the number defined in these criterias are usually the first few digits of the actual Premium Rate number (eg. 1900) but not the complete digit string of the premium rate number.

Page 41 of 159

(42)

1.15 Scenarios

8.1.1 Scenario 1 : Unsuccessful Premium Rate Call (Barring based on Service Provider’s predefined

incoming Blacklist number at the service level)

Description:

Usually, the freephone number is accessible from all types of phones from any operator. However, sometimes there might be a need to block access to freephone service from a certain type of phones, eg. payphone or operator assisted calls. These kind of calls can be differentiated because they have specific value in calling party category field of the ISUP IAM message.

The service logic should have the functionality to allow the network operator to defined a certain list of calling party number or calling party category that is barred from accessing the operator’s freephone service. When the caller makes the call, he hears an invalid tone played by the switch indicating that it is not a valid call. This is achieved by the SCP by sending a INAP ReleaseCall message to the SSP with certain cause value. The default value of the cause code is Normal Unspecified (31) which corresponds to a 3 beep tone.

There is no charge incurred for the call, both for the service user and the service customer.

Call Flow:

Page 42 of 159

EndMessage {ReleaseCall (cause = NormalUnspecified)} ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)}

(43)

Page 43 of 159

O-SSP

T-SCP

B Party

A Party

OSCP

Verify callingPartyNumber or callingPartyCategory is in Service provider’s incoming blacklist

ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)} ContinueMessage { SpecialisedResourceReport (}

(44)

8.1.2 Scenario 2: Unsuccessful Premium Rate Call (Barring based on Service Customer’s predefined

incoming blacklist number)

Description:

Each service customer has its own group of desired/privilege customers and undesired customers. The service customer may wish to have different call routing treatment for different kinds of caller. For the undesired callers, they may want to play an

announcement to block the actual routing of the call to its destination.

Therefore, the service logic should have the functionality to allow each of the service customer to define its own list of incoming blacklist numbers. When the caller makes the call, the service logic recognizes the calling party’s number and plays an

announcement to the caller, eg. “Sorry, you are not allowed to call this number”

There is no charge incurred for the caller (or service user), but the service customer needs to pay for the duration of the announcement call as the call is considered successful call with normal call completion (based on cause code).

Call Flow:

Page 44 of 159 ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)} ContinueMessage { SpecialisedResourceReport (} ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)}

(45)

Page 45 of 159

O-SSP

T-SCP

B Party

A Party

O-SCP

Verify that the callingPartyNumber or

The service logic search for the corresponding service customer record in DataBase based on calledPartyNumber

Verify that the callingPartyNumber is in Service subscriber’s incoming blacklist

If the caller hangs up before the end of announcement, the SCP instruct s SSP to disconnect the connection with the SRF. ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)} ContinueMessage { SpecialisedResourceReport (}

(46)

8.1.3 Scenario 3: Unsuccessful Premium Rate Call (routing to announcement based on Service

Customer’s predefined time dependant routing at the service customer’s level)

Description:

Dependant on the individual service customer who owns the particular freephone number, the routing of the calls, when to play announcement or route to which destination number varies. Usually, a service customer will need to play different Welcome announcement depending on the time of the call. When it is non-office hour, the service customer will select a pre-recorded “Out of office hour” announcement to request the caller to call on the next day.

Therefore, the service logic should have the functionality to allow each of the service customer to define its own non-office hour and announcement. When the caller makes the call, the service logic recognizes that it is during the non-office hour of that particular freephone service customer and plays an announcement to the caller, eg. “Thank you for calling. Our office is closed. Please call again on the next working day.”

There is no charge incurred for the caller (or service user), but the service customer needs to pay for the duration of the call announcement as the call is considered successful call with normal call completion (based on cause code).

Call Flow:

Page 46 of 159 DP: O_CalledPartyBusy TT: O_CalledPartyBusy; DP: O_NoAnswer TT: O_NoAnswer ContinueMessage { RequestReportBCSMEvent (oDisconnect) ConnectToResource (resourceAddress), PlayAnnouncement (informationToSend.inbandinfo.messageID.eleme ntaryMessageID)} ContinueMessage { SpecialisedResourceReport (}

(47)

Page 47 of 159 DP: O_CalledPartyBusy TT: O_CalledPartyBusy; DP: O_NoAnswer TT: O_NoAnswer

O-SSP

T-SCP

B Party

A Party

O-SCP

The service logic search for the corresponding service customer record in DataBase based on

calledPartyNumber

Verify that the time of the call is not during office hour as defined by the service subscriber

Play “Non-office hour” announcement

If the caller hangs up before the end of announcement, the SCP instruct s SSP to disconnect the connection with the SRF.

(48)

8.1.4 Scenario 4: Successful Premium Rate Call from Privilege Callers

Description:

Each service customer has its own group of desired/privilege customers and undesired customers. The service customer may wish to have different call routing treatment for different kinds of caller. For the privilege callers, service customer may want to get the Customer Service Representative to attend to their needs immediately. Also, these CSR could be the selected group who has special language fluency or has more skills.

Therefore, the service logic should have the functionality to allow each of the service customer to define its own list of origin dependent routing and time dependant routing. When the caller makes the call, the service logic recognizes they are the privilege callers and immediately route the call to the serving CSR, without even playing the Welcome announcement. Calls are distributed to a number of different destination numbers according to two distribution methods. In the first method (percentage distribution) the service subscriber specifies a percentage of total calls for each destination and the calls are distributed evenly according to this plan on a call-by-call basis. In the second method, (distribution every n-th call) the service subscriber can specify distribution of calls every n-th call to different destination number. Also, when one number is busy/no answer, the service logic will route call to the next available destination number defined in Line hunting. Possible Line Hunting mechanisms are top of the list, most idle, next after previous answer.

Call Flow:

Page 48 of 159

DP: O_CalledPartyBusy TT:

O_CalledPartyBusy; DP: O_NoAnswer

(49)

Page 49 of 159

O-SSP

T-SCP

B Party

A Party

calledPartyNumber)} initiate a Freephone call

(eg. dial 1600 123456)

OSCP

DP: O_CalledPartyBusy TT: O_CalledPartyBusy; DP: O_NoAnswer TT: O_NoAnswer ContinueMessage {EventReportBCSM(oCalledPartyBusy/oNo

Asnwer)} Start Hunting/Call Forward to the

next destination number defined

call setup completed and voice path established

The service logic search for the corresponding service subscriber’s record in DataBase based on

calledPartyNumber

Translates the service number to actual destination number based on origin dependent and time dependent routing

The intended number is selected based on call distribution mechanism based on key quota/ percentage/nth call

Monitor call for busy / no answer/overflow/answer ContinueMessage { RequestReportBCSMEvent (bcsmEvent), Connect (destinationRoutingAddress)} ContinueMessage { Connect (destinationRoutingAddress)} DP: O_Answer TT: O_Answer ENDMessage {EventReportBCSM(oAnswer)}

(50)

8.1.5 Scenario 5 : Successful Premium Rate Call from Normal Callers

Description:

For a normal freephone caller who is not the privilege callers of the service subscriber, a Welcome Announcement is played to them before the routing of calls. Possibly, they are prompt with a choice menu for them to select which department or service they are requesting from the service subscriber. Afterwhich, the service logic will route the call according to the digit input by the caller.

Therefore, the service logic should have the functionality to allow each of the service customer :

• To define the Welcome message to be played

• to define its own list of origin dependent routing and time dependant routing. Calls are distributed to a number of different destination numbers according to two distribution methods. In the first method (percentage distribution) the service subscriber specifies a percentage of total calls for each destination and the calls are distributed evenly according to this plan on a call-by-call basis. In the second method, (distribution every n-th call) the service subscriber can specify

distribution of calls every n-th call to different destination number.

• To define line hunting/call forward. When one number is busy/no answer, the service logic will route call to the next

available destination number defined in Line hunting. Possible Line Hunting mechanisms are top of the list, most idle, next after previous answer.

Call Flow:

(51)

Page 51 of 159

O-SSP

T-SCP

B Party

A Party

callingPartyCategorycalledPartyNumber)} initiate a Freephone call

(eg. dial 1600 123456)

ContinueMessage

{ PromptAndCollectUserInformation Result/Error ()}

OSCP

call setup unsuccessful ContinueMessage {

ConnectToResource (resourceAddress), PromptAndCollectUserInformation Request (digits),

RequestReportBCSMEvent}

Verify that the callingPartyNumber or callingPartyCategory is not in Service provider’s incoming blacklist

The service logic search for the corresponding service subscriber’s record in DataBase based on calledPartyNumber

Play Welcome Announcement Establish bearer

connection to IP Start announcement

When digit input is received or PAC application timer (T pc) expires, service logic starts the following:

Translates the service number to actual destination number based on origin dependent and time dependent routing The intended number is selected based on call distribution mechanism based on key quota/ percentage/nth call Monitor call for busy /no answer/overflow/asnwer ContinueMessage

{ DisconnectForwardConnection (), RequestReportBCSMEvent (bcsmEvents), Enter digit

Repeat Prompt And Collect ‘n’ times if necessary

(52)

Page 52 of 159

O-SSP

T-SCP

B Party

A Party

OSCP

ContinueMessage {

Connect (destinationRoutingAddress)}

call setup completed and voice path established DP: O_Answer TT : O_Answer ContinueMessage {ReportEventBCSM(oAswer)} DP: O_CalledPartyBusy TT : O_CalledPartyBusy; DP: O_No_Answer TT : O_No_Answer ContinueMessage {ReportEventBCSM(oCalledPartyBusy or

(53)

9.0 Virtual Card Calling (VCC)

1.16 Service Description

The Virtual Calling Card is a prepaid card that provides personal mobility. Subscribers (users) can use any access network and calling unit, fixed and mobile. The VCC cards are of fixed denomination and no subscriber profile is linked to the card. The back-office systems (billing etc) do not have any information about the subscriber, but only have the card details and current balance. The VCC cards are not rechargeable.

The call flow shown below, considers the VCC call initiated from a fixed line phone on the BSNL/MTNL network. The dialled number (example: "31-822") indicates to the BSNL network that the call has to be routed to the local exchange, from where the call is further handled. This call would not be redirected to mobile network, but would rather be handled on the NLD network and service control point.

The subscriber would call a service access number (for example: "31-VCC" [31-822]) to initiate the call. Unless voice recognition is available, all dial option is through DTMF using IVR.

Some of the features for VCC are:  On line / real time debiting

 Multiple simultaneous calls per card / account  One call at a time / card

 Calls having duration below certain threshold  Service calls like language selection etc.  Support multiple currencies simultaneously

 Provision to give bonus call credit based on usage etc.  Follow on Calls  Card Merging  Auto-dialing Page 53 of 159 ContinueMessage { ConnectToResource (resourceAddress.none), PromptAndCollectUserInformation (InformationToSend.inbandinfo.elementaryMe ssgge.MessageID, CollectedInfo.collectedDigits.maximumNbOfDigits)}

(54)

routes it to the VCC service logic in the SCP for further call processing. In SCP, the called party, calling party information together with service key is analysed and if the criterias are met, the call is completed and all the charges are applied to the called party. VCC service employs a 4 digit service access code (eg. 31-822) for callers to dial in to IN for further call connection request.

Statically Armed VCC Trigger

Triggers for VCC service are not armed on a per subscriber basis, but are office or switch based. Following criterias maybe used to provision in the SSP :

– Specific digit string (DP2 or DP3) – CalledPartyNumber (DP2 or DP3)

Either way, the number defined in these criterias should be the complete the complete digit string of the service access code.

Page 54 of 159 ContinueMessage { ConnectToResource (resourceAddress.none), PromptAndCollectUserInformation (InformationToSend.inbandinfo.elementaryMe ssgge.MessageID, CollectedInfo.collectedDigits.maximumNbOfDigits)}

(55)

1.18 Scenarios

9.1.1 Scenario 1 : Successful Virtual Card Call (Point to point card)

Description:

Sometimes, for promotional purposes, the corporate customers will want to issue to the general public or their customers calling cards with predefined denominations with predefined destination number (eg. the corporate customer’s own hotline or CSR). When the caller dials the VCC service access number, and enters card number / PIN (if CLI is not recognized), the service logic in SCP automatically pulls out the destination number predefined by the corporate customer and connect the call to this number. The caller will not be prompt to enter his/her desired destination. In fact, the caller will not be able to make calls to other destination besides the predefined number.

Call Flow:

Page 55 of 159 ContinueMessage { ConnectToResource (resourceAddress.none), PromptAndCollectUserInformation (InformationToSend.inbandinfo.elementaryMe ssgge.MessageID, CollectedInfo.collectedDigits.maximumNbOfDigits)} ContinueMessage {ApplyChargingReport()}

(56)

Page 56 of 159

BeginMessage {InitialDP (serviceKey, callingPartyNumber,calledPartyNumber) }

initiate a VCC call (eg. dial 31822 access number)

ContinueMessage { ReturnResult (PromptAndCollectUserInformation, digitsResponse)} ContinueMessage { ConnectToResource (resourceAddress.none), PromptAndCollectUserInformation (InformationToSend.inbandinfo.elementaryMe ssgge.MessageID, CollectedInfo.collectedDigits.maximumNbOfDigits)}

Play the corresponding Welcome announcement specified for VCC service

Prompt user for card number

Establish bearer connection to IP Start announcement

A Party inputs 12-digit VCC card number

Repeat Prompt And Collect ‘n’ times if necessary ContinueMessage {ApplyChargingReport()} ContinueMessage {ApplyChargingReport()} ContinueMessage {PlayAnnouncement)}

(57)

Page 57 of 159

ContinueMessage {ApplyChargingReport()}

Validate card number

Check the status of the card (Active or not) If card is active, check balance available and play annoncement notifying user of the remaining balance Check if there is already an ongoing call. If yes, validate time gap between simultaneous calls.

Check if there is any service provider /customer defined promotional / marketing messages. Play the promotional message is there is any.

ContinueMessage

{DisconnectForwadConenction, RequestReportBCSMEvent Dynamically set EDP-R

O_Called_Party_Busy O_No_Answer

Dynamically set EDP-N O_Answer O_Disconnect

A Party

ContinueMessage { SpecialisedResourceReport}

OSCP

ContinueMessage { ConnectToResource (resourceAddress.none), PlayAnnouncement (InformationToSend.inbandinfo.elementaryMess gge.MessageIDs)}

Recognizes the card is a Point to point card : Allocate a threshold to the SSP indicating the time allowed for the call to proceed before reporting SCP the charging report.

Connect the call to the predefined destination number for the card.

Establish bearer connection to IP Start announcement

OSSP

TSSP

B Party

ContinueMessage { PlayAnnouncement (InformationToSend.inbandinfo.elementaryMess gge.MessageIDs)} ContinueMessage { SpecialisedResourceReport}

Recognizes the card is a Point to point card : Based on the tariff rate for the destination number, play announcement to indicate the duration allowed for the call.

ContinueMessage { ConnectToResource (resourceAddress.none), PromptAndCollectUserInformation (InformationToSend.inbandinfo.elementaryMe ssgge.MessageID, CollectedInfo.collectedDigits.maximumNbOfDigits)} ENDMessage { DisconnectForwardConnection, ReleaseCall)} ContinueMessage {ApplyChargingReport()} ContinueMessage {PlayAnnouncement)}