11 Chapter 11 CAP

Technical Manual Signaling & Protocols
HUAWEI MSOFTX3000 Mobile SoftSwitch Center
Table of Contents
Table of Contents
Chapter 11 CAP ........................................................................................................................... 11-1
11.1 Overview ........................................................................................................................ 11-1
11.1.1 Definition and Functions of the Interface ............................................................ 11-1
11.1.2 CAP Implementation in MSOFTX3000 ............................................................... 11-1
11.1.3 Structure of the Protocol Stack ........................................................................... 11-2
11.1.4 Message Structure .............................................................................................. 11-2
11.2 CAP Operations ............................................................................................................. 11-3
11.2.1 Call Related Operations ...................................................................................... 11-3
11.2.2 SMS Related Operations .................................................................................... 11-8
11.3 Basic Signaling Procedures........................................................................................... 11-9
Huawei Technologies Proprietary

i

Chapter 11 CAP
Chapter 11 CAP
11.1 Overview
11.1.1 Definition and Functions of the Interface
CAMEL Application Part (CAP) has evolved from the Intelligent Network Application
Protocol (INAP) of the wired Intelligent Network (IN). CAP enables signaling
interworking between GSM Service Switching Function (gsmSSF), GSM Specialized
Resource Function (gsmSRF) and GSM Service Control Function (gsmSCF) of radio
IN functional entities, for the purpose of supporting CAMEL services.
CAP protocol is one of the parts of the Signaling System No. 7. CAP is the user part
of the Transaction Capabilities Application Part (TCAP) in the SS7. CAP uses
structured/unstructured dialog capabilities provided by the TCAP protocol, and
realizes signaling interaction between functional entities.
CAP interface used in the UMTS is shown in Figure 11-1.
gsmSCF
CAP
CAP
CAP
gsmSSF
MAP
VLR
MSC Server
gsmSSF
MSC Server
gsmSRF
Figure 11-1 CAP interface supported in the UMTS network
11.1.2 CAP Implementation in MSOFTX3000

MSOFTX3000 functions as a MSC Server or GMSC Server in the UMTS R4
networking model. Service Switching Point (SSP) functional entity is built in
MSOFTX3000. The CAP protocol is used on the interface between MSOFTX3000
and a Service Control Point (SCP), as shown in Figure 11-2.

11-1

Chapter 11 CAP
CAP
CAP
MSC Server/SSP
(MSOFTX3000)
SCP
Figure 11-2 CAP protocol implementation in MSOFTX3000
11.1.3 Structure of the Protocol Stack

MSOFTX3000 provides two ways to transfer the CAP protocol: TDM based and IP
based. The TDM based way is to make use of the services provided by the MTP for
information transfer; the IP based way is to make use of the services provided by the
SIGTRAN protocol for transmission. The protocol stack is shown in Figure 11-3
CAP
CAP
(G)MSC Server/SSP
(MSOFTX3000)
SCP
CAP
CAP
TCAP
TCAP
SCCP
SCCP
MTP3
MTP3
MTP2
MTP2
MTP1
MTP1
(G)MSC Server/SSP
(MSOFTX3000)
SCP
CAP
CAP
TCAP
TCAP
SCCP
SCCP
M3UA
M3UA
SCTP
SCTP
IP
IP
MAC
MAC
(a) TDM based
(b) IP based
Figure 11-3 Structure of the CAP protocol stack
11.1.4 Message Structure

The structure of a CAP message is shown in Figure 11-4.
MTP
Message
SCCP
Message
TCAP
Message
CAP
Message
Figure 11-4 Position of CAP in a link message

In SS7, CAP messages are conveyed as the component part of TCAP messages.
CAP messages are coded in the Abstract Syntax Notation One (ASN.1) format. There
11-2

Chapter 11 CAP
is a one-to-one relationship between CAP message types and operation codes in the
TCAP component. When a message is transferred, an Invoke ID shall be allocated to
each initiated operation. The Invoke ID is mainly used to identify a particular operation
in a certain direction of the CAP dialog. By distinguishing the operation code, a
component can be translated to the corresponding CAP message. Message
translation between CAP and TCAP is implemented by the Functional Entity Access
Manager (FEAM).
11.2 CAP Operations

