Fraud Management Systems

Intelligent Networks,
CAMEL protocol, Services

and Applications
Tinniam.V. Ganesh
tvganesh.85@gmail.com
Tinniam V Ganesh - http://gigadom.wordpress.com 1

Why Intelligent Networks ?
The initial digital switches like Lucent’s 5ESS, Nortel’s

DMS-100, Ericsson’s AXE included feature processing as
a part of the switch software. New features or changes to
features were expensive and time consuming.
Intelligent Networks removes Service Creation from the

switch to a remote Node, the Service Control Point
(SCP).

12/3/2008
History
History : Intelligent Networks started off by providing

number translation service with the aid of another
Network Node. It was used for free phone services like
8XX- services.

12/3/2008
Basics of IN
What is an Intelligent Network ? What does it try to achieve
 Intelligent Networks (IN) define a distributed framework of communicating network

elements which together provide services.
 Allows Service Providers to provision services quickly with little or no help from the
suppliers of digital exchanges.
 Service processing through IN builds upon, the current call process infrastructure of
existing digital exchanges. It does so by using
 a generic model of existing Call Control Functionality (CCF) to process basic two-
party calls
 Service Switching Functionality (SSF) to invoke IN service.
 Once invoked, IN service logic is executed under the control of Service Control
Functionality (SCF), in conjunction with Service Data Functionality (SDF).

12/3/2008
Network Elements in an Intelligent
Network

12/3/2008
Network Elements in an Intelligent
Network
 SSF – Service Switching Function - Provides a set of functions that
are required for interaction with the CCF and SCF.
 SCF – Service Control Function – The SCF executes Service Logic
and commands the SSF to perform call related actions
 SRF – Specialized Resource Function – The SRF plays
announcements and collects user digits
 SDF – Service Data Function – contains customer and network
related data for access by the SCF
 CCF – Call Control Function - provides call processing functions

12/3/2008
Relationship between CCF and other
entities

12/3/2008
BCSM
Basic Call State Model
 The BCSM is used to describe the actions in an Switch/
MSC/GMSC during originating, forwarded or terminating calls.
 The BCSM identifies the points in basic call processing when logic
instances (accessed through the SCF) are permitted to interact
with basic call control capabilities.

12/3/2008
BCSM model
BCSM Model
Overview
 The BCSM provides a high-level model description of CCF activities
required to establish and maintain communication paths for users.
 Many aspects of the BCSM are not externally visible to IN service logic
instances. However, aspects of the BCSM that are reflected upward to the
SSF are visible to IN service logic instances and can be influenced by the
SCP.
 The BCSM identifies points in basic call when IN service logic instances can
interact with basic call and connection control capabilities. The BCSM
provides a framework for describing basic call and connection events that
can lead to the invocation of IN service logic instances or should be reported
to active IN service logic instances.
 BCSM models exist for both the originating and terminating half of the call
and are called O-BCSM and T-BCSM respectively.

12/3/2008
Components of a BCSM
The components that describe a BCSM, are points in
call (PICs), detection points (DPs), BCSM transitions,
and events.
 PICs identify CCF activities associated with one or
more basic call/connection states of interest to IN
service logic instances. Transition
 DPs indicate states in basic call and connection
processing at which transfer of control from non-IN DP
to IN service logic can occur. BCSM transitions
indicate the normal flow of basic call/connection Point In Call (PIC)
processing from one PIC to another. Entry events

cause BCSM transitions into PICs. Exit events
represent the result of PIC processing.

12/3/2008
Originating and Terminating half
call
gsmSCF (1)
CAMEL relationship
MSC
gsmSSF/CCF
O(A-B) T(A-B)
A-Party B-Party

12/3/2008
Originating BCSM (O-BCSM)
Originating Basic Call State Model

12/3/2008
T-BCSM
Terminating- Basic Call State Model
T_Null T_Exception
T_Abandon
Terminating_Attempt_Authorised
T_Busy
Terminating Call Handling T_No_Answer
T_call_handling_failure
T_Disconnect
T_Answer
T_Active T_active_failure

Basic Call transition
12/3/2008
Detection Points (DP) types)
 Certain basic call events may be visible to the GSM Service Control Function
(gsmSCF). The DPs are the points in call at which these events are detected.
 A DP can be armed in order to notify the gsmSCF that the DP was encountered, and
potentially to allow the gsmSCF to influence subsequent handling of the call. If the DP
is not armed, the processing entity continues the processing without gsmSCF
involvement.
 Three different types of DPs are identified:
 Trigger Detection Point - Request (TDP-R)
