Ssfam

Page 1
In this course module we will work with SSF-AM principples and Rules. Further we will
try to get a picture of how the SSF-STD and SSFAM are distinguished from each other.
After this module you should gain :
- Knowledge about differences between SSF-STD and SSF-AM in general.
- Knowledge about the functionalities blocks, their interfaces, their positions and
functions in an IN call within AM-environment.
- Knowledge about Implementation models in SSF-AM.
- Triggering and Invocation of SSFAM.
- IN Call procession in general.
MEMOID : LMDKCTN. Date : 03/11/98
DOCNAME: IN-SSF-Introduction Course DOCNO : 6/LMD/TX/XC-98:043 Uen DOCREV : REV. A.
Product Unit Network Services & Control NS&C, Product Provisioning
1
SSFAM SSFAM
SSF-Introduction Course
Module 2
Page 2
2
General Differences from SSF-STD General Differences from SSF-STD
In general the SSFAM and SSF-STD are aliked each other alot.
They have :
The same Operation sending/receiving handling principple.
Same Events Report and Monitoring procedures.
Almost the same Invocation method.

BUT,
The SSFAM differs from SSF-STD at the following points :
Support ETSI-CS1 + in AM environment .
Have the opportunity to support Mobil Application.
Two Connection Point Views :
- Connection Point view.
- Associated (Connection) Point view.
Multiple Call Parties (max 30) handlings within one SSFAM-call.
User Interaction both on Connection Point and on specific call leg.
Have some extra Event Detection Points in CLSM models.
Different Functional Blocks structure.
The Data Base Subsystem tables (DBS) are used for Triggering.
Page 3
SHSIM : Simulation Function.
SHPM : Protocol Handling.
SHTCU: SSF Transaction Capabilities ser (CCITT TCAP...)
SHTTM : TASI Triggering Manager.
SHTRI : SSF TASI ROS Interfaces.
SHTDM : SSF TASI Dialogue Manager.
SHTD1-8 : SSF Trigger Data Owner 1-8.
SHEXT : SSF Extension Value Mapping.
SHBCA : SSF Basic Call Administration.
SHCM : SSF Call and Connection Manager.
SHMM : SSF Message Manager.
SHCLSM : SSF CLSM manager.
SHRDO : SSF Route Data Owner.
SHEC : SSF Event Manager.
SHCC : SSF Call Control.
SHCFH : SSF Clearing and Fault Handling.
SHOPSRF : SSF Operation Handling - SRF.
SHINSRF : SSF SRF internal.
SHMCS : SSF Mass Call Service
SHSF/SFA, SHCL/CLA, SHCG/CGA : ASF, CL, CG handling.
3
BASIC CALL
FUNCTION
SHBCA
SHRDO
SHCM
SHMM
SHCLSM
CALL MON
& CONTROL
SHEC
SHCC
SHCFH
CHARGING
FUNCTION
SHCHM
SHCA
MASS CALL
FUNCT.
SHMCS
SHSF/SFA
SHCL/CLA
SHCG/CGA
SCF
ROS : SHSIM, SHPM1-2, SHTCU1-3
TASI : SHTTM, SHTDM, SHTRI, SHEXT, SHTD1-8
SPECIAL.
RESOURSE
FUNCT.
SHOPSRF
SHINSRF
IN3- SSFAM Function blocks structure IN3- SSFAM Function blocks structure
Page 4
4
SSFAM SSFAM
Structures and Structures and Principples Principples
Page 5
Connection Point View 1 : This is an Incoming two party IN call.
Connection Point View 2 : This is an Incoming multiple party IN call.
Connection Point View 3 : This is an Outgoing multiple party IN call.
Connection Point View 4 : This is an Incoming multiple party IN call, user interaction is
connected to connection point. Announcement is played to all call parties.
Connection Point View 5 : This is an Incoming two party IN call, user interaction is
connected to outgoing leg B only. Incoming leg A is put on hold, only ougoing leg B can
hear announcement. After announcement is ended the leg B can be re-connected to
connection point again.
Connection Point View 6 : This is an Incoming two party IN call, user interaction is
connected to incoming leg A only. Outgoing leg B is put on hold, only incoming leg A
can hear announcement. After announcement is ended the leg A can be re-connected to
connection point again.
5
Connection Point view Connection Point view
: up to 29
outgoing
legs
: up to 30
outgoing
legs
A
B
A
B1
B2
: up to 29
outgoing
legs
Annc
Annc
Annc
A
B
A
B1
B2
B1
B2
1
2
3
4
5
6
A
B
Page 6
Interface (1) : AM-AM communication in order to perform Operational and maintenant
Commands.
Interface (2) : AM-AM communication (administrative). To coordinate about the
existence of an IN triggering Table between XSS and SSFAM.
Interface (3) : AM-AM communication (charging related).
Interface (4) : AM-AM communication (traffic related).
Interface (5) : Application Platform Services Interface (APSI).
Abbreviations :
- FOAM : Formatting & Output AM.
- RMP : Resourse Module Platform.
- SYSOMAM : System Operational & Maintenance.
- APSI : Application Platform Service Interface.
6
SSFAM - SSFAM - Architechture Architechture - External Interfaces - External Interfaces
SYSOMAM
SSFAM FOAM
RMP
APZ
XSS
APSI (5)
(1)
(2)
(3) (4)
Page 7
Interface (1) : ROS -TASI : dialogue control.
Interface (2) : BC - TASI : Triggering.
Interface (3->6) : TASI - CM-CC/CH/SRF/MCS : reception and sending of INAP
operations (in areas : Call control, Charging, Specialized Resource, and Mass Call).
Interface (7->10) : CM-CC - CH/SRF/MCS : Call related Event information from CM-
CC to other operation owner blocks when requested.
Interface (11) : SRF - MCS : User interface performing for Mass call function.
Interface (12) : BC - CM-CC : Call related Event information from BC to CM-CC. This
interface is used when traffical Detection Points are to be detected and reported. The
interface is also used when traffical message must be transferred through SSFAM.
Interface (13->15) : BC - CH/SRF/MCS : These interfaces are used when the operation
owner blocks have to read or writte parameters value from or to traffical messages that
are transferred or generated by SSFAM.
Abbreviations:
- TASI : Triggering And Invocation of SCF.
- ROS : Remote Operation Handling.
7
SSFAM - SSFAM - Architechture Architechture - Internal Interfaces - Internal Interfaces
ROS
TASI
BC
CM-CC
CH SRF MCS
SSFTP
(1)
(2) (3) (4) (5) (6)
(7)
(8)
(9)
(10)
(11)
(12) (13) (14)
SCF
(15)
Page 8
The SSF FSM (Finite State Machine) is always associated with one and only one call-
related SSF instance.
The purpose of SSF session FSM is to control the interaction between dialogues in half
of the call that the session pertains to, as the SSF-AM supports multiple active dialogues
within one half call.
In order to supporting and controlling the multiple dialogues / multiple call legs the SSF
session have the following rules :
-The Call Party reference number allocated to Calling Party in a call (initiated by ICA,
IDP or ARI operations) is always 1.
- The Call Party reference number allocated to a Called Party created in a call as a result
of a transit call through the exchange or due to receipt of Connect or Continue operation,
is always 2.
- The additional call leg that is created by ICA operation in a call with Calling Party is
already present, will have the leg reference number in the range from 3 to 30.
- Those operations that related to a leg which is not existed at reception of operation
(e.g Apply Charging, CallInformationRequest, SendChargingInfo...) will be allocated to
Call Party reference number 2. And the LegID value received becomes the Reserved
legID. There is allowed only one reserved LegID value at any one time.
Note that in the Session FSM above :
- Creation of a dialogue to an SCF (SLP) is only allowed when the SSF session FSM is
in state Seized.
- The Trigger Detection Points (TDPs) are only armed in the Call Monitoring Function.
- And the Re-triggering within a call ( or half call) is only allowed when SSF Session
has been created in direct response to an event in the call.
8
SSFAM - Implementation Session - FSM SSFAM - Implementation Session - FSM
IDLE
SEIZED
SUPPRESS
TRIGGERING
SSF_seized_by_Call
Call_release
InitialDP_sent
Call_release
Controlling_dialogue_
goes_to_monitoring
ICA_rec
Page 9
The SRF FSM represents the states of Specialized Resource Function.
The SRF is first connected to the call and then announcement is ordered. The SRF may
either disconnnect itself from the call or be disconnected by a
DisconnectForwardConnection Operation from SCF.
9
SSFAM - SRF - User Interaction - FSM SSFAM - SRF - User Interaction - FSM
IDLE
CONNECTED
USER
INTERACTION
Connect_request
SRF_sanity_timeout
Disconnect_forward_connection
SRF_sanity_timeout
SRF_initiated_disconect
Disconnect_forward_connection
Play_announcement
Promt_and_collect
Page 10
The SSF Mass Call FSM is to control the performance of Activate Service Filtering, Call
Gap and Call Limit operation in SSF. It is slightly different with SSF-STD (CS1) models,
in which it has a DORMANT state. This is to allow for the inclussion of a start timer in
CS1+ version of operations (ASF,CG..).
10
SSFAM - Mass Call - FSM SSFAM - Mass Call - FSM
IDLE
DORMANT
ACTIVE
ActivateServiceFiltering_not_delayed
CallGap_not_delayed
CallLimit_not_delayed
ActivateServiceFiltering_delayed
CallGap_delayed
CallLimit_delayed
Tssme_timer_expired
ActivateServiceFiltering_not_delayed
CallGap_not_delayed
CallLimit_not_delayed
Page 11
This picture describer the State Machine that an IN call through SSF-AM can have.
The states HandOver and Handover_Ending are included so that we cover the
Conditional Triggering and execution of Handover operation from SCF which is one of
the differences between SSF-STD and SSF-AM.
The operation Handover can be received in SSF in two different cases :
- Handover is received in response to Conditional Triggering. In this case the data
contained in operation is discarded and the triggering function is requested to build
another IDP (using unconditional Trigger Invoked Network signalling data) and send it to
the indicated SCF (by Service Key). This procedure is again be mentioned in chapter
Triggering.
- Handover is not received in response to Conditional Triggering. In this case the SSF
will use the Called Party Address in Handover operation to establish a new dialogue
toward SCF. The data received in Handover will be used to build IDP operation. Both
dialogues toward SCFs must be kept open by SSF until the subsequent dialogue is
established. If the Handover is not successful performed an Error must be sent to the
original SCF.
The state Idle : The dialogue is inactive.
The state Control : The dialogue is capable of transferring control of the call to SCF, and
thus accepting operations for the Call Control from SCF. Only one call-related dialogue
present within a Session can be in this state at any one time. The Session FSM is notified
when a dialogue within the Session transits from Control to monitoring.
The state Monitoring : The dialogue is not capable of transferring control of the call to
SCF. The SSF in this state cannot accept operations that requesting such transfer, or
operations that affects control of the call. Though the SSF can accept some certain
charging operations, and the requests to cancel EDPs and reports. Note that no APV can
be presented within the dialogue when SSF is in this state.
11
SSFAM - Call View - FSM SSFAM - Call View - FSM
HANDOVER
ENDING
HANDOVER
IDLE
MONITOR
CONTROL
Dialogue_end
Handover_received
Handover_fail
No_EDP_R
No_EDP_N
Dialogue_end
IDP_sent
ICA_received
ARI_sent
Handover_successful
Handover_successful
Dialogue_end
Page 12
The purpose of Connection Point View (CPV) is to describer the behaviour of the
connection point. It also determines when the processing in the call is to be continued or
suspended.
The CPV has associated with it a queue and an FSM. The CPV notifies the Dialogue
whenever a change in the state of FSM is occurred. All operations that are received in the
dialogue specific for the CPV will be stored in the queue in the order the operations
arrived and will be executed sequentially.
It is possible that a Call Party can be released while the view is in state Waiting For
Instruction (WFI). If this is the case and the view has appropriate Abandon or Disconnect
EDP-R armed, then the event will be reported to SCF by ERB operation, and the call is
released if none other events is pending.
A counter is existing to keep track of the sending ERB operations from SSF, and the
CPV is only transitting to Processing state when the corresponding combination of
Connect, Continue or CollectInformation operations is executed successfully by the view.
It means the number of these operations combined must be equal the number of EDP-Rs
sent. Note that the counter is set to one when CPV is created.
The states of CPV FSM are defined as follows :
- IDLE : The CPV is vacant.
- WFI : the control of the call resides with the SLP running on SCF. The processing of
all ISUP mesage events except Release is suspended.
- WFI (SRF_INT or ASSIST_INT) : The control of the call resides with the SLP
running on the SCF. An co-located SRF, Intelligent Pheripheral (IP) or Assisting SSF is
connected to the Connection Point. The processing of all ISUP message except Release is
suspended.
- Processing : The control of the call resides with the SSF. ISUP message events
proceeding.
- Processing (SRF_INT or ASSIST_INT) : The control of the call resides with SSF,
ISUP messages proceeding. An User Interaction is in progress with connection to either a
co-located SRF, IP or Assisting SSF.
12
SSFAM - Connection Point View - FSM SSFAM - Connection Point View - FSM
WFI
SRF_INT
PROCESSING
SRF_INT
WFI PROCESSING
WFI
ASSIST_INT
PROCESSING
ASSIST_INT
CUE_exec_CS1+
EDP-R_encount
DFC_exec
CTR_exec
ETC_exec
DFC_exec
Ass_path_disc
CI_exec
CON_exec
CUE_exec
EDP-R_encount
CUE_exec
EDP-R_encount
CTR_exec
DFC_exec
SRF_init_disc
ETC_exec
DFC_exec
Ass_path_disc
IDLE
Dialogue_rel
Call_rel
Dialogue_create
Dialogue_rel
Call_rel
Dialogue_rel
Call_rel
Page 13
An Associated Point is a physical switch location to which a call party that not connected
to the Connection Point is attached. Such a party is said to be on hold. An Associated
Point contains only one call party.
The Associated Point View is to describer the behaviour of an Associated Point.It
determines when the processing in a call is to be continued or suspended.
The APV has associated with it a Finite State Machine (APV - FSM).
In APV only the ReleaseCallPartyConnection operation that can initiate buffering on the
view. Operations that receive while the view is buffering are not accepted for execution
and are discarded or have error returned for them to SCF.
It is possible that a Call Party can be released while the view is in state WFI. If this is the
case and the view has appropriate Abandon or Disconnect EDP-R armed, then the event
will be reported to SCF by ERB operation, and the call is released if none other event is
pending.
A counter is existing to keep track of the sending ERB operations from SSF on those
armed EDP-Rs, and the APV is only transitting to Processing state when the
corresponding number of Continue operations is executed successfully by the view. It
means the number of these Continue operations must be equal the number of EDP-Rs
sent. Note that the counter is set to one when APV is created.
13
SSFAM - Association Point View - FSM SSFAM - Association Point View - FSM
WFI
SRF_INT
PROCESSING
SRF_INT
WFI
PROCESSING
WFI
ASSIST_INT
PROCESSING
ASSIST_INT
CUE_exec
EDP-R_encountered
DFC_exec
CTR_exec
ETC_exec
DFC_exec
Ass_path_disc
CUE_exec
EDP-R_encountered
CUE_exec
EDP-R_encountered
CTR_exec
DFC_exec
SRF_init_disc
ETC_exec
DFC_exec
Ass_path_disc
IDLE
Dialogue_rel
Call_rel
Dialogue_rel
Call_rel
Dialogue_create
Page 14
14
SSFAM - Triggering SSFAM - Triggering
Page 15
15
SSFAM - Triggering Capabilities SSFAM - Triggering Capabilities
Unconditional Triggering supported.
Conditional triggering supported via co-located SCF.
Initiating SSF and Assisting SSF supported via same triggering
mechanism.
Restriction of capabilities applied at time of data entry.
Page 16
The Data Base Subsystem (DBS) is contained of the following tables :
SHIST : SSF IN Service Trigger data : Determines BCSM, IST, SUS/RES indicators.
SHISTTOTDP : SSF IST to IDP data : Connects IST and TDP.
SHTNS : SSF Trigger Network Signalling Data : Determines default data for SSF
Incoming/outgoing routes, Charging cases, Soft/hard Request, Calling Line Identity
handling.
SHTDP : SSF Trigger Detection Point Data : Determines Service key, Dialogue level,
Protocol Identity.
SHTDPS : SSF Trigger Detection Point Service Data : Determines Call Gap indicator,
Simulation Handling, SCF control Essential, Service Key, Destination identity.
SHINS : SSF Invoke Network Signalling Data : Determines Calling/ Called Number,
bearer Capability, High Layer Compatibility, and Service Interaction Indicators.
SHEXTLIST : SSF Extension List Data : Extension Field and associated data.
SHTSD : SSF Trigger Service Destination Data : Determines Global Title, Numbering
Plan, Nature of Address, Translation Type, Destnation Point Code, Subsystem Number (
for SCF address).
SHTSO : SSF Trigger Service Origination Data : Determines Global Title, Numbering
Plan, Nature of Address, Translation Type, Destnation Point Code, Subsystem Number (
for SSF own address).
SHEXTRANS : SSF Extension Field Translation.
16
SSFAM - Triggering Data SSFAM - Triggering Data
SSF-IST
DATA
(DBS)
SSF TRIG.
NET.SIGNAL.
(SHTNS)
IST TO TDP
DATA
(SHISTTOTDP)
SSF TRIG.
NET. SIGNAL
(SHTNS)
EXTENSION
FIELD LIST
DATA (SHEXTLIST)
SSF TDP
SERV. DATA
(SHTDPS)
SSF TRIG.
SERV.DEST
DATA
(SHTSD)
SSF TRIG.
SERV. ORIG
DATA
(SHTSO)
SSF TRIG.
NET. SIGNAL
(SHTNS)
EXTENSION
FIELD LIST
DATA
(SHEXTLIST)
IST
EXTENSION
FIELD TRANSL.
DATA (SHEXTTRANS)
XSS-IST
INDICATIOR
(CHARGING)
TDP
SERV.DATA
(SHTDPS)
Conditional
Triggering
Normal
Triggering
Page 17
This Triggering form is called Unconditional or Normal Triggering. This is the same
triggering principple as in SSF-STD inwhich the SSF based on trigger indications defined
in the IST to find out when-where-which data to send in IDP operation toward SCF to
invoke the IN-Service. The Service Logic Program can be located in local SSCP node or
remote in SCP node.
There is no pre-screening perfoming via co-located SCF.
17
Unconditional Triggering Unconditional Triggering
SSF
SCF
SCP
SSP
I
S
T
IDP CON
SETUP SETUP
Page 18
This type of triggering is used by SSF in order to run a screening service script on a co-
located SCF before invocation of the real IN service script.
The screening script is run in order to ensure that the service invoker has the authority
and capability to run the requested service. The execution of screening service is an
integrated part of the service invocation process.
To run the screening script an IDP operation is sent from SSF to an SCF located in the
same network node as SSF (SSCP), using a set of parameters applicable to the screening
required. The screening SLP (Service Logic Program) is identify by means of a
Conditional Triggering Service Key, defined within the IST.
If the screening is successful a Handover INAP operation is sent from co-located SCF to
SSF. At receiving of this operation an IDP will be formed using parameters applicable to
the SLP to be run in the event of successful triggering. A separate Service Key is
associated to this SLP. The SLP may be located in either local or remote Network node.
If the screening was unsuccessful, the triggering is failed and the dialogue between SSF
and the co-located SCF (the one that running screening script) is closed.
18
Conditional Triggering Conditional Triggering
SSCP
SSF SCF
SCP
SCF
SETUP
I
S
T
OP_IDP
OP_HANDOVER
OP_IDP
OP_CONNECT
Page 19
19
SSFAM - Triggering Example SSFAM - Triggering Example
DBTRI;
DBTSI:TAB=SHIST,IST=08130,TNSID=100,SSFTYPE=I,BSCMTYP=ORIG;
DBTSI:TAB=SHISTTOTDP,IST=08130,TDPNO=DP1,TDPID=280;
DBTSI:TAB=SHTNS,TNSID=100,ROUTTYP=DR,BRISRID=1,BROSRID=2,
DRISRID=1,DROSRID=2,CLIDTYP=1,SCFIDTY=0,ISCC=8,OSDCC=0,OSBCC=0;
DBTSI:TAB=SHTDP,TDPID=280,DIAGTYP=1,PROTI=1,TDPSID=80,
TINSID=101;
DBTSI:TAB=SHTDPS,TDPSID=80,SK=223,TRIG=1,TSID=100,TSOID=101,
SHR=1,SHS=5,EVTYPE=YES;
DBTSI:TAB=SHINS,INSID=101,CDN=OPT,CGCAT=OPT;
DBTSI:TAB=SHTSD,TSDID=100,DSTNAME=SCFN600,FDSTADR=0,
DPC=600,SSN=252;
DBTSI:TAB=SHTSO,TSOID=101,ORGNAME=SSFN600,FORGADR=0;
DBTRE=COM;
Page 20
20
SSFAM - Triggering - Administration SSFAM - Triggering - Administration
DBTSI : Data Base Table Specification, Insert.
DBTSC: Data Base Table Specification, Change.
DBTSP : Data Base Table Specification, Print.
DBTSE : Data Base Table Specification, End.
DBTRI : Data Base Transaction, Initiate.
DBTRE : Data Base Subsystem procedure, End.
DBTRR : Data Base Subsystem procedure, Reset.
DBTRS : Data Base Subsystem procedure, Set.
Page 21
The Detection Points that marks with an arrow are those new DPs in comparison with
SSF-STD detection points.
21
SSFAM - Trigger Detection Points SSFAM - Trigger Detection Points
Trigger Detection points on Originating CLSM :
DP1 - O-Attempt Authorized : Receipt of ISUP message IAM.
DP2 - Collect Information : Receipt of IAM or SAMs, number analysis
is not completed.
DP3 - Analysed Information : Receipt of IAM or SAMs, number analysis
is completed.
DP4 - O-Route Select Failure : REL from B-side.
DP4a- O-Alerting : ACM or CPG(alerting) from B-side.
DP5 - O-Called Party Busy : REL from B-side, cause value busy.
DP5a- O-CalledPartyNotReachable : REL from B-side, cause value subscriber
absent
DP6 - O-Noanswer : REL from B-side, cause value No-answer
from user.
DP7- O-Answer : Receipt of ANM or CON from B-side.
DP8 - O-Midcall : Flash
DP9 - O-Disconnect : REL from A or B-side, cause user onhook
or T-suspend expired.
DP10- O-Abandon : REL from A-side before entry to active PIC.
DP11- O-Suspended : Receipt of network initiated SUS from B-side
DP11a- O-Reanswer : Receipt of reanswer from B-side.
Page 22
The Detection Points that marks with an arrow are those new DPs in comparison with
SSF-STD detection points.
22
SSFAM - Trigger Detection Points SSFAM - Trigger Detection Points
Trigger Detection points on Terminating CLSM :
DP12 - T-Attempt Authorized : Receipt of ISUP message IAM.
DP12a - T-Route Select Failure : REL from B-side.
DP12b - T-Alerting : ACM or CPG(alerting).
DP13 - T-Called Party Busy : REL from B-side, cause value busy.
DP13a - T-CalledPartyNotReachable : REL from B-side, cause value subscriber
absent
DP14 - T-Noanswer : REL from B-side, cause value No-answer
from user.
DP15 - T-Answer : Receipt of ANM or CON from B-side.
DP16 - T-Midcall : Flash
DP17 - T-Disconnect : REL from A or B-side, cause user onhook
or T-suspend expired.
DP18 - T-Abandon : REL from A-side before entry to active PIC.
DP19 - T-Suspended : Receipt of network initiated SUS from
B-side
DP19a - T-Reanswer : Receipt of reanswer from B-side.
Page 23
In this chapter we will try to get a picture of how the Call procession in SSF-AM looks
like.
In principple the SSFAM Call procession is quite similar with SSF-STD. But because of
function block structure is different and becuase of the multiple call legs possibility, the
flow of signalling through function blocks in SSFAM is different in compare with SSF-
STD.
The mechanisme with which SSFAM handles charging is totally not mentioned.
To know more about SSFAM we are expected to go deeper into the AM environment
which is not belonged to this courses scope.
23
SSFAM - Call Processions SSFAM - Call Processions
Page 24
This picture shows the IN call procession without triggering and invocation of SCF.
The call configuration as above can be encounterred if the IN service triggering is
defined so that the invocation of SCF is stated at later Detection Points of a call process,
i.e Detection Point Disconnect (DP9).
When a subscriber dials IN access number a call setup will be performed toward IN, the
Initial Address Message (IAM) is sent on the route toward SSF. At receiving of this
message the Call Manager block (SHCM) will in co-operation with Message Manager
(SHMM) and Charging Manager (SHCHM) to handle the incoming message and take
care of seizure of other function blocks that needed fot this IN call. The Call Control
block (SHCC) is linked in to control the Call View. The CLSM handler (SHCLSM) is
linked in to control the moving of call sequence in the Call Leg State Models. The Event
Handler (SHEC) is also linked in to control and report traffical events (internally in SSF).
When the SSF find out that the condition for forwarding the call to the outgoing side is
fullfilled, it will build the IAM message, based on the data received from incoming side
and based on triggering data indicator, and sent the IAM to outgoing side.
When the Address Complete Message (that indicates Alerting on outgoing side) is
coming, the event will be noted, the CLSM state is changed, and if no further information
must be added in the ACM, the SSF will transfer the ACM to incoming side.
The same will be performed when Answer Message is received (ANM).
The call after ANM is stated to be through connection or in speech position.
24
Call Procession - With no triggering Call Procession - With no triggering
DJO
SHCM
SHMM
SHCHM
DJI
SHCLSM SHTTM SHEC
TCS
IAM_REC
IAM_SENT
DP_REACH(DP1,2,3,12)
DP_REACH (DP1,2,3,12)
TCS
ACM/ANM_REC
ACM/ANM_SENT
SHCC
Page 25
This picture shows the IN call procession in which the triggering and invocation of SCF
is performed.
This call configuration is encounterred when a Triggering Detection Point, that was
defined into IN service Triggering data, is reached after routing to SSF has been
successful performed.
When a subscriber dials IN access number a call setup will be performed toward IN, the
Initial Address Message (IAM) is sent on the route toward SSF. At receiving og this
message the Call Manager block (SHCM) will in co-operation with Message Manager
(SHMM) and Charging Manager (SHCHM) to handle the incoming message (read and
store data) and take care of seizure of other function blocks that needed for this IN call.
When the Trigger Detection Point is reached tthe CLSM handler block (SHCLSM) will
be informed. By co-operation with Event Handler (SHEC) and TASI Trigger Manager
block (SHTTM) the IDP operation will be built with the data indicated by SHTD1-8. The
IDP operation will be sent to Protocol handler block (SHPM) via the TASI-ROS interface
function block (SHTRI).
The IDP operation sending will be checked by TASI Dialogue Manager (SHTDM).
The IDP operation is received by SCF through Protocol handler and Remote Operation
Handler blocks (SHPM and SHTCUn). A service script will be pointed out in SCF and
the operations that tight to the service will be sent to SSF.
The typical operation that is received from SCF can be Connect or RequestReportBCSM
operation. In the later overheads we will deal with operation receiving and execution.
It is the Call Control block (SHCC) that will handle the operation Connect received from
SCF, it will also process the operation execution into traffic link, and report result on
operation execution to SHTDM.
When the SSF find out that the condition for forwarding the call to the outgoing side is
fullfilled, it will build the IAM message, based on the data received from incoming side,
on triggering data indicator, and on the Connect operation received from SCF and sent the
IAM to outgoing side.
25
Call Procession - With Triggering Call Procession - With Triggering
DJO
SHCM
SHMM
SHCHM
DJI
SHCLSM SHEC SHTTM
SHTRI
SHTDM
SHPM
SHTCUn
SHTD1-8
TCS TCS
DP_REACH
TDP_ENCOUNT
IAM_REC
DBS_DATA
IDP/ARI_SENT
INVOKE_DATA
IAM_SENT
SCF
SHCC
OP_PROCESS
OP_PROCESS
DP_REACH
OP_PROCESS
Page 26
In this picture we deal with operation receiving from SCF in SSF.
After the IN service is invoked the SCF will sequentially send the operation tight to
service to SSF, performing the service.
Typically the operation RequestReportBSCM and Connect that may be sent to SSF, to
armed on some Event detection points and to connect the call to an outgoing subscriber.
The operations sending from SCF will be performed by the blocks mentioned in the
picture above.
- SHTCUn : Handles the operations parameters. Checks on transaction capability
(depend on which TCAP the SSF is interface with).
- SHPM : Intepretes / filters the operations data.
- SHPM : Checks on dialogue FSM to see that the operation receiving/executing in SSF
is allowed or not.
- SHTRI : Checks on TASI-ROS interface, makes sure that the operation receiving of
data is happened sequentially. (By checking on invoke request/response).
- SHCC : After receiving of invoke_request for receiving operation data, whenever it is
available for the block to read operation data, the SHCC will send invoke_response to
SHTRI and begins to read operation data directly from SHPM (can be Connect
operation).
- SHEC : The same mechanisme is performed by SHEC, to read the operation data of it
own (the operation is e.g RRB).
- When all operation data are read then its up to SHTDM to decide that operation
execution shall be started or not.
26
Call Procession - Receiving a sequence of Operations Call Procession - Receiving a sequence of Operations
SHTCUn
SHPM
SHTRI
SHTDM
SHEC SHCC
SCF
OP_SENT(2)
OP_DATA_READ(5) OP_DATA_READ(10)
OP_SENT(1)
INV_REQ(3&8)
INV_RESP(7&12)
INV_REQ(4)
INV_RESP(6)
INV_REQ(9)
INV_RESP(11)
PROCESS_OP(13&14)
Page 27
In this picture we study on processing of a sequence of operation during execution of
them within SSF.
After the operations data are sucessfully fetched by the operation owner blocks the TASI
Dialogue manager (SHTDM) will order the the operation owner to decode the operations.
An Operation token handling procedure (that controlled by SHEC) will be used to ensure
that the operation decoding and execution is happened sequentially.
At successfully decoding of operations, the SHTDM will in sequence order the operation
owners to execute the operation.
27
Call Procession - Processing a sequence of Call Procession - Processing a sequence of
Operations (1) Operations (1)
SHTDM
SHCM
SHMM
SHCHM
SHEC SHCC SHCLSM
DJO DJI
TCS TCS
OP_DECODE
OP_EXEC_REQ
OP_EXEC_RESULT
OP_DECODE
OP_EXEC_REQ
OP_EXEC_RESULT
OP_TOKEN_HANDL
TRAF_DATA_READ_WRITE
IAM_REC
IAM_SENT
Page 28
In this picture we study the INAP operation sending from SSF to SCF.
A traffical event can result in an operation sending from SSF to SCF. Lets take an
example, if event Alerting has been armed as Event Detection Point in Request mode.
When Adrdress Complete Message is receiving from outgoing side of SSF, a report to
SCF must be performed. The operation EventReportBCSM (ERB - on DP5a) will be built
and sent to SCF.
The operation owner (in this case is the Event Handler - SHEC) will inform SHTDM -
the TASI Dialogue Manager - about the require.
The SHTDM informs the protocol manager (SHPM) within ROS (via SHTRI) and the
operation (ERB) data will then be read directly from the operation owner.
Further information about sending and receiving of operation in SSFAM can read from
document : 2/15519-APR 101 15 Uen.
28
Call Procession - Processing a sequence of Call Procession - Processing a sequence of
Operations (2) Operations (2)
SHCM
SHMM
SHCHM
DJI DJO
SHCLSM SHEC SHTRI
SHPM
SHTCUn
SHTDM
TCS
TCS ACM_REC ACM_SENT
ACM_EVENT_NOTIFY
ACM_EVENT_NOTIFY
INV_REQ
INV_RESP
INV_ID_REQ
INV_ID_RES
INV_RESP
INV_OP-SENT
DATA_READ
OP_DATA_FOR_SENDING
INV_REQ
Page 29
Further information about the Simulation Handling function in SSFAM can find in the
following documents :
CODs :
1-4/19082-CNT 299 63 Uen : Service Switching Simulation Function
OPI :
1/15431-CNT 299 63 Uen : Service Switching Simulation Dialogue, Test.
AI2 :
2/15518-CNT 299 63 Uen : Service Switching Simulation Function.
29
SSFAM - Simulation Handling SSFAM - Simulation Handling
Simulation handling function in SSFAM is called : SHSIM.
The usages of SHSIM is similar with the INTSIMs in SSF-STD :
- Monitoring of IN dialogue.
- Simulating of IN-function Entities.
- Testing of IN function Entities communication.
Commands :
- SHSDI : Dialogue Simulation, Initiate.
- SHSDE : Dialogue Simulation, End.
- SHSOI : Operation Simulation, Initiate.
- SHSCI : Operation Simulation - Camel , Initiate.
Page 30
30
Appendices Appendices
Page 31
31
Appendices (1) Appendices (1)
Basic Call Handling function Blocks (BC):
SHCLSM : Service Switching Call Leg State Model.
* Keeps track of ISUP messages that have been sent/received
on the leg.
* Reports Local events and Detection point.
* Holds CLSM models.
SHCM : Service Switching Call Manager.
* Coordinates reporting od DP on legs connected to the
Connection Point.
* Administers the physical connection in the Group switch
using RMP.
* Seizure/Release of Call and leg Individuals.
Page 32
32
SHMM : Service Switching Message Manager.
* Handling of Sending/receiving SSFTP (ISUP) mesages
to/from SSFDJI/O via the RMP.
* Administers the messages token.
* Allow users in SSFAM to read/write data into the messages.
SHRDO: Service Switching Route Data Owner.
* Route data Owner in SSFAM.
* Provides Route data to other blocks in SSFAM.
* Setup, change and removal of SSF route data when
requested by SHBCA block.
SHBCA: Service Switching Basic Call Administration.
* Administers of route data.
Basic Call Handling function Blocks (BC-continued) :
Page 33
33
Call Control and Monitoring (CC) :
SHCC: Service Switching Call Control.
* Controls the flow of SSFTP(ISUP) messages.
* Handles operations : CI, CON, CUE, ICA, RC, HCP, REC, RCP,
and SGI.
SHCFH: Service Switching Clearing and Fault Handling.
* Ensures proper Leg or Call release when fault occurred in
SSFAM during the call.
SHEC: Service Switching Event Control.
* Reporting of events during the call to the users. The events
can be on Leg, Call, or Dialogue.
The Users can be the internal SSF function blocks or SCF if
any request events existed.
* Call Token request handling.
* CIRp, CIRq, ERB, RRB operation handling.
Page 34
34
Charging handling (CH) :
SHCHM: Service Switching Charging Manager
* Controls charging of IN services.
* Uses Charging services provided by the RMP.
* Handles operations : AC, ACR, ENC, RNC, FCI, and SCI.
SHCA: Service Switching Charging Analysis.
* Controls Charging Analysis.
PS: In Polaris the Charging handler blocks are replaced by two
new charging blocks : one acts as Charging Platform and another
as Charging Executor.
Page 35
35
Specialized Resource Function handling (SRF) :
SHOPSRF: Service Switching Operation SRF
* Seizure and use RMP resources in respect to Annc,
Tones and Digits reception.
* Handling of connection to assisting SSF.
* Handles operations : CTR, DFC, ETC, PA and P&C.
SHINSRF: Service Switching Internal SRF
* Seizure and use of RMP resources in respect to annc,
and Tones.
* Provides interface to internal SSF users to play annc, tones or
Text to an end users.
* Translation of TextID to text string.
Page 36
36
Triggering And SCF Invocation handling blocks (TASI) :
SHTRI: Service Switching TASI-ROS Interface
* Distribution of Operations.
* Dialogue seizure/release handling.
* Operation versus Message coordination
* Handles operations : CAN and RT.
SHTDM: Service Switching TASI Dialogue Manager.
* Transmission, reception, Sequencing, screening of
components sent to/from SCF.
* Contains Call View, CPV and APV FSM.
SHTTM: Service Switching TASI Trigger Manager.
* Fetching, Arming TDPs for the call.
* Contains Session view FSM.
* Handles operations : IDP, HO, ARI.
Page 37
37
Triggering And SCF Invocation handling blocks (TASI-cont) :
SHTD1-8: Service Switching TASI Trigger Data 1-8
* Trigger data.
* Data Base Subsystem data.
Page 38
38
Mass call handling blocks (MCS) :
SHMCS : Service Switching Mass Call Services
* Queueing and distributing ASF, CG and CL.
* Traffic handling when the call stopped.
SHSF : Service Switching Service Filtering.
* Performs Service Filtering.
* Setup, Change, Deleting of analysis tree.
* Handles operations : ASF and SFR.
SHSFA : Service Switching Service Filtering Administration.
* Administers service filtering.
Page 39
39
Mass call handling blocks (MCS-continued) :
SHCG: Service Switching Call gap.
* Perfoms Call Gap.
* Setup, Change, deleting of analysis tree.
* Handles operation : CG.
SHCGA : Service Switching Call Gap Administration.
* Administers Call Gap.
SHCL : Service Switching Call Limit
* Performs Call Limit.
* Setup, Change, Deleting of analysis tree.
* Handles operations : CL.
SHCLA : Service Switching Call Limit Administration.
* Administers Call Limit.
Page 40
40
Remote Operation handling (ROS) :
SHTCU1 : Service Switching Transaction Capabilities User1
* Interface towards CCITT TCAP (CME 20).
SHTCU2: Service Switching Transaction Capabilities User2
* Interface towards Adapted White CCITT TCAP based on
ANSI SCCP (CMS 40).
SHTCU3 : Service Switching Transaction Capabilities User3
* Interface towards Japanese TCAP (CMS 30).
SHPMx : Service Switching Protocol Manager.
* Interwork of outgoing CS1 operations for market
adaptations.
* Operation Verification.
Page 41
41
Simulation Handling (SIM) :
SHSIM : Service Switching Simulation Function
* Simulation of SSF towards the SCF.
* Simulation of SCF towards the SSF.
* Logging of components between SSF and SCF.
SHEXT : Service Switching Extensions.
* Value mapping of mobile specific parameters from SSFTP
parameters to extensions in INAP operations and
vice versa.
SHEXPA : Service Switching Exchange Properties
Administration.
* Administration and storage of SSF-AM exchange Properties.

Ssfam

Caricato da

Informazioni sul documento

Descrizione originale:

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

Ssfam

Caricato da

Copyright:

Formati disponibili

Page 1

Potrebbero piacerti anche