Interaction between functional entities across the mobile intelligent network depends
on a variety of operations defined by the CAP protocol. The CAP protocol defines
different operation sets in specific phases. MSOFTX3000 supports CAMEL Phase 3.
In this phase, the CAP protocol defines 32 CAP operations. 24 operations are call
related and others are Short Message Service (SMS) related. The functions of each
operation are briefly described as follows.
11.2.1 Call Related Operations

I. Initial DP
This operation is sent by the gsmSSF to the gsmSCF. After detection of a Detection
Point (DP) in the Basic Call State Module (BCSM), triggering of an intelligent call
procedure is required. The gsmSSF initiates the Initial DP. The "Initial DP" operation
contains various information needed by the gsmSCF, such as the calling number,
called number, calling subscriber location information, called subscriber location
information, subscriber status, etc.
II. RequestReportBCSMEvent
This operation is sent by the gsmSCF to the gsmSSF. According to the service
requirements, the gsmSCF can use the RequestReportBCSMEvent to request the
gsmSSF for a call related BCSM event. Upon reception of this operation, the gsmSSF
records the necessary call related BCSM event to be reported. When the BCSM
event is detected, a notification is sent to the gsmSCF by an "EventReportBCSM.
III. EventReportBCSM
This operation is sent by the gsmSSF to the gsmSCF. The gsmSSF has recorded the
reported event required in the RequestReportBCSMEvent message sent by the
gsmSCF. If the event is detected, a notification is sent to the gsmSCF by using an
EventReportBCSM. The gsmSCF will perform further handling according to the
event type.
11-3

Chapter 11 CAP
IV. CallInformationRequest
This operation is sent by the gsmSCF to the gsmSSF. After collection of call related
information is required in service operations and management, the gsmSCF can send
to the gsmSSF a CallInformationRequest message to collect the following call
related information:
z
Call Attempt Elapsed Time
Call Stop Time
Call Connected Elapsed Time
Release Cause
The information will be reported by the gsmSSF to the gsmSCF in the

CallInformationReport format when the call is released or the collection is
completed.
V. CallInformationReport
This operation is sent by the gsmSSF to the gsmSCF. When the gsmSSF receives
the CallInformationRequest from the gsmSCF, the gsmSSF sends the required
information in the CallInformationReport format to the gsmSCF at call release or
collection completion, so that the gsmSCF can collect the call related information.
If a gsmSSF is requested by the gsmSCF to report a call information event, the
gsmSSF contains the suspended call information report. If the gsmSSF reports the
call information event, the call information report suspension will be released.
VI. ApplyCharging
This operation is sent by the gsmSCF to the gsmSSF, and is used to control the
duration of the call. The ApplyCharging operation contains the maximum call
duration, the charging tariff change duration and other control parameter used in the
call. The actual call duration will be sent in an ApplyChargingReport by the gsmSSF
to indicate to the gsmSCF when the call reaches the maximum duration or the call is
released by either subscriber.
VII. ApplyChargingReport
This operation is sent by the gsmSSF to the gsmSCF. When the actual call duration
reaches the maximum duration specified in the corresponding ApplyCharging
operation or the call is released by either subscriber, the gsmSSF sends this
operation to inform the gsmSCF about the actual duration and other related
information of the call.

11-4

Chapter 11 CAP
VIII. SendChargingInformation
This operation is sent by the gsmSCF to the gsmSSF. This operation is used to send
e-parameters from the gsmSCF to the gsmSSF. SendChargingInformation contains
the Charge Advice Information (CAI) of the Advice of Charge (AoC). This CAI can be
used to replace the MSC generated CAI and inhibit any further generation of CAI.
IX. FurnishChargingInformation
requirements, the gsmSCF sends to the gsmSSF a FurnishChargingInformation
message to control output of the charging information at the gsmSSF.
X. Continue
This operation is sent by the gsmSCF to the gsmSSF. The gsmSCF makes use of the
Continue operation to instruct the gsmSSF to proceed with the suspended call
processing.
XI. Connect
requirements, the gsmSCF makes use of the Connect operation to modify some
parameters of the call, such as the called address, calling line identification
presentation, etc., so that the call can go on as per the service requirements.
XII. ReleaseCall
requirements, the gsmSCF initiates, at any time of the call, the ReleaseCall
operation to request the gsmSSF to release the corresponding call.
XIII. ConnectToResource
This operation is sent by the gsmSCF to the gsmSSF. When subscriber interaction is
required, the gsmSCF originates the ConnectToResource operation to instruct the
gsmSSF to connection the current call to the gsmSRF, preparing for the subsequent
subscriber interaction process.
XIV. PlayAnnouncement
This operation is sent by the gsmSCF to the assisting gsmSSF/gsmSRF. This
operation is used in the user interaction process of intelligent call proceeding. Via this
operation, the gsmSCF indicates to the gsmSRF to play an announcement to the user.

