GENERATION%20OF%20PROTOCOLS%20FOR%20TELEPHONY%20FEATURES%20FROM%20SCENARIO%20REQUIREMENTS - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

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

Description:

LOLA. lotos2msc. MSC. traces. LOTOS spec. scenarios. UCM. Stage 3: SDL ... Analysis Model. Bound Use Case Maps. Patterns for. Mobility and. Radio Resource. Management ... – PowerPoint PPT presentation

Number of Views:20
Avg rating:3.0/5.0
Slides: 41
Provided by: siteUo8
Learn more at: http://www.site.uottawa.ca
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

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


1
GENERATION OF PROTOCOLS FOR TELEPHONY
FEATURES FROM 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 1 A semi-formal notation
for presenting sequences of abstract
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
mapping semi-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 translating from 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 LBSS FAM 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 WIN FAM 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...
About PowerShow.com