generation of protocols for telephony features from scenario requirements by luigi logrippo...
TRANSCRIPT
GENERATION OF PROTOCOLSFOR TELEPHONY FEATURES
FROM SCENARIO REQUIREMENTS
By Luigi Logrippo
University of Ottawa
School of Information Technology and Engineering
with contributions of the group
The three stages of the standardization process in telecom
• Stage 1: Specification of requirements, main functionalities, user view
• Stage 2: Identification of components and messages. Protocol scenarios expressed in the form of Message Sequence Charts (MSCs)
• Stage 3: Detailed description of the protocol
Issues
• How to guarantee a disciplined, high-quality, development process among the three stages
• How to specify properly each stage
• How to guarantee consistency and traceability among the stages
• How to obtain automatically implementations from Stage 3
• How to derive test cases from all stages (with R.L. Probert)
• How to do design-time performance assessments (work by Prof. M. Woodside, Carleton University).
Importance of a correctly specified protocol
• Implementation is simplified (and possibly even automated)
• Reduced reliance on testing, last minute ‘fixes’
• Interworking between different implementations has a better chance
• Updates can be traced to affected code
Stage 1Requirements,Services &User’s View
Stage 2 Stage 3
Relevant techniques at different design stages
UCM
MSC
LOTOS
SDL
TTCN
Messages& Entities
Protocol &Procedures
Use Case Maps basic notation
OR-fork OR-join AND-fork AND-join
Fork-join Rendez-vous Dynamic-stubStatic-stub
Use Case Maps for Stage 1A semi-formal notation for presenting sequences ofabstract responsibilities in distributed systems.
Matches well the abstract descriptions of Stage 1.Assignment of responsibilities to components to be added in stage 2.
[Switching Center]
[Resource Manager]
InitiateCall
AllocateResources Timer
Failure
[Timeout]
GetAnswer
GetNoAnswerStatusReported
LOTOS
• Language of Temporal Ordering Specification
• Formal Description Technique
• Process Algebra Properties
• Interprocess Synchronization (rendezvous)
• Appropriate for systems prototyping and validation
• Several possible specification/representation styles
• Higher level languages that map into LOTOS have been defined
• Flexible representation of system structures
• Validation tools
From UCM to LOTOS: a fairly natural mapping
semi-automatic translation tools are under development
Stubs
Or-Fork/Join
Responsibilities
Components/maps
And-Fork/Join
Rendezvous
TimeOuts
Processes
[ ] operator
Actions
Processes
||| operator
Synchronization ||| and enable >>
[ ] operator
LOTOS Allows to Execute Stage 1
• Scenarios can be derived and validated
• Message Sequence Charts can be derived
• Functional Test Suites can be derived
Example : rule for translating from UCM to LOTOS
process P1[a,b]:=….
( r1;r2;…[ ]r1;r3;
…..)endproc
r1r2
r3
r1
r2
r3
r4
process P2[a,b]:=…. r1;
( r2;stop
||| r3;stop)>>r4;
……endproc
Example: rule for translatingfrom UCM to LOTOS(cont) process Example[a,b]:=
…. r_i; Stub[a,b] >> r_o; ….endproc
process Stub[a,b]:= P1[a,b] [ ] P2[a,b]endproc
process P1[a,b]:= …endproc
process P2[a,b]:= …endproc
r1r2
r3
r4r2
r3or
Plug-in p1 Plug-in p2
r_i r_o
r1
Scenarios Generated From Unbound UCMs
• All possible scenarios that can be obtained by visiting path segments a limited number of times (user-defined)
• All generated scenarios should run against the specification successfully
• These scenarios, generated at the design stage, can be reused at the implementation stage
Example: Unbound UCM for WIN LBSSFAM Status Change
[MS] [MSC] [SCP(FAM)]
[VLR]
[HLR]
[MPC]
[Supervisor]SetActive
SetInactive
PowerOff
PowerOn GetProfile
V_Profile
H_Profile
NotifyFAM [Pull]
[Push]
SetupMonitoring SendLoc
UpdLoc
NotifySV
MS: Mobile Station
MSC: Mobile Switching Center
FAM: Fleet and Asset Management
SCP: Service Control Point
Notify FAM: notify SCP of change of user status Pull: On demand positioning, Push: Periodic update
process FAM_Status_Change[start,resp,end] :exit:=
start !PowerOn;
resp !GetProfile;
( resp !v_Profile;
sub_FAM_Status_Change_[start,resp,end]
[ ]
resp !h_Profile;
sub_FAM_Status_Change_[start,resp,end]
)
[ ]
start !SetInactive;
sub_FAM_Status_Change_[start,resp,end]
[ ]
start !PowerOff;
sub_FAM_Status_Change_[start,resp,end]
[ ]
start !SetActive;
sub_FAM_Status_Change_[start,resp,end]
where
process sub_FAM_Status_Change_[start,resp,end] :exit:=
resp !NotifyFAM;
resp !SetStatus;
(sub_FAM_Status_Change_1[start,resp,end]
[ ]
resp !SetupMonitoring;
resp !SendLoc;
resp !UpdLoc;
sub_FAM_Status_Change_1[start,resp,end]
)
endproc
process sub_FAM_Status_Change_1[start,resp,end] :exit:=
resp !NotifySV;
end; exit
endproc
endproc
Example: LOTOS spec. automatically generate from UCMS
process scenario [scenario,start,end,resp]: exit :=
start!PowerOn;
resp!GetProfile;
resp!h_Profile;
resp!NotifyFAM;
resp!SetStatus;
resp!SetupMonitoring;
resp!SendLoc;
resp!UpdLoc;
resp!NotifySV;
end;
scenario; exit
endproc
Example: LOTOS Scenarios, automatically generated from UCMs
Stage 2
• In Stage 2, more detailed information is provided about system architecture, actions performed and message exchanges between components.
• That information is added to the UCM as components (bounding) and LOTOS instructions (mapping).
• This leads to a more detailed specification that enables the generation of scenario-based Message Sequence Charts (MSC).
SystemUser
Switching Center
Resource Manager
InitiateCall
AllocateResources Timer
Failure
[Timeout]
GetAnswer
GetNoAnswerStatusReported
Bound UCM between Stages 1 and 2
In Stage 1, LOTOS Allows to
• Derive Scenarios
• Validate the Specification
In Stage 2, LOTOS Allows to
• Derive Message Sequence Charts
• Derive Functional Test Suites
Example: Bound UCM for LBSS WINFAM Status Change
MS MSC SCP(FAM)
VLR
HLR
MPC
Supervisor
SetActive
SetInactive
PowerOff
PowerOn GetProfile
V_Profile
H_Profile
NotifyFAM [Pull]
[Push]
SetupMonitoring SendLoc
UpdLoc
NotifySV
A Corresponding Trace
ms_to_msc ! ms ! msc ! poweron;
msc_to_vlr ! msc ! vlr ! getprofile;
vlr_to_hlr ! vlr ! hlr ! getprofile;
hlr_to_vlr ! hlr ! vlr ! profile;
vlr_to_msc ! vlr ! msc ! profile;
msc_to_fam ! msc ! fam ! notifyfam;
resp ! setstatus;
fam_to_mpc ! fam ! mpc ! setupmonitoring;
resp ! getlocation;
mpc_to_fam ! mpc ! fam ! location;
resp ! updloc;
fam_to_sv ! fam ! sv ! notifysv;
Stage 2: Message Sequence Chart Notation (MSCs) for WIN LBSS– FAM Status Change
MSCMSC
SVSV
MPCMPC
FAMFAM
HLRHLR
VLRVLR
MSMS
getProfile
profile
notifyFAM
PowerOn
notifySV
Location
SetupMonitoring
profile
getProfile
Requirements
UCMNAV
ucm2lotos ucm2scenarios
LOLA
lotos2msc
MSC
traces
LOTOS spec scenarios
UCM
Stage 3: SDL
• ITU-T’s Specification and Description Language
• Appropriate for detailed specification of
architectures and protocols
• MSCs can be input to SDL and validated
• Code can be obtained from SDL
• Test suites can be obtained from SDL
Our method
Stage 1
Stage 2
Stage 3
Requirements
SDL
SDL
MSCs
Test Cases (TTCN) Implementation
ArchitecturalModel
UCM
LOTOSscenarios
scenariosscenarios
Evaluation of method
• Not limited to standards.– can be applied generally to software design– and probably also to hardware design, with
adaptations
• Intensive and rigorous at the design level
• Simplifies significantly implementation, testing and probably maintenance
The WIN project (NortelNetworks)
• WIN: Wireless Intelligent Network
• New NA wireless standard including many sophisticated features: Pre-pay Call, Location-Based Charging
• WIN features are being specified (UCM, LOTOS, SDL) and validated
• Results fed back to standards committees and industrial partner
New PBX (Mitel)different type of system, but related method
• UCMs and UCMNav being used by industrial partner to specify features
• Translation into LOTOS
• Analysis of scenarios by using LOTOS tools to look for potential problems before implementation starts
• SDL tools also used for test case generation, leading to executable functional tests (in collaboration with R.L. Probert).
Patterns: towards an architectural approach to telecom software engineering
• Focus on common solutions to recurring problems regarding mobile wireless communication systems– requirements and analysis stages
• Capture common behavior and architectural elements– documentation for legacy systems– source of initial design decisions for new systems (Wireless IP, IMT-
2000)
• Patterns can be validated (e.g. by using LOTOS methods)
Finding Patterns: authentication
GSM
E2
S
a
cb
E1
e
E2
Sa
cb
E1
d
WATM
e
E3
ANSI-41
E2
S
a
e
E1
d
bc
d
E3
IMT-2000
E2
S
a
cb
E1
de
E3
Use Case Maps System Descriptions
<S,a,b,c,(e,E1) [ ](d,E2)>
Stub
NameProblemContextForcesSolutionResulting Context
Common Behavior
Grap. Spec. of the Pattern Solution
E2
Sa
cb
E1
de
E2
Sa
cb
E1
de
Pattern Form
Plug-in
A Summary of the Authentication Pattern
SAuth: Start Authentication
E2Auth : end Successful Auth.
E1Auth
: end Unsuccessful Auth.
[a1]: [Auth. Success][a2]: [Auth. Denied]sAI : send Authentication InformationaAA: apply Auth. AlgorithmcAR: check Authentication Result
nAD : notify Access DeniednS : notify Success
Legend :
SAuth
[a1]
sAI
[a2]
E1AuthE2
AuthnAD
aAA
cAR
nS
• Problem: Preventing unauthorized or fraudulent access to cellular networks by mobile stations illegally programmed with counterfeit identification and electronic serial number.
• Solution: Perform an authentication operation in both the mobile station and the network sides based on an encryption algorithm and a secret key number.
• A collection of patterns that build on each other to generate a system
Pattern Language
Authentication
LocationRegistration Inter-system
HandoffExecution
HandoffFailureActions
Paging
Radio Resource ManagementMobility Management
Home andVisitor
Databases
Ciphering
SecurityDatabase
AnchorMobile
Switching Center
ReleasingResources
TemporaryIdentification
HandoffDecision
Starting patternpotential sequences in which the patterns occurexchanges of data between two patterns
Reusability
Common Solutions for Protocol Design
Problems
reuses
E’3
R3
R1
(a) Unbound UCM
S’1
R2
[l12] [l22]
E’3
R3
R1
(b) Bound UCM
S’1
R2
[l12] [l22]
Component1
Component2
Use Case Maps
System Description with Different Techniques
LOTOS
Message Sequence Charts
(WmATMSwitch [ms_to_wsh, wsh_to_link, vlr_to_wsh] (zone_2)|[vlr_to_wsh]|VLR [vlr_to_wsh] (vlr_2, InitialVLRSet2))
_A, zone_1,hlr_1,info_A)AuthNetResult (
InitiateRegCONF
MobileStation CurrentWmATMSwitch
InitiateRegREQ (user_A,info_A,zone_1)
AuthSuccess(user_A, zone_1)
(user_A,zone_1)
AuthUsrResult (user_A, zone_1,hlr_1,r)
HomeDatabase
AuthUsr ( useruser_A, zone_1,hlr_1,r)
describes
Patterns for Mobility
and Radio Resource Management
Approach for Pattern Reuse
Requirements ModelUnbound Use Case Maps
Design (Stage 2)
Analysis (Stage 2)
RequirementsCapture (Stage 1)
Design ModelLOTOS
1st Development Cycle2nd Development Cycle
Scenario ModelMessage SequenceCharts
Analysis ModelBound Use Case Maps
Patterns for Mobility and
Radio ResourceManagement
Feature Interaction Detection and Resolution
• Do telephony features being designed interact with each other in any way?
• Working on this problem for quite a number of years
• A number of approaches developed
• Participated in two international Feature Interaction contexts– Second prize in both
• New CITO project with Joanne Atlee of Waterloo now starting
Feature Interaction Screening
• Techniques to detect the possibility of feature interaction– by static analysis of the system specifications
• A number of very effective approaches developed – two Master theses, other work not yet documented
• from approaches based on Use Case Map specification• to approaches based on logic: specification of feature pre- and
post-conditions and detection of inconsistencies.
Feature Interaction Detection
• Massive job, requires extensive state exploration
• But the number of possibilities to try is reduced by previous efficient screening
• Here too, a number of approaches developed (one Master, one PhD thesis, other methods not yet documented)
Feature Interaction Resolution
• Subject of new project with Jo Atlee and Mitel
• Towards architectures that tolerate and resolve FI
Towards IP
• IP telephony protocols are our current target
• Working on validation aspects of telephony systems based on SIP and CPL
In few words:
• Towards a unified development process
• Pragmatic approach based on sound theory
• But there are missing steps, missing components...