11-5

Chapter 11 CAP
The gsmSSF plays a role of signaling trunk during this process. Upon reception of the
operation, the gsmSSF will deliver it to the concerned gsmSRF.
XV. PromptAndCollectInformation
This operation is sent by the gsmSCF to the assisting gsmSSF/gsmSRF. This
operation is used in user interaction process of intelligent call proceeding. Via this
operation, the gsmSCF instructs the gsmSRF to play an announcement to the user, in
order to require the user to input relative information (e.g. account information and
user password). After collecting the information input by the user, the gsmSRF sends
it to the gsmSCF in the format of PromptAndCollectInformation. The gsmSSF
functions as the signaling trunk in the process. Upon reception of the operation, the
gsmSSF will deliver it to the controlled gsmSRF.
XVI. DisconnectForwardConnection
This operation is sent by the gsmSCF to the gsmSSF/gsmSRF. After user interaction
process
is
completed,
the
gsmSCF
uses
this
operation
to
request
the
gsmSSF/gsmSRF to clear the connection of the specialized resources for the call.
XVII. SpecializeResourceReport
This operation is sent by the gsmSRF to the gsmSCF. The gsmSRF uses this
operation to indicate to the gsmSCF that the corresponding PlayAnnouncement
operation has been completed.
XVIII. EstablishTemporaryConnection
This operation is sent by the gsmSCF to the initiating gsmSSF. Due to the
requirement by the service or management, the gsmSCF expects to utilize an assist
procedure in user interaction. In this case, the gsmSCF actively sends the
EstablishTemporaryConnection operation to the initiating gsmSSF, requesting the
initiating
gsmSSF
to
create
temporary
connection
with
the
assisting
gsmSSF/gsmSRF. Upon receipt of the operation, the initiating gsmSSF will initiate an
assist request to the corresponding network entity according to the address of the
assisting gsmSSF/gsmSRF contained in the operation, so as to enable the
appropriate assist procedure.
XIX. AssistRequestInstruction
This operation is sent by the assisting gsmSSF/gsmSRF to the gsmSCF. Upon
reception of the assist request from the initiating gsmSSF, the assisting
gsmSSF/gsmSRF sends this operation to the gsmSCF to start an assist procedure
and makes use of the assisting SSP or independent IP to achieve user interaction.

11-6

Chapter 11 CAP
XX. CallGap
This operation is sent by the gsmSCF to the gsmSSF. A gsmSSF may provision to the
gsmSCF a large volume of message traffic in a relatively short time. If the growing of
the traffic exceeds the allowable range, congestion may happen at the gsmSCF. This
will prolong the message responding time and increase the call failure rate. Therefore,
the gsmSCF can activate a CallGap operation at detecting the congestion,
requesting the gsmSSF to slow down the sending of service requests to it.
XXI. ResetTimer
This operation is sent by the gsmSCF to the gsmSSF. This operation is used by the
gsmSCF to refresh the status timer of the gsmSSF during the service proceeding, in
order to avoid status timeout at the gsmSSF.
XXII. Cancel
This operation is sent by the gsmSCF to the gsmSSF/gsmSRF, for the purpose of
canceling
previously
sent
PlayAnnouncement
operation
or
PromptAndCollectInformation operation. The gsmSSF/gsmSRF uses an error

indication Canceled to notify the gsmSCF of the successful cancellation of the
corresponding operation.
The
Cancel
operation
can
also
be
used
to
cancel
all
suspended
ApplyChargingReport or CallInformationReport operation, and all configured EDP

