GENERATION%20OF%20PROTOCOLS%20FOR%20TELEPHONY%20FEATURES%20FROM%20SCENARIO%20REQUIREMENTS

1
GENERATION OF PROTOCOLSFOR TELEPHONY
FEATURESFROM SCENARIO REQUIREMENTS

• By Luigi Logrippo
• University of Ottawa
• School of Information Technology and Engineering

with contributions of the group
2
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

3
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).

4
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

5
Relevant techniques at different design stages
Stage 1
Stage 2
Stage 3
Requirements, Services Users View
Protocol Procedures
Messages Entities
UCM
LOTOS
MSC
SDL
TTCN
6
Use Case Maps basic notation
OR-fork
OR-join
AND-fork
AND-join
Fork-join
Rendez-vous
Dynamic-stub
Static-stub
7
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.
8
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

9
From UCM to LOTOS a fairly natural
mappingsemi-automatic translation tools are
under development

• Processes
• operator
• Actions
• Processes
• operator
• Synchronization and enable gtgt
• operator

• Stubs
• Or-Fork/Join
• Responsibilities
• Components/maps
• And-Fork/Join
• Rendezvous
• TimeOuts

10
LOTOS Allows to Execute Stage 1

• Scenarios can be derived and validated
• Message Sequence Charts can be derived
• Functional Test Suites can be derived

11
Example rule for translating from UCM to LOTOS
process P2a,b . r1 ( r2 stop
r3 stop) gtgt r4 endproc
process P1a,b . ( r1 r2
r1 r3 ..) endproc
12
Example rule for translatingfrom UCM to
LOTOS(cont)
process Examplea,b .
r_i Stuba,b gtgt
r_o . endproc process Stuba,b
P1a,b
P2a,b endproc process P1a,b
endproc process P2a,b endproc
r_o
r2
or
r3
Plug-in p1
Plug-in p2
13
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

14
Example Unbound UCM for WIN LBSSFAM Status
Change
MS Mobile Station MSC Mobile Switching Center
FAM Fleet and Asset Management SCP Service
Control Point
Pull On demand positioning, Push Periodic
update
Notify FAM notify SCP of change of user status
15
Example LOTOS spec. automatically generate from
UCMS
process FAM_Status_Changestart,resp,end
exit start !PowerOn resp !GetProfile (
resp !v_Profile sub_FAM_Status_Change_start,res
p,end resp !h_Profile sub_FAM_Status_Cha
nge_start,resp,end ) start
!SetInactive sub_FAM_Status_Change_start,resp,e
nd 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,en
d exit resp !NotifyFAM resp
!SetStatus (sub_FAM_Status_Change_1start,resp,e
nd resp !SetupMonitoring resp
!SendLoc resp !UpdLoc sub_FAM_Status_Change_1
start,resp,end ) endproc process
sub_FAM_Status_Change_1start,resp,end
exit resp !NotifySV end exit endproc endpro
c
16
Example LOTOS Scenarios, automatically generated
from UCMs
process scenario scenario,start,end,resp exit
start!PowerOn resp!GetProfile res
p!h_Profile resp!NotifyFAM resp!SetStatus
resp!SetupMonitoring resp!SendLoc resp!
UpdLoc resp!NotifySV end
scenario exit endproc
17
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).

18
Bound UCM between Stages 1 and 2
19
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

20
Example Bound UCM for LBSS WINFAM Status Change
Supervisor
SCP(FAM)
MS
MSC
SetActive
Pull
NotifyFAM
NotifySV
SetInactive
PowerOff
Push
UpdLoc
GetProfile
PowerOn
VLR
MPC
V_Profile
HLR
SetupMonitoring
SendLoc
H_Profile
21
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
22
Stage 2 Message Sequence Chart Notation (MSCs)
for WIN LBSS FAM Status Change
23
Requirements
UCMNAV
LOLA
lotos2msc
24
Stage 3 SDL

• ITU-Ts 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

25
Our method
Requirements
Architectural Model
UCM
Stage 1
scenarios
LOTOS
MSCs
scenarios
scenarios
Stage 2
SDL
Stage 3
SDL
Test Cases (TTCN)
Implementation
26
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

27
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

28
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).

29
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)

30
Finding Patterns authentication
Use Case Maps System Descriptions
31
A Summary of the Authentication Pattern

• 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.

32
Pattern Language

• A collection of patterns that build on each other
  to generate a system

Starting pattern
potential sequences in which the patterns occur
exchanges of data between two patterns
33
Reusability
Common Solutions for Protocol Design Problems
describes
Patterns for Mobility and Radio Resource
Management
34
Approach for Pattern Reuse
2nd Development Cycle
1st Development Cycle
Requirements
Capture (Stage 1)
Analysis (Stage 2)
Design (Stage 2)
35
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

36
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.

37
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)

38
Feature Interaction Resolution

• Subject of new project with Jo Atlee and Mitel
• Towards architectures that tolerate and resolve FI

39
Towards IP

• IP telephony protocols are our current target
• Working on validation aspects of telephony
  systems based on SIP and CPL

40
In few words

• Towards a unified development process
• Pragmatic approach based on sound theory
• But there are missing steps, missing
  components...