This detection point is statically armed and initiates a IN/ CAMEL control relationship when
encountered and there is no existing relationship. Processing is suspended when the DP is
encountered.
 Event Detection Point - Request (EDP-R)
This detection point is dynamically armed within the context of a CAMEL control
relationship. Processing is suspended when encountering the DP and the gsmSSF waits for
instructions from the gsmSCF.
 Event Detection Point - Notification (EDP-N)
This detection point is dynamically armed within the context of a CAMEL control
relationship. Processing is not suspended when encountering the DP.

12/3/2008
O-BCSM Detection Points (DPs)
Camel detection Point Armed as Reported when
DP O-Collected Info TDP-R All digits collected according

to dialing plan.
DP O-Analyzed Info TDP-R Information analyzed and
digits translated to obtain
routing address and NOA
DP O- RouteSelectFailure TDP-R,EDP-N,EDP-R A route could not be
selected
DP O-Busy EDP-N,EDP-R A busy indication received
from the terminating party
DP O-No Answer EDP-N,EDP-R A no-answer event detected
DP O-Answer EDP-N,EDP-R The terminating party has

answered
DP O-Disconnect (9a/9b) EDP-N,EDP-R Disconnection after being in
active conversation
DP O-Abandon EDP-N,EDP-R Originator disconnects
before answer is detected at
the terminating end
12/3/2008
T-BCSM Detection Points (DPs)
CAMEL Detection Point: DP Type Description:
DP12 Terminating Attempt TDP-R Indication that the Termination attempt is
Authorised analysed.
DP 13 T_Busy EDP-N, EDP-R Indication that:

- a busy indication is received from the
destination exchange,
- Not reachable or call establishment failure
event is determined from the HLR
response or upon a cause IE in the ISUP
release message.
DP 14 T_No_Answer EDP-N, EDP-R Indication that an application timer associated
with the T_No_Answer DP expires
DP15 T_Answer EDP-N, EDP-R Call is accepted and answered by terminating

party
DP17 T_Disconnect EDP-N, EDP-R A disconnect indication is received from the

terminating party or from the originating
party.
DP 18 T_Abandon EDP-N A disconnect indication is received from the
originating party during the call
establishment procedure
12/3/2008
DP Processing Rules
DP processing rules
 The gsmSSF shall apply the following set of rules during DP processing to ensure
a single point of control:
 EDPs are disarmed by the gsmSSF as they are encountered and reported to the
gsmSCF, when the occurrence of another EDP causes the implicit disarming of
the EDP or when the leg clears.
 A control relationship persists as long as there is 1 or more EDP-R armed for this
portion of the call or if the gsmSSF is in any state except Monitoring or Idle.
 A control relationship changes to a monitor relationship if the control
relationship does not persist and :
 1 or more EDP-N armed, or
 1 or more Call information Report outstanding, or an Apply Charging Report
outstanding.
 A control relationship terminates if it does not persist and does not change to a
monitor relationship. A monitor relationship terminates if there are neither EDP-
Ns armed nor reports outstanding or if the call clears.

12/3/2008
DP Processing rules
Arming/disarming mechanism
 The mechanism by which the DP is armed. A DP may be statically armed or
dynamically armed.
The following arming rules apply:
 A DP is dynamically armed by the gsmSCF within the context of a CAMEL control
relationship (between the gsmSSF and the gsmSCF).
The following disarming rules apply:.

 If an armed EDP is met, then it is disarmed.
 If an EDP is met that causes the release of the related leg, then all EDPs related to
that leg are disarmed.
 If a call is released, then all EDPs related to that call are disarmed.
 If an EDP is met, then other EDPS are disarmed, in accordance with the implicit
disarming rule table
 If an EDP is armed, it can be explicitly disarmed by the gsmSCF by means of the
RequestReportBCSMEvent information flow.

12/3/2008
Implicit disarming rules for DPs in O-BCSM
Encountered DP Implicit disarmed DPs

DP4 DP 5 DP 6 DP 7 DP 9 leg 1 DP 9 leg 2 DP 10
DP4 Route_Select_Failure X X X X X
DP5 O_Busy X X X X X
DP6 O_No_Answer X X X X X
DP7 O_Answer X X X X X
DP9 O_Disconnect leg 1 X X
DP9 O_Disconnect leg 2 X X X X X
DP10 O_Abandon X X
12/3/2008
Implicit disarming rules for DPs in T-BCSM
Encountered DP Implicit disarmed DPs

