Specification and Validation of Telecommunication Services in ACP

90 Pages·2008·0.59 MB·English

Speci(cid:2)cation and Validation of Telecommunication Services
(cid:0)
in ACP
Yuan Zhaorui
Abstract
Thispaperisconcernedwiththeformal speci(cid:2)cationandvalidationoftelecommunication
services(cid:3) Firstly(cid:4) we provide a method to model the telecommunication system(cid:3) Based on
thisresult(cid:4)wegivetheformalspeci(cid:2)cationoftelecommunicationservicesandthedetectionof
(cid:0)
feature interactions(cid:4) using the Algebra of CommunicationProcess with Abstraction (cid:5)ACP (cid:6)(cid:3)
Speci(cid:2)cation examples are given(cid:4) (cid:2)rst basic(cid:4) about the telecommunication system and plain
old telephoneservices(cid:4) thenwithsupplementaryservices(cid:4) suchascall waiting(cid:4)call forwarding
busy(cid:4) three way calling(cid:3) We show by examples how to apply our method to the detection of
the feature interactions(cid:3)
(cid:0)
Keywords TelecommunicationService(cid:4) FeatureInteractions(cid:4) ACP (cid:4) IntelligentNetwork
(cid:0) Introduction
The short history but quick development of telecommunication network witnesses how they are
driven and stimulated into huge changes by market competition and continuously increasing cus(cid:2)
tomerrequirementstoprovidenewservicesasquicklyaspossible(cid:3) Aseriesofnewtechniques(cid:4)such
as intelligent network (cid:5)IN(cid:6) is developed to ful(cid:7)ll this task(cid:3) However(cid:4) due to the development of
softwareandhardwaretechnology(cid:4)thetelecommunicationsystemhasevolvedtoalarge(cid:4)real(cid:2)time(cid:4)
distributedsoftwaresystem(cid:3) Introducinganewtelecommunicationserviceintosuchacomplicated
system also introduces the risk of interfering the behavior of existing software component or ser(cid:2)
vices(cid:4) whichmaybringcostlyandcatastrophicsoftwarefaults(cid:3) In ordertoensurethereliabilityof
the telecommunication system(cid:4) speci(cid:7)cation and validation work is required before introducing a
new telecommunicationserviceintothenetwork(cid:3) Moreover(cid:4)ifanewservicehasnegativein(cid:8)uence
on the network(cid:4) strategies must be introduced to the network to solve the problem(cid:3)
In the behavior analysis of telecommunication system(cid:4) formal techniques have a place because
they allowlogical modeling(cid:4) prototypingand validation of features at the design stage (cid:9)(cid:10)(cid:11)(cid:12)(cid:3) When
engineers start to give some formal speci(cid:7)cations of a telecommunication system(cid:4) they are un(cid:2)
doubtedly in need of an e(cid:13)cient model to describe the call processing procedure in the system(cid:4)
which can provide enough information for the speci(cid:7)cation and analysis of the system(cid:3)
This paper describes amethod(cid:4) basedon Algebraof Communication Processwith Abstraction
(cid:0)
(cid:5)ACP (cid:6)(cid:4) for specifying and analyzing the telecommunication system(cid:3) Central to the method is
the call processing model based on the basic call state model (cid:5)BCSM(cid:6) concept from the Telecom(cid:2)
munication sector of International Telecommunication Union (cid:5)ITU(cid:2)T(cid:6) Capability Set(cid:2)(cid:10) (cid:5)CS(cid:2)(cid:10)(cid:6)
recommendation of IN(cid:3) BCSM is a state transition machine representing the behavior of switch(cid:2)
ing processes(cid:3) BCSM is able to supports the description of call processing procedure of plain old
telephone services (cid:5)POTS(cid:6) and (cid:14)(cid:15) IN services in CS(cid:2)(cid:10) (cid:9)(cid:16)(cid:12)(cid:3)
Ourcallandserviceprocessingmodel is buildbytheparallelcompositionofBCSMsand other
processesrepresentingothertelecommunication systementities(cid:4) such asusers andtelecommunica(cid:2)
tionservices(cid:3) Byanalyzingthe parallelexecutionand communicationbehaviorsofthese processes
with the help of computer supported tools(cid:4) we arriveat a stagewhere it is possible to analyze the
execution traces of IN calls and detect the interactions between IN services(cid:3)
(cid:16)
(cid:0)
For speci(cid:7)cation and analysis(cid:4) we use ACP (cid:4) which has been developed since (cid:16)(cid:17)(cid:15)(cid:10) at the cen(cid:2)
(cid:0)
ter for Mathematics and Computer Science(cid:4) Amsterdam (cid:9)(cid:18)(cid:12)(cid:3) ACP is the formalism suitable for
describing distributed system of processes communicating in a synchronous way(cid:3) Process Speci(cid:7)(cid:2)
(cid:0)
cation Formalism (cid:5)PSF(cid:6) is a computer readable language to specify ACP processes(cid:3) Moreover(cid:4)
PSF formally supports the data types and modularization(cid:3) PSF has a supporting toolset PSF
(cid:0)
Toolkit to analyze the behavior of a system speci(cid:7)ed in ACP (cid:3)
Thispaperisstructuredasfollows(cid:3) Section(cid:10)presentsthemodelofINcallandserviceprocess(cid:2)
(cid:0)
ing(cid:3) Section (cid:14) givesa brief introduction to ACP and PSF(cid:3) Section (cid:19) presents formal descriptions
of the telecommunication system and services(cid:3) Section (cid:18) presents examples on how to detect
feature interaction based on formal speci(cid:7)cations and formal tools(cid:3) In the appendices(cid:4) we give
some speci(cid:7)cation examples(cid:3) Appendix A presents a PSF speci(cid:7)cation of the data used in our
module(cid:3) Appendix B presents a detailed PSF description of telephone users and BCSMs(cid:3) Ap(cid:2)
pendix C presents a PSF description of several IN services(cid:3) Appendix D and Appendix E present
a description of IN services states and BCSM states respectively(cid:3)
Acknowledgements
This report was re(cid:7)ned in discussion with Kees Middelburg(cid:3) I would like to thank him for his
comprehensive reading and important comments(cid:3) I would like also to thank Jan Bergstra for his
remarks on the system modeling(cid:4) and Vincent van Oostrom for his nice help(cid:3)
(cid:2) Modeling of IN Call Processing
(cid:2)(cid:3)(cid:4) Introduction to the BCSM concept in IN
ThebasicaimofIntelligentNetwork(cid:5)IN(cid:6)istoprovideanetworkstructuretofacilitatequickservice
deployment(cid:3) Thisaimisachievedbyconstructingacomputernetworkuponthetransportnetwork(cid:3)
The function of transport network is simpli(cid:7)ed to only switching and information transmission(cid:4)
while theservicecontrolfunctionsareleft fortheupper levelcomputernetwork(cid:3) Atcertainpoints
in the IN call processing(cid:4) the switch can suspend the call and trigger IN services residing in the
computer network(cid:4) and apply for IN service(cid:20)s control overthe call processing(cid:3)
ITU(cid:2)T proposes two state transition machines Originating Basic Call State Model (cid:5)OBCSM(cid:6)
andTerminatingBasicCallStateModel(cid:5)TBCSM(cid:6)torepresenttheswitchingcontrolonthecalling
party and the called party respectively(cid:3) Figure (cid:16) shows both state transition machines(cid:3) On the
left side is the state transition machine representing the behavior at the originating side(cid:4) and on
the right side is the state transition machine representing the behavior of the terminating side(cid:3)
BCSMs provide a high(cid:2)level model of switching activities required to establish and maintain
communication paths for users(cid:3) As such(cid:4) BCSMs identify a set of basic call and connection ac(cid:2)
tivities in switching and show how these activities are joined together to process a basic call and
connection(cid:9)(cid:16)(cid:12)(cid:3) Inparticular(cid:4)itprovidesaframeworkfordescribingbasiccallandconnectionevents
that can lead to the invocation of or should be reported to telecommunication service processes(cid:4)
for describing those points in call and connection processing at which these events are detected(cid:4)
and for describing those points in call and connection processing when the transfer of control can
occur(cid:3)
Figure (cid:16) shows the components that have been identi(cid:7)ed to describe a BCSM(cid:4) including(cid:4) De(cid:2)
tection Points (cid:5)DP(cid:6)(cid:4) represented as small rectangles(cid:21) Points in Call (cid:5)PIC(cid:6)(cid:4) represented as big
rectangles(cid:21)BCSMtransitionsandevents(cid:3) PICsidentifyswitchingactivities associatedwithoneor
morebasiccall(cid:22)connectionstatesof interestto telecommunicationservices(cid:3) DPs indicatestatesin
basiccallandconnectionprocessingatwhichtransferofcontroltotelecommunicationservicelogic
can occur(cid:3) Telecommunication services are permitted to interact with basic call and connection
control capabilities at DPs(cid:3) For example(cid:4) PIC Authorize Origination Attempt in OBCSM is a
state where the originating terminal rights are being checked(cid:21) DP T Busy is a state where the
(cid:10)
Figure (cid:16)(cid:23) Basic Call State Model
terminating party busy event is encountered in terminating call processing(cid:3) It is possible for IN
services to control the state transitions at DP(cid:3)
BCSM transitions(cid:4) representedas solid lines in Figure (cid:16)(cid:4) are the transitions in Plain Old Tele(cid:2)
phone Services (cid:5)POTS(cid:6)(cid:4) which indicate the normal (cid:8)ow of basic call(cid:22)connection processing from
one PIC to another(cid:3) In addition to BCSM transitions(cid:4) there areextended transitions(cid:4) represented
as dotted lines in Figure (cid:16)(cid:4) which are caused by IN services(cid:3)
In Section (cid:10)(cid:3)(cid:10) and Section (cid:10)(cid:3)(cid:14)(cid:4) we show how to model IN call and service processing based
on the BCSM concept(cid:3) We start from POTS(cid:4) the elementary service in the telecommunication
system(cid:3)
In the IN structure(cid:4) telecommunication services provide additional functions over the basic
phone service in the sense that new telecommunication services are introduced to the network
without modifying the switching software(cid:4) but by adding software for the service concerned in
the computer network(cid:3) IN services di(cid:24)er from each other by de(cid:7)ning di(cid:24)erent communication
behavior between the computer network and the communication network(cid:4) thus causes di(cid:24)erent
state transition procedure in the BCSM(cid:3)
(cid:2)(cid:3)(cid:2) Modeling of POTS
POTS is elementary in that it only provides the voice connection between two terminal users(cid:3)
Supplementary services and multi(cid:2)party calls are all built upon the two(cid:2)party call provided by
POTS(cid:3) In this section(cid:4) we illustrate how to model POTS(cid:3)
u(cid:2) c(cid:2) u(cid:3)
OBCSM TBCSM Called
Calling
c(cid:3) u(cid:5)
u(cid:4)
Figure (cid:10)(cid:23) Modeling of a POTS call
Any POTScall is composedof(cid:19) elements(cid:4) the calling party(cid:4) the called party andtwoswitching
(cid:14)
processes in charge of their behavior (cid:5)these processes may be in the same physical entity(cid:4) i(cid:3)e(cid:3) the
sameswitch(cid:6)(cid:3) Figure(cid:10)isthemodelingofasimpletwopartycall(cid:3) Theentitiescallingandcalledare
processesonbehalfofterminalusers(cid:4)whicharecapableofsendingusersignalstothenetwork(cid:4)such
as o(cid:24)hook(cid:4) onhook(cid:4) dialing(cid:21) or receiving signals from the network(cid:4) for example(cid:4) dial(cid:2)tone(cid:3) These
processes execute in parallel and communicate with each other to establish the voice connection
between the calling partyandthe called party(cid:3) Elements u(cid:3)up tou(cid:4) arecommunicationchannels
between users and BCSMs(cid:3) OBCSM and TBCSM synchronizewith each other by communicating
on Channel c(cid:3) and c(cid:5)(cid:3)
OBCSM starts call processing when the calling party o(cid:24)hooks(cid:3) It takes some internal actions
to authorize the terminal rights to initiate the call(cid:4) and to synchronize with the calling party
again on the signal dial(cid:2)tone(cid:3) After the called party number is collected(cid:4) OBCSM selects the
route and initiates the terminal call processing on the TBCSM side(cid:3) TBCSM is responsible for
authorizingand ringing the called party(cid:3) If the called partyanswers the call(cid:4) the voice connection
betweenthetwopartiesisestablishedandtheBCSMswaitforaconnectionreleaseevent(cid:3) BCSMs
decide their state transitions based on the messages received from other entities(cid:3) There are two
kinds of communication between these parallel processes(cid:23) communications between the users and
the switching network(cid:4) and communications between the switching processes(cid:4) i(cid:3)e(cid:3) OBCSM and
TBCSM(cid:3)
There are several points in our model worth explanation(cid:23)
(cid:16)(cid:3) In the modeling of POTS(cid:4) we use the same process to describe the calling party and the
(cid:0)
calledparty(cid:4) whicharedistinguishedbytheircommunicationbehaviorswithotherprocesses(cid:3)
Actually(cid:4) the deployment of multi(cid:2)party services such as three way calling (cid:5)TWC(cid:6) already
blur the distinction between the calling and the called(cid:3) A user can be explicitly expected
to be the calling or the called in a two(cid:2)party call(cid:4) but in multi(cid:2)party calls(cid:4) this situation is
changed(cid:3) Forexample(cid:4) a TWC servicesubscribercan be the calledpartyin an existing call(cid:4)
buthis(cid:22)herrolechangestothecallingpartywhenthesubscriberputthecurrentcallonhold
and initiate a call to a new party using the functionality of the TWC service(cid:3)
If we insist on using di(cid:24)erent formal descriptions for the calling and the called party in this
situation(cid:4) the modelingofuserswill bedi(cid:13)cult andconfusing(cid:3) A(cid:8)exible but e(cid:24)ectivechoice
is to use the same process description to specify them(cid:3) It is left for the communication
behaviors to decide whether a user is a calling party or a called one in the current call
processing context(cid:3)
(cid:10)(cid:3) ThereisnodirectcommunicationbetweenOBCSMandthecalledparty(cid:4)orbetweenTBCSM
and the calling party(cid:3)
(cid:14)(cid:3) We use the same model for the inter(cid:2)switch call and the intra(cid:2)switch call(cid:3) However in CS(cid:2)(cid:10)(cid:4)
thecallprocessingmodelforinter(cid:2)switchcallisasdescribedinFigure(cid:14)(cid:4) whichisderiveddi(cid:2)
rectlyfromthephysicalimplementation(cid:3) Ininter(cid:2)swi(cid:0)tchcalls(cid:4)OBC(cid:0)SMcannotcommunicate
directly withTBCSM in anotherswitch(cid:4) so OBCSM and TBCSM areimplemented respec(cid:2)
tively in the switch at the calling side an(cid:0)d the one at t(cid:0)he called side(cid:4) in orderto synchronize
the OBCSM and the TBCSM(cid:3) OBCSM and TBCSM are mirror processes(cid:0) of OBCSM and
TBCSMinthesensethatifasignalsentbyOBCSMisreceivedinTBCSM incertainstate(cid:4)
the signal is received in TBCSM in the same state(cid:4) and the signa(cid:0)l is processed in the same
way(cid:3) If the signalcausesstatetransitionsin TBCSM and TBCSM (cid:4) the statetransitions are
thesame(cid:3) ThisisthesamecaseforsignalssentbyTBCSM(cid:3)Sincethe aimofourmodelingis
to analyze the service behavior and what we care about is the state transitions in OBCSM(cid:4)
TBCSM(cid:4) as well as their com(cid:0) municatio(cid:0)ns with the environment and their in(cid:8)uence on each
other(cid:4) we simplify OBCSM (cid:4) TBCSM and the communication channels between them to
communication channels between OBCSM and TBCSM(cid:4) and in this way(cid:4) we use the same
model for intra(cid:2)switch calls and inter(cid:2)switch calls(cid:3)
(cid:0) (cid:0)
SeeSection (cid:5)(cid:6)(cid:2)fortheACP descriptionofusers(cid:6)
(cid:19)
SWITCH SWITCH
(cid:0) (cid:0)
OBCSM TBCSM OBCSM TBCSM
calling called
Figure (cid:14)(cid:23) BCSMs in a two(cid:2)party inter(cid:2)switch call
In Table (cid:16)(cid:4) we describe the set of user(cid:2)network signals and the BCSM(cid:2)BCSM signals(cid:3)
We write U for the set of user(cid:2)network signals(cid:4) V for the set of BCSM(cid:2)BCSM signals(cid:4) ADDR
for the set of terminal addresses(cid:4) ID for the set of identi(cid:7)ers for the two party call(cid:3) We have(cid:23)
U (cid:25) f o(cid:6)hook(cid:5)x(cid:6)(cid:4) onhook(cid:5)x(cid:6)(cid:4) (cid:8)ashhook(cid:5)x(cid:6)(cid:4) dial(cid:5)x(cid:4)y(cid:6)(cid:4)
noanswer(cid:5)x(cid:6)(cid:4) userbusy(cid:5)x(cid:6)(cid:4) useridle(cid:5)x(cid:6)(cid:4) dial tone(cid:5)x(cid:6)(cid:4)
alert user(cid:5)x(cid:4)y(cid:6)(cid:4) special tone(cid:5)x(cid:6)(cid:4) stop special tone(cid:5)x(cid:6)(cid:4) back ring(cid:5)x(cid:4)y(cid:6)(cid:4)
CWtone(cid:5)x(cid:6)(cid:4) busy tone(cid:5)x(cid:4)y(cid:6)(cid:4) stop back ring(cid:5)x(cid:4)y(cid:6)(cid:4) stop alert user(cid:5)x(cid:4)y(cid:6)(cid:4)
stop CWtone(cid:5)x(cid:6)(cid:4) stop dial tone(cid:5)x(cid:6)
j x(cid:4) y (cid:2) ADDR g
V (cid:25) f initiate(cid:2)tb(cid:5)id(cid:4) y(cid:6)(cid:4) calling(cid:2)disconn(cid:5)id(cid:6)(cid:4) calling(cid:2)abandon(cid:5)id(cid:6)(cid:4)
terminating(cid:2)busy(cid:5)id(cid:6)(cid:4) call(cid:2)acceptance(cid:5)id(cid:6)(cid:4) called(cid:2)rejected(cid:5)id(cid:6)(cid:4)
called(cid:2)noanswer(cid:5)id(cid:6)(cid:4) called(cid:2)suspend(cid:5)id(cid:6)(cid:4) called(cid:2)reanswer(cid:5)id(cid:6)
j id (cid:2) ID(cid:4) y (cid:2) ADDR g
ThemodelingofatwopartycallisfundamentaltoINservicespeci(cid:7)cationsandfurtherresearch
on feature interactions(cid:3) Complicated IN calls(cid:4) such as multi(cid:2)party calls(cid:4) conference calls can be
decomposed into a number of two party calls(cid:3) There are no direct communication between these
two party calls(cid:4) but these calls can be controlled together by one or more IN services(cid:3) Similar
decomposition work can be found in (cid:9)(cid:16)(cid:26)(cid:12)(cid:3)
By decomposing complicated IN calls into a number of two party calls(cid:4) we have a chance to
look deep into how IN services interwork with each other(cid:4) and how improper interworking results
(cid:2)
in feature interactions(cid:3)
(cid:2)(cid:3)(cid:5) Modeling of Telecommunication System with IN service
(cid:0)(cid:2)(cid:3)(cid:2)(cid:4) General Introduction
Supplementary telecommunication services(cid:4) such as call waiting (cid:5)CW(cid:6)(cid:4) call forwarding on busy
(cid:5)CFB(cid:6)(cid:4) three way calling (cid:5)TWC(cid:6)(cid:4) etc(cid:3) provide additional functions to subscribers by modifying
the basic call processingand connectioncontrolprocedure in the basic switching element(cid:3) The IN
structure enables the servicecreation and deployment independent of the existing communication
network(cid:3) Services are de(cid:7)ned by introducing additional software into the upper level computer
network(cid:3) ThenotionthatservicecontrolandcallcontrolareprovidedseparatelyinINmotivatesus
todescribeatypeofINservicewithaparameterizedprocess(cid:3) Theparametervaluewillbeassigned
when the service is activated(cid:3) The interworking between the IN service and the communication
network is modeled by the communications between the processes concerned(cid:3) More speci(cid:7)cally(cid:4)
when an IN call is initiated(cid:4) at certain DP points(cid:4) BCSMs can suspend call processing and send
messages to IN services to report call processing events(cid:3) After receiving the messages(cid:4) IN services
may send messages back to the BCSMs concerned(cid:4) after which the BCSMs can decide the state
transitions based on the messages received(cid:3)
(cid:2)
SeeSection (cid:7)(cid:6)
(cid:18)
Signaling Set Signaling Direction Name Comments
Between User to Network o(cid:24)hook The user lifts the handset(cid:3)
User onhook The user hangs up(cid:3)
and (cid:8)ashhook (cid:27)
Network noanswer Called party no answer
userbusy Called party busy
useridle Terminal is in the idle state
dial (cid:27)
Network to User dial tone Dialing tone
stop dial tone To stop dialing tone
special tone Alerting tone used by somesupplementaryser(cid:2)
vices
stop special tone To stop special tone
alert user Call alerting on the called party
stop alert user To stop call alerting on the called party
busy tone Informing the calling party that the called is
busy
back ring Call alerting on the calling party
stop back ring To stop call alerting on the calling party
CWtone Call waiting tone
stop CWtone To stop Call waiting tone
Between OBCSM initiate tb To initiate TBCSM for call processing
OBCSM to calling disconn To indicate calling party disconnection
and TBCSM TBCSM calling abandon To indicate calling party abandon
TBCSM terminating(cid:2)busy Called party busy detected
to call(cid:2)acceptance Call accepted by the called party
OBCSM called(cid:2)rejected Call refused by the network
called(cid:2)noanswer Called party no answer detected
called(cid:2)suspend Called party suspending detected
called(cid:2)reanswer Called party re(cid:2)answeringdetected
Table (cid:16)(cid:23) the Set of User(cid:2)Networksignals and BCSM(cid:2)BCSM Signals
Service(cid:0) (cid:2)(cid:2)(cid:2)(cid:2)(cid:2)(cid:2)(cid:2)(cid:2)(cid:2)(cid:2)(cid:2)(cid:2) Servicen
InteractionManager
OBCSM OBCSM
(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
(cid:3)(cid:3)(cid:3)(cid:3)(cid:3)(cid:3)
OBCSM
(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0) OBCSM
User(cid:0) Userm
TBCSM
(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0) TBCSM
(cid:3)(cid:3)(cid:3)(cid:3)(cid:3)(cid:3)
TBCSM
TBCSM
Figure (cid:19)(cid:23) Modeling of IN call processing
(cid:28)
Figure (cid:19) is the model of a telecommunication system with m telephone subscribers and n
IN service instances(cid:3) Since the introduction of IN services is independent of the communication
network underneath(cid:4) which does not change the existing communication protocols between users
andBCSMs(cid:4)aswellasbetweendi(cid:24)erentBCSMs(cid:4)theentitiesBCSMs(cid:4)usersandthecommunication
between them aremodeled in the samewayasPOTS(cid:3)At anyspeci(cid:7)c point ofcall processing(cid:4)one
usercanonlycommunicatewithoneBCSM(cid:3)However(cid:4)duetotheexistenceofmulti(cid:2)partycallsand
IN services(cid:4) during the course of call processing(cid:4) one user may communicate with other BCSMs(cid:21)
the exact number of which depends on the number of calls in the system (cid:5)possibly IN(cid:2)calls or
POTS(cid:6)(cid:3)
Theinteractionmanager(cid:5)IM(cid:6)isamanagingprocessovercommunicationsbetweenanumberof
INserviceprocessesandBCSMs(cid:3) Whenitcomestothedynamicsolutiontothefeatureinteraction
(cid:3)
problem(cid:4) theIMplaysan importantrole(cid:3) The detailed function oftheIMis beyondthe scopeof
this paper(cid:3) In the case of services validation and feature interaction detection(cid:4) we simply assume
that(cid:4) for messages from IN services to BCSMs(cid:4) IM acts as a bu(cid:24)er(cid:21) for messages from BCSMs
to IN services(cid:4) IM acts as a broadcaster(cid:3) For simplicity(cid:4) in Section (cid:19) and Section (cid:18)(cid:4) we omit the
process IM(cid:3)
Another assumption in our model is that(cid:4) if a BCSM detects a call processing event at a DP(cid:4)
and the reporting of the event is required by more than one telecommunication service(cid:4) the DP
event will be reported to all those services at the same time(cid:3) In feature interaction detection(cid:4) this
is a useful assumption when we need to analyze how two service instances compete for one signal(cid:3)
AnotherissueishowtomodelthecommunicationsbetweenINservicesandBCSMs(cid:3) Suchcom(cid:2)
munications are based on Intelligent Network Application Protocol (cid:5)INAP(cid:6)(cid:4) the protocol de(cid:7)ned
in Q(cid:3)(cid:16)(cid:10)(cid:10)(cid:15) for the communication between di(cid:24)erent IN entities (cid:9)(cid:16)(cid:12)(cid:3) Basically(cid:4) each INAP message
is composed of an operation name and an operation parameter(cid:3)
As a network protocol(cid:4) the INAP de(cid:7)ned in Q(cid:3)(cid:16)(cid:10)(cid:10)(cid:15) is very complicated(cid:3) A large amount of
messages(cid:4) as well as some data in each message(cid:4) are call control irrelevant (cid:5)for example(cid:4) Activate(cid:2)
ServiceFiltering(cid:6)(cid:3) They are de(cid:7)ned for providing database operation(cid:4) network control and other
management functions such as data security(cid:4) service (cid:7)ltering(cid:4) etc(cid:3)
In our case(cid:4) since we emphasize on the IN service(cid:20)s in(cid:8)uence on the call processing model
(cid:5)represented as the BCSMs(cid:6) for the purpose of service validation(cid:4) call control irrelevant mes(cid:2)
sages(cid:22)parameters are ignored for they have no in(cid:8)uence on the BCSM state transitions(cid:3) By the
word (cid:7)ignore(cid:7)(cid:4) we mean that the action of sending or receiving such messages will not occur in
the IN service(cid:20)s speci(cid:7)cation(cid:3)
Now we can concentrate on the sub(cid:2)set of INAP messages which in(cid:8)uence the BCSM state
transitions(cid:4) i(cid:3)e(cid:3) the INAP messages send from or consumed by BCSMs(cid:3) Even though(cid:4) the large
amountofparametersofeachINAPmessagemakeit impossibletocarryoutanyspeci(cid:7)cationand
validation(cid:3) If we have a thorough look at the parameters which are call processing relevant(cid:4) they
can be categorized as(cid:23)
(cid:16)(cid:3) Parameterstoidentifythecalling party(cid:4)suchascallingPartyNumber(cid:4)callingPartySubaddress(cid:4)
etc(cid:3)
(cid:10)(cid:3) Parameters to identify the called party(cid:4) such as calledPartyNumber(cid:4) originalCalledPartyID(cid:4)
etc(cid:3)
(cid:14)(cid:3) Parametersto identify the call(cid:4) such as callid(cid:3)
(cid:19)(cid:3) Parametersfor billing and charging(cid:4) such as chargeNumber(cid:4) etc(cid:3)
We simplify the INAP message parameter set by assigning one parameter for each type in the
categorization(cid:3) Moreover(cid:4)sincebillingandchargingbehaviorisnotofourconcernnow(cid:4)therelevant
parameters are ignored(cid:3) Each BCSM also carries these three parameters(cid:4) callid(cid:4) callingPartyID(cid:4)
calledPartyID to identify it(cid:3)
(cid:3)
SeeSection (cid:7)(cid:6)(cid:2)(cid:6)(cid:3)(cid:6)
(cid:26)
Currently(cid:4) we havesuccessfully applied our model in specifying andvalidating sometypical IN
(cid:4)
servicesanddetectingsomebenchmarkfeatureinteractions(cid:3) Actually(cid:4)thefeatureinteractionswe
have detected cover the majority interactions ever mentioned in papers available(cid:3) Furthermore(cid:4)
mostofthe featureinteractiondetection methodavailablenowusethese threeparametersor even
less(cid:3)
Considering this(cid:4) we believe our method (cid:7)safely(cid:7) decrease the data complexity we are dealing
with(cid:3) However(cid:4) in case that the screening of some parameters may potentially introduce feature
interactionthatdoesnotreallyexist(cid:4)asolutionwouldbecarefullyaddingthenecessaryparameter
into both the BCSMs and the INAP messages(cid:4) but the basic state transitions in BCSMs remain
unchanged(cid:3) Considering this(cid:4) it will be very easy to expand and enrich our model if necessary(cid:3)
From now on(cid:4) we write I for the set of INAP signals(cid:4) listed in Table (cid:10) are the descriptions of
the INAP message set we use(cid:3) Let(cid:20)s call it sub(cid:2)INAP(cid:3)
(cid:0)(cid:2)(cid:3)(cid:2)(cid:0) An Example on Service Modeling
At the IN distributed function plane(cid:4) telecommunication services can be viewed as information
(cid:8)ows between di(cid:24)erent network entities(cid:3) For service speci(cid:7)cation and validation(cid:4) we only care
about those information (cid:8)ows that in(cid:8)uence the switch call processing procedure(cid:4) i(cid:3)e(cid:3) the INAP
messagesfromBCSMtoINservice(cid:4)whichreportthecallprocessingevent(cid:4)andtheINAPmessages
from IN services to BCSMs(cid:4) which control the state transitions in BCSM(cid:3) Based on this notion(cid:4)
each IN service is modeled by a process with several states(cid:4) and in each state(cid:4) the IN service can
send and receive some INAP messages (cid:5)i(cid:3)e(cid:3) messages from the set sub(cid:2)INAP(cid:6)(cid:3) Such modeling of
IN services is consistent with the idea of separating call control from service control in IN(cid:3) Call
control is performed in switching processes(cid:4) represented as BCSMs(cid:3)
ThekeypointofmodelinganINserviceistodescribehowtheycontrolthe statetransitionsin
BCSMsbycommunicatingwiththem(cid:3) Toachievethisgoal(cid:4)weneedtodecidewhich BCSMstheIN
servicecommunicateswith(cid:4)aswellashow theycommunicate(cid:4)i(cid:3)e(cid:3) atwhichDPthecommunication
happens(cid:4) the INAP message name(cid:4) and parameters(cid:3)
Take the modeling of the call waiting service as an example(cid:3) A CW subscriber y will hear a
call waiting tone when an incoming call arrives at him and he is in connection with someone else(cid:3)
Afterthat(cid:4) hecanchooseto answerthenewincomingcallortoignorethe call waitingtone(cid:3) More
speci(cid:7)cally(cid:4) therearetwotwo(cid:2)partycallsinvolvedin anyCW callscenario(cid:4) the existingtwo(cid:2)party
call and the incoming one(cid:4) with eachbehavior representedasa pairof OBCSMand TBCSM(cid:3) The
two calls interwork with each other(cid:4) by sharing a call party that subscribes to the CW service(cid:3)
The CW service subscriber can be the calling party (cid:5)Case (cid:16)(cid:6) or the called party (cid:5)Case (cid:10)(cid:6) in the
existing call(cid:3)
Based on this analysis(cid:4) we give the modeling of both cases in Figure (cid:18) and Figure (cid:28)(cid:3) User
y is the CW service subscriber(cid:3) CWy is the process describing the behavior of the CW service
subscribedby the user y(cid:3) Since these twoscenariosaresimilarwhen analyzingthe behaviorof the
CW service(cid:4) we use the model in Figure (cid:18) as an example(cid:3)
The PSF speci(cid:7)cation of the CW service is given in Appendix B(cid:3) The CW service has four
states(cid:23)
(cid:16)(cid:3) call waiting null(cid:23) denoted as CW(cid:2)null in the PSF speci(cid:7)cation(cid:21) upon receiving the INAP
messagetoreportacalledpartybusy event(cid:5)r(cid:8)inap(cid:2)TBusy(cid:8)req(cid:9)callxz(cid:9)x(cid:10)(cid:10)(cid:6)(cid:4)theservicetransfers
to the call waiting service active state(cid:3)
(cid:10)(cid:3) call waiting service active(cid:23) denoted as CW(cid:2)active in the PSF speci(cid:7)cation(cid:21) a state where a
terminating busy event has been reported by the TBCSM and the CW service is activated(cid:3)
(cid:4)
SeeSection (cid:7)(cid:6)(cid:3)(cid:8)(cid:7)(cid:6)(cid:4)and(cid:7)(cid:6)(cid:5)(cid:6)
(cid:5)
Aparametermarkedwiththecharacter o isoptional(cid:6)
(cid:15)
Signaling Name in Q(cid:3)(cid:16)(cid:10)(cid:10)(cid:15) Name in our Model Parameters
Direc(cid:2)
tion
(cid:5)
AnalyseInformation inap(cid:2)ai callid(cid:4) calledPartynumber(cid:5)o(cid:6)
ColletInformation inap(cid:2)ci callid
From Connect inap(cid:2)conn callid(cid:4) callingPartyNumber(cid:5)o(cid:6)(cid:4)calledPartyNumber(cid:5)o(cid:6)
Services Continue inap(cid:2)cont callid
to ContinueWithArg inap(cid:2)cwa callid(cid:4) callingPartyNumber(cid:5)o(cid:6)(cid:4)calledPartyNumber(cid:5)o(cid:6)
BCSMs DisconnectLeg inap(cid:2)dl callid(cid:4) calledPartyNumber
InitialCallAttempt inap(cid:2)ica callid(cid:4) callingPartyNumber
OriginateCall inap(cid:2)oc callid(cid:4) callingPartyNumber
ReleaseCall inap(cid:2)rc callid(cid:4) callingPartyNumber(cid:22)calledPartyNumber
Reconnect inap(cid:2)rec callid
SelectRoute inap(cid:2)sr callid(cid:4) callingPartyNumber(cid:5)o(cid:6)(cid:4)calledPartyNumber(cid:5)o(cid:6)
MergeCallSegment inap(cid:2)mgc callid(cid:4) callingPartyNumber(cid:22)calledPartyNumber
MoveCallSegment inap(cid:2)mvc callid
MoveLeg inap(cid:2)ml callid(cid:4) callingPartyNumber(cid:22)calledPartyNumber
SelectFacility inap(cid:2)sf callid
SplitLeg inap(cid:2)sl callid(cid:4) callingPartyNumber(cid:22)calledPartyNumber
AnalysedInformation inap(cid:2)Analysed req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
OriginationAttempt inap(cid:2)OAttempt req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
OriginationAttempt(cid:2) inap(cid:2)OAuthorized req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
Authorized
CollectedInformation inap(cid:2)Collected req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
OTermSeized inap(cid:2)OSeized req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
OAnswer inap(cid:2)OAnswer req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
From OReAnswer inap(cid:2)OReAnswer req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
BCSMs OSuspended inap(cid:2)OSuspend req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
to ODisconnect inap(cid:2)ODisc req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
Services OMidCall inap(cid:2)OMid req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
OCalledPartyBusy inap(cid:2)OBusy req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
ONoAnswer inap(cid:2)ONoAnswer req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
OAbandon inap(cid:2)OAbandon req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
RouteSelectFailure inap(cid:2)RouteFail req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
(cid:27) inap(cid:2)ONull req(cid:22)ind(cid:4) callid(cid:4) callingPartyNumber
TerminationAttempt inap(cid:2)TAttempt req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
TerminationAttempt(cid:2) inap(cid:2)TAuthorized req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
Authorized
FacilitySelectAvailable inap(cid:2)FacilAvail req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
TMidCall inap(cid:2)TMid req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
TNoAnswer inap(cid:2)TNoAnswer req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
TBusy inap(cid:2)TBusy req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
TAbandon inap(cid:2)TAbandon req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
TDisconnect inap(cid:2)TDisc req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
CallAccepted inap(cid:2)CAccept req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
TAnswer inap(cid:2)TAnswer req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
TReAnswer inap(cid:2)TReAnswer req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
TSuspended inap(cid:2)TSuspend req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
(cid:27) inap(cid:2)TNull req(cid:22)ind(cid:4) callid(cid:4) calledPartyNumber
Table (cid:10)(cid:23) The Re(cid:7)ned INAP Message Set in Our Model
(cid:17)
CWy
d(cid:16) d(cid:10) d(cid:14) d(cid:19) d(cid:18)d(cid:28)
userx u(cid:16) OBCSMx(cid:2)y c(cid:16) TBCSMx(cid:2)y
u(cid:10) c(cid:10)
OBCSMy(cid:2)z c(cid:14) TBCSMy(cid:2)z
c(cid:19)
u(cid:14) u(cid:19) u(cid:18) u(cid:28)
usery userz
Figure (cid:18)(cid:23) Modeling of a CW Call(cid:23) Case (cid:16)
CWy
d(cid:16) d(cid:10) d(cid:14) d(cid:19) d(cid:18)d(cid:28)
userx u(cid:16) OBCSMx(cid:2)y c(cid:16) TBCSMx(cid:2)y
u(cid:10) c(cid:10)
TBCSMz(cid:2)y c(cid:14) OBCSMz(cid:2)y
c(cid:19)
u(cid:14) u(cid:19) u(cid:18) u(cid:28)
usery userz
Figure (cid:28)(cid:23) Modeling of a CW Call(cid:23) Case (cid:10)
(cid:14)(cid:3) call waiting(cid:23) denoted as CW(cid:2)cw in the PSF speci(cid:7)cation(cid:21) a state where a call waiting tone
hasbeen sendtotheCWsubscriber(cid:3) TheCWservicecandealwith thefollowingcallevents
in this state(cid:23) (cid:11)ashhook from the CW subscriber(cid:21) onhook from any call party(cid:3)
(cid:19)(cid:3) call on hold(cid:23) denoted as CW(cid:2)ch in the PSF speci(cid:7)cation(cid:21) a state where a call is put on hold
by the CW service instance(cid:3) The CW service can deal with the following call event in this
state(cid:23) (cid:11)ashhook from the CW subscriber(cid:21) onhook from any party(cid:3)
The CW servicecommunicateswith OBCSMx(cid:2)y(cid:4) TBCSMx(cid:2)y(cid:4) OBCSMy(cid:2)z and TBCSMy(cid:2)z(cid:3) The
(cid:6) (cid:7)
INAP messages send by these BCSMs are sent as an indication or as a request (cid:4) depending on
the service requirement(cid:3) If a BCSM sends an INAP message as an indication(cid:4) it will continue call
processing without waiting for the response messages from IN services to decide the subsequent
BCSMtransitions(cid:3) IfaBCSMsendsanINAPmessageasanrequest(cid:4)itwillsuspendcallprocessing
and wait for the response messages from IN services(cid:3)
For example(cid:4) if in the call on hold state(cid:4) the user z onhookswhen he(cid:22)she is on hold(cid:4) an INAP
message inap(cid:2)TDisc(cid:8)req(cid:9)callxz(cid:9)z(cid:10) or inap(cid:2)TSuspend(cid:8)req(cid:9)callxz(cid:9)z(cid:10) will be sent to the CW service by
(cid:8)
TBCSMy(cid:2)z(cid:3)
(cid:2)
(cid:3) Introduction to ACP and PSF
(cid:0)
This section serves as a brief and basic introduction to ACP and PSF(cid:4) which is the base of tools
(cid:0) (cid:0)
to help writing and analyzing speci(cid:7)cations in ACP (cid:3) For more thorough discovery of ACP and
(cid:6)
Themessageformismessage(cid:2)name(cid:3)ind(cid:4) parameter(cid:5)(cid:4) parameter(cid:6)(cid:7) (cid:9)ind istheconstant(cid:6)
(cid:7)
Themessageformismessage(cid:2)name(cid:3)req(cid:4) parameter(cid:5)(cid:4) parameter(cid:6)(cid:7) (cid:9)req istheconstant(cid:6)
(cid:8)
Theexactmessagedepends onthe exactphaseofcallprocessing(cid:6)
(cid:16)(cid:11)