Intelligent networks, camel_services_and_applications_v1

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

1

Intelligent Networks, CAMEL protocol, Services and Applications

Tinniam.V. Ganesh

[email protected]


2 12/3/2008

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).


3 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.


4 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).


5 12/3/2008

Network Elements in an Intelligent Network


6 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


7 12/3/2008

Relationship between CCF and other entities


8 12/3/2008

BCSMBasic 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.


9 12/3/2008

BCSM model

BCSM ModelOverview 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.


10 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.

DPs indicate states in basic call and connection processing at which transfer of control from non-IN to IN service logic can occur. BCSM transitions indicate the normal flow of basic call/connection processing from one PIC to another. Entry events cause BCSM transitions into PICs. Exit events represent the result of PIC processing.

Point In Call (PIC)

DP

Transition


11 12/3/2008

Originating and Terminating half call

MSCgsmSSF/CCF

T(A-B)

B-PartyA-Party

O(A-B)

gsmSCF (1)

CAMEL relationship


12 12/3/2008

Originating BCSM (O-BCSM)Originating Basic Call State

Model


13 12/3/2008

T-BCSMTerminating- Basic Call State Model

T_Null

Terminating Call Handling

T_Exception

T_Active

Terminating_Attempt_Authorised

T_Answer

Basic Call transition

T_Busy

T_No_Answer

T_Abandon

T_Disconnect

T_active_failure

T_call_handling_failure


14 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.


15 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


16 12/3/2008

CAMEL Detection Point:

DP Type Description:

DP12 Terminating Attempt Authorised

TDP-R Indication that the Termination attempt is 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

T-BCSM Detection Points (DPs)


17 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.


18 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.


19 12/3/2008

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

Implicit disarming rules for DPs in O-BCSM


20 12/3/2008

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

Implicit disarming rules for DPs in T-BCSM


21 12/3/2008

Protocol layers

INAP/CAP

TCAP

SCCP

MTP[3-1]

INAP/CAP INAP/CAP

TCAP

SCCP

MTP[3-1]

INAP/CAP

SSP SCP


22 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


23 12/3/2008

SCCP parameters

SCCP message parameterspoint 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.

.


24 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.


25 12/3/2008

TCAPTCAP 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


26 12/3/2008

TCAP Sub Layers


27 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


28 12/3/2008

Component Portion

Information element

…

Information element

a) Component

Tag

Length

Contents

b) Information element

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


29 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


30 12/3/2008

Dialogue Portion

Used to establish the application context that will be used in the dialogue


31 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.


32 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 typesBOOLEAN, 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 ::= INTEGEREthernetAdapterNumber ::= OCTET STRING -- OCTETs represent 8 bit bytes


33 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


34 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 IMPLICITIMPLICIT tags – There is no need to transfer the data type. The tag alone would enable

to discriminateEXPLICIT tags – the data type needs to be transferredIf an IMPLICIT tag is not specified then the tag by default is EXPLICITIn the IMPLICIT tag is used in ASN.1 module definitions then all tags in the module are

IMPLICITA user-defined has a class and a number within square brackets [] as shown in the

previous page e.g callAttemptElapsedTimeValue [0] INTEGER (0..255)


35 12/3/2008

Basic Encoding Rules (BER)

Provide the conventions of actual data transfer –n the form of Type, Length, Value

Class Bit 8 Bit 7

UNIVERSAL 0 0

APPLICATION 0 1

CONTEXT-SPECIFIC

1 0

PRIVATE 1 1

Class P/C Tag Number

To network

Primitive – (0) BOOLEAN, INTEGER, OCTET STRING, NULL, ENUMERATED, OBJECT IDENTIFIER

Constructed – (1) SEQUENCE, SEQUENCE OF, CHOICE

T L

T L V T L V

Value

Type


36 12/3/2008

Universal Tags

UNIVERSAL Class TagsUNIVERSAL 1 BOOLEANUNIVERSAL 2 INTEGERUNIVERSAL 3 BIT STRINGUNIVERSAL 4 OCTET STRINGUNIVERSAL 5 NULLUNIVERSAL 6 OBJECT IDENTIFIERUNIVERSAL 10 ENUMERATEDUNIVERSAL 16 SEQUENCE and SEQUENCE OFUNIVERSAL 22 IA5Stringo o o


37 12/3/2008

ASN.1 Examples A :: [UNIVERSAL 1] BOOLEANIf A is TRUE then0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1Type 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 32B :: [2] IMPLICIT INTEGER1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 1 0 – CONTEXT-SPECIFIC 0 - PRIMITIVE 0 0 0 1 0 – Tag

Number 0000 0001 – Length0010 0000 - Value = 32


38 12/3/2008

Eg. ASN.1

Assume all parameters are context-specificWms_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 02name ------------- r a c k 1 –> 81 05 72 61 63 6b 31descr --------------- l e v e l 2 –> 82 07 6c 65 76 65 6c 20 32location ------------- 0 3 –> 83 02 30 33


39 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.


40 12/3/2008

INAP/CAP operationxyz OPERATIONARGUMENT {Parameter1, Parameter2,...}RESULT {Parameter1, Parameter2,...}LINKED {operation3, operation4,...}ERRORS {error1, error2....}

error1 ERRORPARAMETER {Parameter6, Parameter7,...} etc

to peer

to peer

to peer

OperationsResultsErrors

INVOKERETURN RESULTRETURN ERRORREJECT

BEGINCONTINUEENDABORTUNIDIRECTIONAL