DP 13 DP 14 DP 15 DP 17 leg 1 DP 17 leg 2 DP 18
DP13 T_Busy X X X X
DP14 T_No_Answer X X X X
DP 15 T_Answer X X X X
DP 17 T_Disconnect leg 1 X X
DP 17 T_Disconnect leg 2 X X X X
DP18 T_Abandon X X

12/3/2008
Protocol layers
SSP SCP
INAP/CAP INAP/CAP
TCAP TCAP
SCCP SCCP
MTP[3-1] MTP[3-1]

12/3/2008
SCCP – Signaling Connection Control
Point
SCCP provides a routing function which allows signalling messages
to be routed to a signalling point based on, for example, dialed
digits. This capability involves a translation function which
translates the global title (e.g. dialed digits) into a signalling point
code and a sub-system number

12/3/2008
SCCP parameters
SCCP message parameters

point code: The "point code" identifies a signalling point where the affected
subsystem or SCCP is located.
subsystem number: The " subsystem number" parameter field identifies the
SCCP or a subsystem which is failed, withdrawn, congested or allowed.
(INAP,CAP, MAP)
calling/called party address: The "calling/called party address" parameter
field, together with additional information given by the MTP, contains
enough information to uniquely identify the origination/destination
signalling point and/or the SCCP service access point.
It can be any combination of a global title (dialled digits, for example), a
signalling point code, and a subsystem number. The subsystem number
(SSN) identifies an SCCP user when provided.
.

12/3/2008
Point Codes
Point codes
Every signalling point (SP) and signalling transfer point (STP), when
integrated in an SP, will be allocated its own unique point code. This is used
by the MTP routing function to direct outgoing messages towards their
destination in the network as indicated by the inclusion of the appropriate
point code in the routing label. This point code is known as the destination
point code (DPC). The routing label also contains the point code of the SP
originating the message signal unit, therefore, the combination of this
originating point code (OPC) and DPC will determine the signalling relation
(i.e. the network points between which MTP “User” information is
exchanged). The DPC is used by the receiving SP/STP discrimination
function to determine whether the message is addressed to that SP or
requires to be onward routed by means of the signal transfer capability of
the STP.

12/3/2008
TCAP
TCAP provides the means to establish non-circuit-related
communication between two nodes in the signaling network.
IN messages are encapsulated within TCAP messages before being sent
out.
 TCAP provides the transport to the INAP/CAP operations.

 Has 2 layers
 Transaction portion
 Dialogue Portion
 Component portion

12/3/2008
TCAP Sub Layers

12/3/2008
Transaction Portion
 Transaction portion identifies the originating and destination
dialogue instances by their transaction id.
 Five types of Transaction layer messages
 Begin –Used to set up a dialogue. Has only originating
transaction id.
 Continue – Used during a dialogue. Has both origination &
destination transaction id.
 End – Used to end a dialogue. Contains only destination
transaction id
 Abort – Used for abnormal termination. Only destination
transaction id
 Unidirectional – Sent when there is no need to establish a
transaction with the remote entity. Has only origination
transaction id

12/3/2008
Component Portion
Information element Tag
… Length
Contents
Information element
b) Information element
a) Component
Carries the INAP/CAP operation. The component portion can carry

many operations. A Component is made of several Information
Elements. An information consists of 3 elements tag, length and
contents

12/3/2008
Component Types
 Types of components
 Invoke : This component indicates that the operation requires a
procedure to be executed at the remote end (SSP/SCP)
 Return Result : Indicates the result of a previously requested
operation
 Return Error : Indicates there were errors in the INAP/CAP eg.
Operation level errors (missing parameters, parameter out of
range etc).
 Reject – Indicates a operation not supported by the Application
Context, parameters not supported for operation as defined

12/3/2008
Dialogue Portion
 Used to establish the application context that will be used in the
dialogue

12/3/2008
ASN.1/BER
 All INAP/CAP operations are ASN.1 encoded before it is sent out by
the SSP or SCP.
 The encoded operation will be included in the component portion of
the TCAP message.
 When the SSP/SCP receive any operation the operation is ASN.1
decoded before passing it to the application.
 ASN.1 – Abstract Syntax Notation provides a representation of data
in an unambiguous way
 BER – Basic Encoding Rules (BER) state how the data is to be
transferred so that the entities on either end can understand and
decode the data.

12/3/2008
ASN.1 (contd.)
 A piece of information can have a type (INTEGER, BOOLEAN…) and a value (X) analogous to
programming languages
 There are 4 ASN.1 types
 Simple – Also known as primitive types and are the built in types
 Structured – Also known as constructed types and consist of structure of simple types
(analogous to a C –structure)
 Tagged types – Are used to remove ambiguities in the ASN.1 definition of field
 Sub-types – Use existing types like
