GENERATION OF PROTOCOLS FOR TELEPHONY FEATURES FROM SCENARIO REQUIREMENTS By Luigi Logrippo University of Ottawa School of Information Technology and.

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