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

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

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

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

6. Stage 1 Requirements, Services & User’s View Stage 2Stage 3 Relevant techniques at different design stages UCM MSC LOTOS SDL TTCN Messages & Entities Protocol & Procedures

7. Use Case Maps basic notation OR-forkOR-joinAND-forkAND-join Fork-joinRendez-vousDynamic-stubStatic-stub

8. 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. [Switching Center] [Resource Manager] InitiateCall Allocate Resources Timer Failure [Timeout] GetAnswer GetNoAnswer Status Reported

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

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

11. LOTOS Allows to Execute Stage 1 Scenarios can be derived and validated Message Sequence Charts can be derived Functional Test Suites can be derived

12. Example : rule for translating from UCM to LOTOS process P1[a,b]:= …. ( r1; r2; … [ ] r1; r3; …..) endproc r1 r2 r3 r1 r2 r3 r4 process P2[a,b]:= …. r1; ( r2; stop ||| r3; stop) >> r4; …… endproc

13. Example: rule for translating from 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 r1 r2 r3 r4 r2 r3 or Plug-in p1 Plug-in p2 r_i r_o r1

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

15. Example: Unbound UCM for WIN LBSS FAM 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

16. 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 Example: LOTOS spec. automatically generate from UCMS

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

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

19. SystemUser Switching Center Resource Manager InitiateCall Allocate Resources Timer Failure [Timeout] GetAnswer GetNoAnswer Status Reported Bound UCM between Stages 1 and 2

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

21. Example: Bound UCM for LBSS WIN FAM 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

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

23. Stage 2: Message Sequence Chart Notation (MSCs) for WIN LBSS– FAM Status Change MSC SV MPC FAM HLR VLR MS getProfile profile notifyFAM PowerOn notifySV Location SetupMonitoring profile getProfile

24. Requirements UCMNAV ucm2lotosucm2scenarios LOLA lotos2msc MSC traces LOTOS specscenarios UCM

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

26. Our method Stage 1 Stage 2 Stage 3 Requirements SDL MSCs Test Cases (TTCN)Implementation Architectural Model UCM LOTOS scenarios

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

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

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

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

31. Finding Patterns: authentication GSM E2E2 S a c b E1E1 e E2E2 S a c b E1E1 d WATM e E3E3 ANSI-41 E2E2 S a e E1E1 d b c d E3E3 IMT-2000 E2E2 S a c b E1E1 d e E3E3 Use Case Maps System Descriptions Stub Name Problem Context Forces Solution Resulting Context Common Behavior Grap. Spec. of the Pattern Solution E2E2 S a c b E1E1 d e E2E2 S a c b E1E1 d e Pattern Form Plug-in

32. A Summary of the Authentication Pattern S Auth : Start Authentication E 2 Auth :end SuccessfulAuth. E 1 Auth :end UnsuccessfulAuth. [a1]: [Auth. Success] [a2] : [Auth. Denied] sAI:send Authentication Information aAA:applyAuth. Algorithm cAR :check Authentication Result nAD :notify Access Denied nS:notify Success Legend : S Auth [a1] sAI [a2] E 1 Auth E 2 nAD 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.

33. A collection of patterns that build on each other to generate a system Pattern Language Starting pattern potential sequences in which the patterns occur exchanges of data between two patterns

34. Reusability Common Solutions for Protocol Design Problems reuses 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 Current WmATMSwitch InitiateRegREQ (user_A,info_A,zone_1) AuthSuccess (user_A, zone_1) (user_A,zone_1) AuthUsrResult (user_A, zone_1,hlr_1,r) Home Database AuthUsr (user _A, zone_1,hlr_1,r) describes Patterns for Mobility and Radio Resource Management

35. Approach for Pattern Reuse Requirements Model Unbound Use Case Maps Design (Stage 2) Analysis (Stage 2) Requirements Capture (Stage 1) Design Model LOTOS 1 st Development Cycle 2 nd Development Cycle Scenario Model Message Sequence Charts Analysis Model Bound Use Case Maps Patterns for Mobility and Radio Resource Management

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

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

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

39. Feature Interaction Resolution Subject of new project with Jo Atlee and Mitel Towards architectures that tolerate and resolve FI

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

41. In few words: Towards a unified development process Pragmatic approach based on sound theory But there are missing steps, missing components...