events.
XXIII. ActivityTest
This operation is originated by the gsmSCF to test the normality of the control
relationship of the gsmSCF on the gsmSSF/gsmSRF. Upon reception of the
ActivityTest operation indication, the gsmSSF/gsmSRF will return the ActivityTest"
outcome if the control relationship is normal; otherwise, the gsmSSF/gsmSRF will not
perform any handling on it. If an ActivityTest response is not received at the
gsmSCF, it indicates that the control relationship between the gsmSCF and the
gsmSSF/gsmSRF has failed in some way. Appropriate actions can be taken as per
the service requirements.
XXIV. ContinueWithArgument
This operation is sent by the gsmSCF to the gsmSSF. The gsmSCF uses the
ContinueWithArgument operation to instruct the gsmSSF to proceed with the
suspended call handling. Moreover, this operation also provides additional services
for the user (calling or called party).

11-7

Chapter 11 CAP
11.2.2 SMS Related Operations

I. InitialDPSMS
This operation is sent by the gsmSSF to the gsmSCF. When the gsmSSF determines
that triggering of a mobile initial SMS procedure is required, the gsmSSF originates
the corresponding procedure by sending the InitialDPSMS operation and requests
the gsmSCF to complete the mobile initial SMS procedure.
II. RequestReportSMSEvent
This operation is sent by the gsmSCF to the gsmSSF. The gsmSCF sends the
RequestReportSMSEvent operation to the gsmSSF, requesting the gsmSSF to
monitor the SMS related event (a success or failure in submitting the short message
to the SMSC). At detecting the SMS event, the gsmSSF notifies the gsmSCF of that
via an EventReportSMS operation.
III. EventReportSMS
This operation is sent by the gsmSSF to the gsmSCF. The gsmSSF has recorded the
reported event required in the RequestReportSMSEvent operation sent by the
gsmSCF. If the event is detected, a notification is sent to the gsmSCF by using an
EventReportSMS. The gsmSSF will perform further handling according to the event
type.
IV. ContinueSMS
This operation is sent by the gsmSCF to the gsmSSF. The gsmSCF uses the
ContinueSMS operation to instruct the gsmSSF to proceed with the suspended
short message handling.
V. FurnishChargingInformationSMS
This operation is sent by the gsmSCF to the gsmSSF, for the purpose of controlling
the output of charging information at the gsmSSF. The gsmSCF sends charge related
information
to
logical
short
message
record.
The
first
FurnishChargingInformationSMS operation leads to the generation of a logical short

message
record.
Receipt
of
subsequent
FurnishChargingInformationSMS
operations shall overwrite or add the contents of the logical short message record.
VI. ReleaseSMS
requirements, the gsmSCF uses the ReleaseSMS operation to request the gsmSSF

11-8

Chapter 11 CAP
to release the mobile initial SMS. This operation can be sent only when the controlling
relationship exists between the gsmSCF and the gsmSSF.
VII. ResetTimerSMS
This operation is sent by the gsmSCF to the gsmSSF. This operation is used by the
gsmSCF to refresh the status timer of the gsmSSF during the short message
proceeding, in order to avoid status timeout at the gsmSSF.
VIII. ConnectSMS
requirements, the gsmSCF can make use of the ConnectSMS operation to request
the gsmSSF to execute certain SMS handling: routing the short message to a
specified target address or affecting other SMS establishment information, etc.
11.3 Basic Signaling Procedures

MSOFTX3000 supports two ways to trigger an intelligent service: subscription
information trigger and number segment trigger. Both trigger signaling procedures are
illustrated in examples in the following part.
I. Procedure 1
Figure 11-5 depicts the call flow for a mobile prepaid subscriber in the
MSCa/VLR/SSP covering scope making a call to a PSTN subscriber, where the
O-CSI triggers the intelligent service.

11-9

MSCa/VLR/SSP
Chapter 11 CAP
SCPa
PSTN
O-CSI trigger
IDP
RRBE
Charging the
calling party
AC
Continue
IAI
ACM
ANC
.
.
.
ACR
ERB
RC
CAP messages
TUP messages
Figure 11-5 Flow of prepaid subscriber calling PSTN subscriber (O-CSI trigger)
1)
The MSCa/VLR/SSP receives the call. According to the calling partys

subscription information, the service is triggered in Originating CAMEL
Subscription Information (O-CSI) manner. The MSCa/VLR/SSP resident toll area
code is directly put in the Location Number parameter of the IDP message. Then
the MSCa/VLR/SSP sends the IDP message to the SCPa.
2)
After the SCPa receives the IDP message, the SCPa analyzes the calling partys
account before anything else is done. If the account is a valid one, determination
of the calling tariff rate is done according to the toll area code of the calling party
visitor location (Location Number parameter contained in the IDP message), and
the called toll area code. In addition to the determination, the balance in the
account is converted into conversation duration, and RRBE, AC and Continue
are sent to the MSCa/VLR/SSP.
3)
The MSCa/VLR/SSP performs the connection according to the called number in

