intro to in-camel.ppt
TRANSCRIPT
Slide 1Introduction to IN/CAMEL
Contents
Evolution of Call Handling
Routing Table
Should be sent to VSNL (international calls)
Should be completed within the network
Routing table
Route selection
Trunk selection
Circuit selection
Call Routing – Logical View
Call Model
Value Added Services: ISUP Solution
Simple routing table based decisions do not suffice
Routing decisions need to be externalized
Channel dissociated signaling (ISUP loopback)
Real-time integration with VAS
Service node based pre-paid
Introduction to IN/CAMEL
Service node - intrusive
ISUP Loopback – Logical View
ISUP – Pros and Cons
Wide acceptance
Voice trunks are expensive
Difficult to have centralized application server within a network
Requires ISUP circuits from every switch
Requires reconfiguration of every switch
Impractical to use across networks for value added applications
Works on the principle of Hop-by-Hop
HPMN
VPMN
Switch
Application
ISUP?
Introducing IN
Fundamental requirements
Application should be notified of call progress
Application should be able to interact with call participants for better service
Application does not need voice trunks all the time
Application can be hosted on one or more computers in a network
Application can be in a different network
SCCP provides more suitable addressing mechanisms
TCAP provides context handling
Introduction to IN/CAMEL
The Essence of IN
Traditional Way Intelligent Way
Introduce a new Feature
IN Basics
Service Switching Point (SSP) uses the help of Service Control Point (SCP) for making call handling decisions
A switch is an SSP
An application, e.g. a pre-paid system, is an SCP
Works on top of SCCP/TCAP
Peer-to-peer messages
No voice trunks involved
Reduces cost of solution
Configuration done on every switch (SSP)
Pre-defined points in call model where an IN message can be exchanged
Known as Detection Points (DP)
MO and MT call models are handled differently
Introduction to IN/CAMEL
Call Routing and IN
Detection Points
The provision of Detection Points (DPs) is required in the ISUP basic call handling in order to access IN functionality and to allow IN service logic influence the processing of IN calls. The detection points (DPs) indicate points in call (PICs) at which transfer of control can occur.
DP #
Introduction to IN/CAMEL
Mid call is a call waiting scenario, Abandon – MO call disconnected without speaking.
Roamware Proprietary and Confidential
IN Message Sequence Chart
Call initiated. SSP needs to consult SCP for call control decision.
SCP asks SSP to keep it informed of call status events.
SCP asks SSP to continue processing the call normally.
SSP says that the B party did not answer the call.
SCP asks SSP to keep it informed of call status events.
SCP asks SSP to connect the call to an alternate number.
SSP informs SCP that the B party has answered the call.
SSP informs SCP that B party has hung up the phone.
Introduction to IN/CAMEL
IN: Pros and Cons
Very lightweight in terms of signaling
Does not necessitate voice trunks for application invocation
Reduced cost of solution
Can use IVR (Intelligent Peripheral or IP) for interactive applications
Enables centralized applications
Enables communication across operators
Cons
Too many vendor specific protocols/versions
Made communication across operators impossible
Requires configuration on every SSP (or switch)
High OAMP overhead
Introduction to IN/CAMEL
Introducing CAMEL
Builds on the concepts of IN
Works on SCCP/TCAP
Standardized in the whole GSM world
No vendor specific specification/version
Does not require configuration on every SSP for MO call model
Imports CAMEL Subscription Information (CSI) from HLR
Evolving protocol
Introduction to IN/CAMEL
MO Call Handling with CAMEL
CSI for MO activity (o-CSI) are transferred to VLR in MAP-UPDATE-LOCATION transaction from the HLR
Calls are supported in all phases
Call forwarding supported in CAMEL phase 2
SMS supported in CAMEL phase 3
SSP uses this CSI to consult SCP during MO activities
No static configuration required on SSP for MO activities
Enables multiple SSP-s in a network very easily
CSI contains the Global Title of the SCP
Can contain HPMN global title
Can work across operators
MO Call Handling with CAMEL – Visualization
Update Location Txn
(Includes o-CSI data)
MT Call Handling with CAMEL
GMSC is configured to obtain CSI for MT calls (t-CSI) from HLR
SSP uses the CSI data to interact with the SCP
No static configuration required in the SSP
Makes it easy to roll out services
MT calls are usually handled in the HPMN only
No need for interaction between operators for MT calls
Introduction to IN/CAMEL
Roamware Proprietary and Confidential
MT Call Handling with CAMEL – Visualization
HLR
SCP
HPMN
CAMEL: Pros and Cons
Very lightweight in terms of signaling
Does not necessitate voice trunks for application invocation
Reduced cost of solution
Can use IVR (Intelligent Peripheral or IP) for interactive applications
Enables centralized applications
Enables communication across operators
Pre-paid roaming with MO service has been possible because of CAMEL
Cons
Adoption is very slow
CAMEL phase 3 has been adopted by a handful of operators
Introduction to IN/CAMEL
Roamware Proprietary and Confidential
Networks Today
Questions?
ETSI INAP Specification: Q12*
Thank you!
Contents
Evolution of Call Handling
Routing Table
Should be sent to VSNL (international calls)
Should be completed within the network
Routing table
Route selection
Trunk selection
Circuit selection
Call Routing – Logical View
Call Model
Value Added Services: ISUP Solution
Simple routing table based decisions do not suffice
Routing decisions need to be externalized
Channel dissociated signaling (ISUP loopback)
Real-time integration with VAS
Service node based pre-paid
Introduction to IN/CAMEL
Service node - intrusive
ISUP Loopback – Logical View
ISUP – Pros and Cons
Wide acceptance
Voice trunks are expensive
Difficult to have centralized application server within a network
Requires ISUP circuits from every switch
Requires reconfiguration of every switch
Impractical to use across networks for value added applications
Works on the principle of Hop-by-Hop
HPMN
VPMN
Switch
Application
ISUP?
Introducing IN
Fundamental requirements
Application should be notified of call progress
Application should be able to interact with call participants for better service
Application does not need voice trunks all the time
Application can be hosted on one or more computers in a network
Application can be in a different network
SCCP provides more suitable addressing mechanisms
TCAP provides context handling
Introduction to IN/CAMEL
The Essence of IN
Traditional Way Intelligent Way
Introduce a new Feature
IN Basics
Service Switching Point (SSP) uses the help of Service Control Point (SCP) for making call handling decisions
A switch is an SSP
An application, e.g. a pre-paid system, is an SCP
Works on top of SCCP/TCAP
Peer-to-peer messages
No voice trunks involved
Reduces cost of solution
Configuration done on every switch (SSP)
Pre-defined points in call model where an IN message can be exchanged
Known as Detection Points (DP)
MO and MT call models are handled differently
Introduction to IN/CAMEL
Call Routing and IN
Detection Points
The provision of Detection Points (DPs) is required in the ISUP basic call handling in order to access IN functionality and to allow IN service logic influence the processing of IN calls. The detection points (DPs) indicate points in call (PICs) at which transfer of control can occur.
DP #
Introduction to IN/CAMEL
Mid call is a call waiting scenario, Abandon – MO call disconnected without speaking.
Roamware Proprietary and Confidential
IN Message Sequence Chart
Call initiated. SSP needs to consult SCP for call control decision.
SCP asks SSP to keep it informed of call status events.
SCP asks SSP to continue processing the call normally.
SSP says that the B party did not answer the call.
SCP asks SSP to keep it informed of call status events.
SCP asks SSP to connect the call to an alternate number.
SSP informs SCP that the B party has answered the call.
SSP informs SCP that B party has hung up the phone.
Introduction to IN/CAMEL
IN: Pros and Cons
Very lightweight in terms of signaling
Does not necessitate voice trunks for application invocation
Reduced cost of solution
Can use IVR (Intelligent Peripheral or IP) for interactive applications
Enables centralized applications
Enables communication across operators
Cons
Too many vendor specific protocols/versions
Made communication across operators impossible
Requires configuration on every SSP (or switch)
High OAMP overhead
Introduction to IN/CAMEL
Introducing CAMEL
Builds on the concepts of IN
Works on SCCP/TCAP
Standardized in the whole GSM world
No vendor specific specification/version
Does not require configuration on every SSP for MO call model
Imports CAMEL Subscription Information (CSI) from HLR
Evolving protocol
Introduction to IN/CAMEL
MO Call Handling with CAMEL
CSI for MO activity (o-CSI) are transferred to VLR in MAP-UPDATE-LOCATION transaction from the HLR
Calls are supported in all phases
Call forwarding supported in CAMEL phase 2
SMS supported in CAMEL phase 3
SSP uses this CSI to consult SCP during MO activities
No static configuration required on SSP for MO activities
Enables multiple SSP-s in a network very easily
CSI contains the Global Title of the SCP
Can contain HPMN global title
Can work across operators
MO Call Handling with CAMEL – Visualization
Update Location Txn
(Includes o-CSI data)
MT Call Handling with CAMEL
GMSC is configured to obtain CSI for MT calls (t-CSI) from HLR
SSP uses the CSI data to interact with the SCP
No static configuration required in the SSP
Makes it easy to roll out services
MT calls are usually handled in the HPMN only
No need for interaction between operators for MT calls
Introduction to IN/CAMEL
Roamware Proprietary and Confidential
MT Call Handling with CAMEL – Visualization
HLR
SCP
HPMN
CAMEL: Pros and Cons
Very lightweight in terms of signaling
Does not necessitate voice trunks for application invocation
Reduced cost of solution
Can use IVR (Intelligent Peripheral or IP) for interactive applications
Enables centralized applications
Enables communication across operators
Pre-paid roaming with MO service has been possible because of CAMEL
Cons
Adoption is very slow
CAMEL phase 3 has been adopted by a handful of operators
Introduction to IN/CAMEL
Roamware Proprietary and Confidential
Networks Today
Questions?
ETSI INAP Specification: Q12*
Thank you!