INAP User ASE's

TCAP ASE

CONNECTIONLESS SCCP

COMPONENT SUB-LAYER

TRANSACTION SUB-LAYER


41 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.


42 12/3/2008

Connect Operation

connect {PARAMETERS-BOUND : bound} OPERATION ::= {ARGUMENT ConnectArg {bound}RETURN RESULT FALSEERRORS {missingParameter |

parameterOutOfRange | systemFailure |taskRefused |unexpectedComponentSequence |unexpectedDataValue |unexpectedParameter}

CODE opcode-connect}


43 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,...


44 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


45 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

PromptAndCollectUserInformation

SCP – SSP /IP Play an announcement to the user and also collect digits entered

SpecializedResourceReport IP/SSP -> SCP Sent after completion of the announcement

Cancel SCP -> SSP/IP Stop playing announcement/tone

DisconnectForwardConnection

SCP -> SSP SCP requests the SSP/IP to disconnect the connection to the IP


46 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


47 12/3/2008

INAP/CAMELNon-call related operations

Operation Direction DescriptionActivateServiceFiltering 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.

Operation Direction Description

ActivityTest SCP -> SSP Tests SS7 link between SCP and SSP

Link Test Operations


48 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


49 12/3/2008

CAMEL network

HLR

GMSC

gsmSCF

MSC

Forwarded leg

MSIncoming line

Visited NetworkInterrogating Network

Home Network

gsmSSFVLR

Roaming leg

CAPCAP

MAP

MAP MAP

gsmSSF

gsmSRFHome/Interrogating/Visited Network

CAP

MO call - Outgoing leg(or Forwarding leg)

MAP


50 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.


51 12/3/2008

SSF state machine


52 12/3/2008

State transitions of the SSF 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

CIRP No change* No change* No change*No change*

ETC WETC

DFC WFI

SRR No change

ACR No change* No change* No change*No change*

* Moves to Idle if no other reports are pending and there are no EDPs armed

state


53 12/3/2008

SCF state machine


54 12/3/2008

SCF state machine (contd.)


55 12/3/2008

Freephone call

1. IAM

CCF

(O-BCSM)

SSF

SCP

2. callEventNotify()

3.InitialDP

4Connect

5. routeRequest()

6.IAM

7.ACM

8.ACM

9.ANM

10.ANM11.REL

12.REL


56 12/3/2008

Freephone callTC – Begin

Application Context

Origination Transaction ID

Component-Invoke

InitialDP (ASN.1 encoded)

TC – Continue

Application Context

Origination Transaction ID

Destination Transaction ID

Component -Invoke

Connect (ASN.1 encoded)

SSP -> SCP

SCP -> SSP


57 12/3/2008

Scenario 1 – Follow-on, follow-me1. 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.


58 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.


59 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.


60 12/3/2008

Services – Follow–on, Follow-me

2. TC-Continue (RequestReportBCSM (4r,5r,6r,7n,9br,9ar), Connect(dra) )

7. TC-Continue (ReleaseCall)

6. TC-Continue (EventReportBCSM 9br)

5. TC-Continue (EventReportBCSM 7n)

1. TC-Begin (InitialDP(sk))

3. TC-Continue (EventReportBCSM 4r)

4. TC-Continue (RequestReportBCSM (4r,5r,6r,7n,9br,9ar), Connect)

Conversation

DP -3 O - Analyzed Info

DP -7 O- Active

DP – 9b O- Disconnect

SCPSSP

Implicity disarm DPs on Leg2

WFI

Monitoring

WFI

Monitoring

WFI

Monitoring

Idle


61 12/3/2008

Services – Call with Announcement1. 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 sent8. SCP sends a ReleaseCall to release the call


62 12/3/2008

2. TC-Continue (CTR, PlayAnnouncement )

3. TC-Continue (EventReportBCSM 9br)

36 TC-Continue (EventReportBCSM 7n)

1. TC-Begin (InitialDP)

5. TC-Continue (RequestReportBCSM (4r,5r,6r,7n,9br,9ar), Connect)

Idle

Conversation


DP -7 O- ActiveDP – 9b O- Disconnect

SCPSSP

Implicity disarm DPs on Leg2

Connect to MediaResource and Play Announcement

Announcement Complete 3. TC- Continue (SpecializedResourceReport)

Integrated MediaResource Function

Services - Call with Announcement

4. TC-Continue (DisconnectForwardConnection)

8. TC-Continue ReleaseCall

7. TC-Continue EDP-9bR

WEUI

WEUI

WFI

Monitoring

WFI

WFI

Idle


63 12/3/2008

7. TC-Continue (ACR)


1. TC-Begin (InitialDP(sk))


5. TC-Continue (RequestReportBCSM (4r,5r,6r,7n,9br,9ar), ACRq, Connect)

Conversation


DP -7 O- Active

SCPSSP

WFI

Monitoring

Monitoring

Idle

2. TC-Continue (RequestReportBCSM (4r,5r,6r,7n,9br,9ar), ACRq, Connect)

4. TC-Continue (ACR, ERB 9br)

WFI

Warning tone applied

Timeout

8. TC-Abort

Prepaid Service


64 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


65 12/3/2008

Thank You !!!

Tinniam V Ganesh

[email protected]

Read my blogs: http://gigadom.wordpress.com/

http://savvydom.wordpress.com/

Intelligent networks, camel_services_and_applications_v1

Technology

Transcript of Intelligent networks, camel_services_and_applications_v1