the TUP message.
4)
At the end of the conversation, either party hooks on. The MSCa/VLR/SSP
reports the charging report and the onhook event.
II. Procedure 2
Figure 11-6 depicts the call flow for a mobile prepaid subscriber out of the
MSCa/VLR/SSP covering scope making a call to a PSTN subscriber, where the
calling party resident MSC/VLR accesses the MSCa/VLR/SSP in OVERLAY mode

11-10

Chapter 11 CAP
and the MSCa/VLR/SSP analyzes the calling number and triggers the intelligent
service based on the number segment.
MSCa/VLR/SSP
PSTN
SCPa
IAI
Number segment
trigger
IDP
Charging the
calling party
RRBE
AC
Continue
IAI
ACM
ANC
.
.
.
ACR
ERB
RC
CAP messages
TUP messages
Figure 11-6 Flow of prepaid subscriber calling PSTN subscriber (number segment
trigger)
1)
Upon receipt of the forwarded call, the MSCa/VLR/SSP analyzes the calling
number. If the calling party is a prepaid subscriber, the prefix at the front of the
called number is converted into the toll area code representing the actual
location of the calling party, and is put in the Location Number parameter of the
IDP message. The MSCa/VLR/SSP looks up the corresponding SCP address
based on the calling number segment, and then sends the IDP message to the
SCPa.
2)
After the SCPa receives the IDP message, the SCPa analyzes the calling partys
account before anything else is done. If the account is a valid one, the tariff rate
is determined according to the actual location (Location Number) of the calling
party and the called toll area code. The balance in the account is converted into
the conversation duration. RRBE, AC and Continue messages are sent to the
MSCa/VLR/SSP.
3)
The MSCa/VLR/SSP performs the connection according to the called number in

the TUP message.
4)
At the end of the conversation, either party hooks on. The MSCa/VLR/SSP
reports the charging report and the onhook event.

11-11

11 Chapter 11 CAP

Caricato da

Informazioni sul documento

Titolo originale

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

11 Chapter 11 CAP

Caricato da

Copyright:

Formati disponibili

Technical Manual Signaling & Protocols

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Huawei Technologies Proprietary

Technical Manual Signaling & Protocols

Figure 11-1 CAP interface supported in the UMTS network

11.1.2 CAP Implementation in MSOFTX3000

Huawei Technologies Proprietary

Technical Manual Signaling & Protocols

Figure 11-2 CAP protocol implementation in MSOFTX3000

11.1.3 Structure of the Protocol Stack

(a) TDM based

Figure 11-3 Structure of the CAP protocol stack

11.1.4 Message Structure

Figure 11-4 Position of CAP in a link message

Technical Manual Signaling & Protocols

11.2 CAP Operations

11.2.1 Call Related Operations

Technical Manual Signaling & Protocols

Call Attempt Elapsed Time

Call Stop Time

Call Connected Elapsed Time

The information will be reported by the gsmSSF to the gsmSCF in the

Huawei Technologies Proprietary

Technical Manual Signaling & Protocols

Huawei Technologies Proprietary

Technical Manual Signaling & Protocols

Huawei Technologies Proprietary

Technical Manual Signaling & Protocols

PromptAndCollectInformation operation. The gsmSSF/gsmSRF uses an error

ApplyChargingReport or CallInformationReport operation, and all configured EDP

Huawei Technologies Proprietary

Technical Manual Signaling & Protocols

11.2.2 SMS Related Operations

FurnishChargingInformationSMS operation leads to the generation of a logical short

Huawei Technologies Proprietary

Technical Manual Signaling & Protocols

11.3 Basic Signaling Procedures

Huawei Technologies Proprietary

Technical Manual Signaling & Protocols

The MSCa/VLR/SSP receives the call. According to the calling partys

The MSCa/VLR/SSP performs the connection according to the called number in

Huawei Technologies Proprietary

Technical Manual Signaling & Protocols

The MSCa/VLR/SSP performs the connection according to the called number in

Huawei Technologies Proprietary

Potrebbero piacerti anche