portNumber ::= INTEGER (1..65535)
 ASN.1 Built in types

BOOLEAN, INTEGER, BIT STRING, OCTET STRING, NULL, ENUMERATED, SEQUENCE,
SEQUENCE OF, CHOICE, OBJECT IDENTIFIER …
e.g EthernetAdapterStatus ::= ENUMERATED {normal(0), degraded(1), offline(2), failed(3) }
EthernetNumberOfCollisions ::= INTEGER
EthernetAdapterNumber ::= OCTET STRING -- OCTETs represent 8 bit bytes

12/3/2008
ASN.1 (contd.)
Structured Types
 EthernetCollisionsCounter ::= SEQUENCE {
highValue Integer,
lowValue Integer
} -- Similar to a C structure
 RequestedInformationValue ::= CHOICE

callAttemptElapsedTimeValue [0] INTEGER (0..255)
callStopTimeValue [1] IMPLICIT DateAndTime,
callConnectedElapsedTimeValue [2] IMPLICIT Integer4,
releaseCauseValue [30] IMPLICIT Cause,
} – Similar to a C Union

12/3/2008
ASN.1 contd.
Tagged Types
If tags were not sent the receiving end would not be able to distinguish which of the parameters was
sent by the sending end
A ::= CHOICE {
x INTEGER,
y INTEGER
}
Tags can be EXPLICIT or IMPLICIT

IMPLICIT tags – There is no need to transfer the data type. The tag alone would enable to
discriminate
EXPLICIT tags – the data type needs to be transferred
If an IMPLICIT tag is not specified then the tag by default is EXPLICIT
In the IMPLICIT tag is used in ASN.1 module definitions then all tags in the module are IMPLICIT
A user-defined has a class and a number within square brackets [] as shown in the previous page e.g
callAttemptElapsedTimeValue [0] INTEGER (0..255)

12/3/2008
Basic Encoding Rules
(BER) TLVTLV
T L
 Provide the conventions of actual data transfer –
n the form of Type, Length, Value Value
Class Bit 8 Bit

7
UNIVERSAL 0 0
Type
APPLICATION 0 1
To network Class P/C Tag Number CONTEXT- 1 0
SPECIFIC
PRIVATE 1 1
Primitive – (0) BOOLEAN, INTEGER, OCTET

STRING, NULL, ENUMERATED, OBJECT
IDENTIFIER
Constructed – (1) SEQUENCE, SEQUENCE OF,
CHOICE

12/3/2008
Universal Tags
UNIVERSAL Class Tags
UNIVERSAL 1 BOOLEAN
UNIVERSAL 2 INTEGER
UNIVERSAL 3 BIT STRING
UNIVERSAL 4 OCTET STRING
UNIVERSAL 5 NULL
UNIVERSAL 6 OBJECT IDENTIFIER
UNIVERSAL 10 ENUMERATED
UNIVERSAL 16 SEQUENCE and SEQUENCE OF
UNIVERSAL 22 IA5String
ooo

12/3/2008
ASN.1 Examples
 A :: [UNIVERSAL 1] BOOLEAN
If A is TRUE then
00000001 00000001 111111111
Type Length Value
0 0 – UNIVERSAL 0 – PRIMITIVE 0 0 0 0 1 – UNIVERSAL BOOLEAN
0000 0001 – Length 1111 1111 - value
B is an INTEGER value 32
B :: [2] IMPLICIT INTEGER
10000010 0000001 00100000
1 0 – CONTEXT-SPECIFIC 0 - PRIMITIVE 0 0 0 1 0 – Tag Number
0000 0001 – Length
0010 0000 - Value = 32

12/3/2008
Eg. ASN.1
Assume all parameters are context-specific
Wms_rackinfo ::= [0] WmsRackInfo;
WmsRackInfo :: = SEQUENCE
{
rackID [0] IMPLICIT INTEGER, -- 2
name [1] IMPLICIT IA5String (SIZE(8)), -- “rack1” – 72,61,63,6b,31
descr [2] IMPLICIT IA5String(SIZE(8)), -- “level 2” - 6c,65,76,65,6c,20,32
location [3] IMPLICIT IA5String(SIZE(2)) -- “03” – 30,33
}
rackID is ------------- -> 80 01 02
name ------------- r a c k 1 –> 81 05 72 61 63 6b 31
descr --------------- l e v e l 2 –> 82 07 6c 65 76 65 6c 20 32
location ------------- 0 3 –> 83 02 30 33

