Intelligent networks, camel_services_and_applications_v1

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
Tinniam V Ganesh (ReleaseCall)
7. TC-Continue - 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

Intelligent networks, camel_services_and_applications_v1

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Intelligent networks, camel_services_and_applications_v1

Ähnlich wie Intelligent networks, camel_services_and_applications_v1 (20)

Mehr von Tinniam V Ganesh (TV)

Mehr von Tinniam V Ganesh (TV) (9)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Intelligent networks, camel_services_and_applications_v1