12/3/2008
INAP/CAP Operations
 INAP/CAP Operations are transferred between entities

 Actions are taken at the nodes depending on the INAP/CAP Operation sent
and the current state in which it is received.
 Services are achieved through the transfer of INAP/CAP operations between
the SSP (switch) and the SCP ( Service Control Point) . IN/Camel
Application Protocol (INAP) is a ROS Element user protocol.
 The ROS protocol is contained within the component sub layer of the TCAP
protocol.
 The INAP/CAP operation is ASN.1 encoded and included in the component
portion of the TCAP message.

12/3/2008
INAP/CAP operation
INAP User ASE's
xyz OPERATION
ARGUMENT {Parameter1, Parameter2,...}
RESULT {Parameter1, Parameter2,...}
LINKED {operation3, operation4,...}
ERRORS {error1, error2....} Operations
to peer Results
error1 ERROR Errors
PARAMETER {Parameter6, Parameter7,...}
etc
TCAP ASE
INVOKE
RETURN RESULT
COMPONENT SUB-LAYER to peer RETURN ERROR
REJECT
BEGIN
TRANSACTION SUB-LAYER to peer CONTINUE
END
ABORT
UNIDIRECTIONAL
CONNECTIONLESS SCCP
12/3/2008
Application layer protocols
(INAP/CAP)
 INAP/CAP are the application layer protocols and talk to their peers at the
other end.
 The protocol units are ROS elements, consisting of Operations and
functions.
 Operations are defined in ASN.1 format.

12/3/2008
Connect Operation
connect {PARAMETERS-BOUND : bound} OPERATION ::= {
ARGUMENT ConnectArg {bound}
RETURN RESULT FALSE
ERRORS {missingParameter |
parameterOutOfRange |
systemFailure |
taskRefused |
unexpectedComponentSequence |
unexpectedDataValue |
unexpectedParameter}
CODE opcode-connect
}

12/3/2008
Connect Operation (CAP Phase 3)
ConnectArg {PARAMETERS-BOUND : bound} ::= SEQUENCE {
destinationRoutingAddress [0] DestinationRoutingAddress {bound},
alertingPattern [1] AlertingPattern OPTIONAL,
originalCalledPartyID [6] OriginalCalledPartyID {bound} OPTIONAL,
extensions [10] SEQUENCE SIZE(1..bound.&numOfExtensions) OF
ExtensionField {bound} OPTIONAL,
carrier [11] Carrier {bound} OPTIONAL,
callingPartysCategory [28] CallingPartysCategory OPTIONAL,
redirectingPartyID [29] RedirectingPartyID {bound} OPTIONAL,
redirectionInformation [30] RedirectionInformation OPTIONAL,
genericNumbers [14] GenericNumbers {bound} OPTIONAL,
serviceInteractionIndicatorsTwo [15] ServiceInteractionIndicatorsTwo OPTIONAL,
chargeNumber [19] ChargeNumber {bound} OPTIONAL,
cug-Interlock [31] CUG-Interlock OPTIONAL,
cug-OutgoingAccess [32] NULL OPTIONAL,
suppressionOfAnnouncement [55] SuppressionOfAnnouncement OPTIONAL,
oCSIApplicable [56] OCSIApplicable OPTIONAL,
naOliInfo [57] NAOliInfo OPTIONAL,
...

12/3/2008
INAP/CAMEL
Call related operations
Operation Direction Function
InitialDP SSP -> SCP Indicates to the SCP
Originating/Terminating trigger was
met
Connect SCP -> SSP Requests the SSP to route based on

DRA
RequestReportBCSM SCP - SSP Arms Detection Points
EventReportBCSM SSP -> SCP Reports Detection Points armed and

sends results
ReleaseCall SCP -> SSP SCP sends this message to release

the current call
CallInformationRequest SCP -> SSP Request for information related to

call like setup time, call connected
time etc
CallInformationReport SSP -> SCP Report on the parameters sent

above
Cancel(allRequests) SCP -> SSP Removes all currently armed

detection points in call

12/3/2008
INAP/CAMEL
Announcement operations
ConnectToResource SCP -> SSP Requests SSP to connect to media
resource/Intelligent Peripheral (IP)
PlayAnnouncement SCP -> SSP /IP Play an announcement/tone to the

user
PromptAndCollectUserInfor SCP – SSP /IP Play an announcement to the user

and also collect digits entered
mation
SpecializedResourceReport IP/SSP -> SCP Sent after completion of the

announcement
Cancel SCP -> SSP/IP Stop playing announcement/tone
DisconnectForwardConnecti SCP -> SSP SCP requests the SSP/IP to

disconnect the connection to the IP
on
12/3/2008
INAP/CAMEL
Charging operations
FurnishCharging SCP -> SSP Charge the user based on the

charging info sent in the operation
SendCharging SCP -> SSP Also charges the user based on

charging information sent but
includes a tariff timer which sends the
AoC parameters
ApplyCharging SCP -> SSP Charge user for a specific duration &
tariff interval based on the charging
info
ApplyChargingReport SCP -> SSP Send information on the call that will
be used for charging namely call
time, setup time in the context of the
tariff interval sent

12/3/2008
INAP/CAMEL
Non-call related operations
Operation Direction Description
ActivateServiceFiltering SCP -> SSP Filter call based on filtering criteria for a specific
duration and send filtering responses at specified
intervals. Play appropriate announcement/tone to
filtered calls. Used in Televoting
ServiceFilteringResponse SSP -> SCP Response sent to ASF at regular intervals within
the duration
CallGap SCP -> SSP Gap calls based on called party address/ service
key or both. Play an announcement. No response
expected from SSP.
Link Test Operations

Operation Direction Description
ActivityTest SCP -> SSP Tests SS7 link between SCP and
SSP

12/3/2008
Class of operations
The INAP/CAP operations belong to a class which signify whether then remote
end will send the result of thee operation, errors or both as shown.
 Class 1 – Results and errors
 Class 2 – Only Errors
 Class 3 – Only result
 Class 4 – No error or result

12/3/2008
CAMEL network
Home Network
HLR MAP gsmSCF
CAP
MAP CAP MAP
gsmSSF VLR gsmSSF
Incoming line GMSC Roaming leg MSC MS

MAP
Forwarded leg MO call - Outgoing leg

(or Forwarding leg)
CAP
Interrogating Network Visited Network
gsmSRF
Home/Interrogating/Visited Network

12/3/2008
CAMEL Network
 HLR: For subscribers requiring CAMEL support, the HLR stores the information
relevant to the current subscription regarding O-CSI,T-CSI. The O-CSI is sent to the
VLR at Location Update, or if the O‑CSI is updated by administrative action. The O/T-
CSI is sent to the GMSC when the HLR responds to a request for routeing
information.
 GMSC: When processing the calls for subscribers requiring CAMEL support, the
GMSC receives an O/T‑CSI from the HLR, indicating the GMSC to request
instructions from the gsmSSF. The GMSC monitors on request the call states (events)
and informs the gsmSSF of these states during processing, enabling the gsmSSF to
control the execution of the call in the GMSC.
 MSC: When processing the calls for subscribers requiring CAMEL support, the MSC
receives an O‑CSI from the VLR indicating the MSC to request instructions from the
gsmSSF. The MSC monitors on request the call states (events) and informs the
gsmSSF of these states during processing, enabling the gsmSSF to control the
execution of the call in the MSC.
 VLR: The VLR stores the O-CSI as a part of the subscriber data for subscribers
roaming in the VLR area.

12/3/2008
SSF state machine

12/3/2008
State transitions of the SSF
state
Operation Idle WFI WEUI Monitor WETC

InitialDP WFI
Connect Idle/Monitoring
CTR WEUI
PA/PCUI No change
DFC WFI
CIRQ No change No change No change
EDP-R WFI
EDP-N No change*
ACRq No change No change No change
CIRQ No change No change No change
No
CIRP No change* No change* No change* change*
ETC WETC
DFC WFI
SRR No change
No
ACR No change* No change* No change* change*
* Moves to Idle if no other reports are pending and there

are no EDPs armed
12/3/2008
SCF state machine

12/3/2008
SCF state machine (contd.)

12/3/2008
Freephone call
SCP
3.InitialDP
4Connect
SSF
2. callEventNotify()
5. routeRequest()
9.ANM
CCF 7.ACM
(O-BCSM) 6.IAM
12.REL
1. IAM
8.ACM
11.REL
10.ANM Tinniam V Ganesh - http://gigadom.wordpress.com 55
12/3/2008
Freephone call
TC – Begin
Application Context
Origination Transaction ID SSP -> SCP
Component-Invoke
InitialDP (ASN.1 encoded)
TC – Continue
Application Context
Origination Transaction ID
Destination Transaction ID
SCP -> SSP Component -Invoke
Connect (ASN.1 encoded)
12/3/2008
Scenario 1 – Follow-on, follow-me
1. When a triggering criteria is met at a statically armed Trigger Detection Point
(O -Analyzed Information) a InitialDP is sent from the SSP to SCP
containing the Service Key, calling party address, called party address
detection point etc. A dialogue is now open between the SSP and the SCP.
The InitialDP is sent in a TC-Begin. The InitialDP is sent in a Invoke
Component of the Component portion.
2. SCP sends a RequestReportBCSM requesting SSP to arm detection points

4r,5r,6r,7n,9br,9ar as Event Detection Point within the context of the call. A
Connect operation is sent to route the call. This is sent in a TC-Continue and
the component portion contains both the RequestReportBCSM and the
Connect with the (Destination Routing Address) DRA as one of the
mandatory parameters. This could be his office number.
The SSF requests the CCF to arm the necessary detection points and to route
the call based on the DRA.

12/3/2008
Follow-on, Follow-me service
3. The call hits (DP- RouteSelectFailure) while routing the call. Leg2 is
released and EDPs armed on this leg are disarmed. An EDP-4 is sent
upwards and call processing suspends waiting for further
instructions
4. The SCP again arms EDPs 4r,5r,6r,7n,9br,9ar and a Connect with a
new number, his mobile number.
The SSF/CCF arms the DPs and routes the call to the new number.
5. This time the terminating party answers the call.
A EDP 7n is sent upward to the SCF. Call Processing does not
suspend.
The call is now in conversation.

12/3/2008
Follow-on, Follow-me service
6. The terminating party now disconnects and a EDP 9bR is sent to

the SCP.
7. The SCP sends a ReleaseCall to release the call .

12/3/2008
Services – Follow–on, Follow-me
SSP DP -3 O - Analyzed Info
Idle SCP
1. TC-Begin
(InitialDP(sk))
WFI
2. TC-Continue (RequestReportBCSM (4r,5r,6r,7n,9br,9ar), Connect(dra) )
Monitoring
3. TC-Continue (EventReportBCSM 4r)
4. TC-Continue (RequestReportBCSM (4r,5r,6r,7n,9br,9ar), Connect)

WFI
Monitoring 5. TC-Continue (EventReportBCSM 7n)
Conversation DP -7 O- Active
DP – 9b O- Disconnect
Monitoring 6. TC-Continue (EventReportBCSM 9br)
WFI
Implicity disarm DPs on Leg2

7. TC-Continue
Tinniam V Ganesh (ReleaseCall)
- http://gigadom.wordpress.com 60
12/3/2008
Services – Call with Announcement
1. The call triggers on DP-3 O Analyzed-Info and a InitialDP is sent.
2. SCP sends a ConnectToResource to connect to media resource
function. SCP sends a PlayAnnouncement requesting the
necessary announcement to be played.
3. When the announcement is completed a
SpecializedResourceReport is sent to the SCP
4. SCP now sends a DisconnectForwardConnection to disconnect the
media resource.
5. SCP arms EDPs 4r,5r,6r,7n,9br,9ar,10r and sends a Connect
6. When the terminating party answers a EDP-7n is sent and the call
goes to answer
7. When the terminating party disconnects a EDP 9br is sent
8. SCP sends a ReleaseCall to release the call

12/3/2008
Services - Call with Announcement
SSP DP -3 O - Analyzed Info SCP
Idle
1. TC-Begin (InitialDP)
Integrated WFI
MediaResource
Function 2. TC-Continue (CTR, PlayAnnouncement )
WEUI
Connect to MediaResource and

Play Announcement
Announcement
Complete 3. TC- Continue (SpecializedResourceReport)
WEUI 4. TC-Continue (DisconnectForwardConnection)
5. TC-Continue (RequestReportBCSM (4r,5r,6r,7n,9br,9ar), Connect)

WFI
Monitoring
36 TC-Continue (EventReportBCSM 7n)
DP – 9b O- Disconnect
3. TC-Continue (EventReportBCSM 9br)
7. TC-Continue EDP-9bR
WFI
Implicity disarm DPs on Leg2 8. TC-Continue ReleaseCall

Idle
12/3/2008
Prepaid Service
SSP DP -3 O - Analyzed Info SCP
Idle
1. TC-Begin (InitialDP(sk))
WFI
2. TC-Continue (RequestReportBCSM (4r,5r,6r,7n,9br,9ar), ACRq, Connect)
Monitoring
3. TC-Continue (EventReportBCSM 7n)
4. TC-Continue (ACR, ERB 9br)
WFI
5. TC-Continue (RequestReportBCSM (4r,5r,6r,7n,9br,9ar), ACRq, Connect)
Monitoring 6. TC-Continue (EventReportBCSM 7n)
Warning tone
applied
Timeout 7. TC-Continue (ACR)
8. TC-Abort

12/3/2008
IN Flavors
ANSI world – AIN 0.1, AIN 0.2
ETSI world – ETSI-INAP CS1, ETSI-INAP CS2, ETSI-INAP CS3, ETSI-INAP
CS4
WIN – Wireless IN
GSM, 3GPP – CAMEL Phase 1, Phase 2, Phase 3, Phase 4
IMS World – CAMEL for IMS
Java INAP APIs - JAIN

12/3/2008
Thank You !!!
Tinniam V Ganesh
tvganesh.85@gmail.com
Read my blogs: http://gigadom.wordpress.com/
http://savvydom.wordpress.com/

12/3/2008

Fraud Management Systems

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Fraud Management Systems

Caricato da

Copyright:

Formati disponibili

Intelligent Networks,

CAMEL protocol, Services

Tinniam V Ganesh - http://gigadom.wordpress.com 1

The initial digital switches like Lucent’s 5ESS, Nortel’s

Intelligent Networks removes Service Creation from the

Tinniam V Ganesh - http://gigadom.wordpress.com 2

History : Intelligent Networks started off by providing

Tinniam V Ganesh - http://gigadom.wordpress.com 3

 Intelligent Networks (IN) define a distributed framework of communicating network

Tinniam V Ganesh - http://gigadom.wordpress.com 4

Tinniam V Ganesh - http://gigadom.wordpress.com 5

Tinniam V Ganesh - http://gigadom.wordpress.com 6

Tinniam V Ganesh - http://gigadom.wordpress.com 7

Tinniam V Ganesh - http://gigadom.wordpress.com 8

Tinniam V Ganesh - http://gigadom.wordpress.com 9

processing from one PIC to another. Entry events

Tinniam V Ganesh - http://gigadom.wordpress.com 10

Tinniam V Ganesh - http://gigadom.wordpress.com 11

Tinniam V Ganesh - http://gigadom.wordpress.com 12

Terminating Call Handling T_No_Answer

Tinniam V Ganesh - http://gigadom.wordpress.com 13

Tinniam V Ganesh - http://gigadom.wordpress.com 14

DP O-Collected Info TDP-R All digits collected according

DP O-Answer EDP-N,EDP-R The terminating party has

DP 13 T_Busy EDP-N, EDP-R Indication that:

DP15 T_Answer EDP-N, EDP-R Call is accepted and answered by terminating

DP17 T_Disconnect EDP-N, EDP-R A disconnect indication is received from the

Tinniam V Ganesh - http://gigadom.wordpress.com 17

The following disarming rules apply:.

Tinniam V Ganesh - http://gigadom.wordpress.com 18

Encountered DP Implicit disarmed DPs

DP9 O_Disconnect leg 1 X X

DP9 O_Disconnect leg 2 X X X X X

Encountered DP Implicit disarmed DPs

Tinniam V Ganesh - http://gigadom.wordpress.com 20

Tinniam V Ganesh - http://gigadom.wordpress.com 21

Tinniam V Ganesh - http://gigadom.wordpress.com 22

SCCP message parameters

Tinniam V Ganesh - http://gigadom.wordpress.com 23

Tinniam V Ganesh - http://gigadom.wordpress.com 24

 TCAP provides the transport to the INAP/CAP operations.

Tinniam V Ganesh - http://gigadom.wordpress.com 25

Tinniam V Ganesh - http://gigadom.wordpress.com 26

Tinniam V Ganesh - http://gigadom.wordpress.com 27

Information element Tag

Carries the INAP/CAP operation. The component portion can carry

Tinniam V Ganesh - http://gigadom.wordpress.com 28

Tinniam V Ganesh - http://gigadom.wordpress.com 29

Tinniam V Ganesh - http://gigadom.wordpress.com 30

Tinniam V Ganesh - http://gigadom.wordpress.com 31

 ASN.1 Built in types

Tinniam V Ganesh - http://gigadom.wordpress.com 32

 RequestedInformationValue ::= CHOICE

Tinniam V Ganesh - http://gigadom.wordpress.com 33

Tags can be EXPLICIT or IMPLICIT

Tinniam V Ganesh - http://gigadom.wordpress.com 34

Class Bit 8 Bit

Primitive – (0) BOOLEAN, INTEGER, OCTET

Tinniam V Ganesh - http://gigadom.wordpress.com 35

Tinniam V Ganesh - http://gigadom.wordpress.com 36

Tinniam V Ganesh - http://gigadom.wordpress.com 37

Tinniam V Ganesh - http://gigadom.wordpress.com 38

 INAP/CAP Operations are transferred between entities

Tinniam V Ganesh - http://gigadom.wordpress.com 39