1 / 28

MSC and SDL

MSC and SDL. Relationship of MSC to SDL. An MSC describes one or more traces of an SDL system specification. An entity in MSC may map to a system, block or process in SDL. MSCs are usually used to help create SDLs, and debug them.

marcie
Download Presentation

MSC and SDL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MSC and SDL

  2. Relationship of MSC to SDL • An MSC describes one or more traces of an SDL system specification. • An entity in MSC may map to a system, block or process in SDL. • MSCs are usually used to help create SDLs, and debug them. • One MSC only shows partial traces of the execution of an SDL, although it is possible to generate a set of MSCs to completely define a process. • MSC are normally generated for the “standard cases”, and typical error scenarios.

  3. Mapping from MSC to SDL • Instance Names should remain the same, so that mapping is one to one. • A Message in MSC maps to a Signals in SDL. • A Conditions in MSC maps to a state in processes in SDL. • An action in MSC maps to a task in SDL. • Decomposed MSCs can be used to represent: • BLOCKs decomposed into processes • Blocks decomposed into blocks • System decomposed into blocks

  4. Example 1. Mapping conditions to states - Block Diagram block phone [Ring, Dialtone, Engaged] [Setup, Disconnect, Connect] G1 G2 Telephone PhoneUser G3 G4 [Alert, NoAnswer, Disconnect, Connect] [LiftHandset, ReplaceHandset]

  5. Setup T Alert T Ringing Example 1. MSC (answer) msc doAnswerPhone Telephone PhoneUser NearPhone NoCall Ring LiftHandset OnPhone Connect Active

  6. Setup Alert T Ringing Example 1. MSC (no answer) msc doesntAnswerPhone Telephone PhoneUser AwayFromPhone NoCall Ring AwayFromPhone NoAnswer NoCall

  7. PROCESS Telephone PAGE 2( 2) TIMER AnswerTimer; Ringing Example 1. Process Diagrams PROCESS Telephone PAGE 1( 2) NoCall Setup LiftHandset AnswerTimer SET(3mins, AnswerTimer) RESET (AnswerTimer) NoAnswer Ring Connect NoCall Alert Active Ringing

  8. Example 2. Mapping from MSC with Sub MSCs to SDL.

  9. Initiator Example 2. Block Diagram block Sys [ICONreq] [ICONind] [ICON] Responder G3 G1 G2

  10. Disconnected ICON ICONind Wait_For_Resp ICON Wait_For_Resp Example 2. Process Diagrams PAGE 1( 1) PAGE 1( 1) PROCESS Responder PROCESS Initiator Disconnected ICONreq setting T

  11. Adding States to a Stateless MSC Designing a protocol involves identifying the following : • The Functional Entities • The messages, and contents of messages. • The message sequences using MSC • States and Tasks on MSC • Creating SDL process diagrams from MSCs • Analysing and refining the protocol.

  12. Identifying States on MSC • SDL processes wait in a state until an event occurs and then react to that event. • Therefore add empty conditions (states) to the MSC just before a message is received. • Add actions after a message has been received. SetupAck SetupAck Info Info

  13. Look for repeated sequences • Once you have added the empty states, try to identify repeated sequences. If an entity responds to a message of the same type in the same way, it is most likely the same state. Bid BidAccept BidAccept Same State Bid BidAccept BidAccept

  14. Advanced MSC Concepts • Lost Message & Found Message • MSC References (allow for reuse of MSCs) • Inline Expressions • alt allows for specifying alternative sequence • exc allows for specifying exception sequence • par allows for specifying parallel sequence • loop<min,max> allows for specifying iterations • opt allows for specifying optional sequence

  15. MSC With Message Loss This Message is lost <lost message symbol> ::= <found message symbol> ::=

  16. MSC Reference MSC Reference Symbol

  17. Alternative Inline Expression • In this example the successful connection case is combined with the failure case within one MSC by means of the alternative inline expression (MSC 'alternative').

  18. Exception Inline Expression • Within MSC 'exception'the same situation as on previous slide is described by means of an equivalent exception inline expression. • In this case either events inside block are executed and MSC finished or rest of MSC is executed. • Opt inline expression describes situation where part of MSC is optional

  19. Branching on MSC • There is no standard way to show that a branching decision in the logic of a functional entity has occurred on an MSC. • It is recommended that when a branch has occurred in an SDL process that a comment be attached on the MSC.

  20. Waiting Branching on MSC PROCESS i1 PAGE 1( 1) msc subsequent timeouts waiting i1 wait Waiting wait (1/2 hour) count := count +1; count := count +1 count < 3 count < 3 No Yes wait (1/2 hour) set(now + 1/2 hour,wait); Idle waiting

  21. Using Message Sequence Charts for validation • Message Sequence Charts can be used to identify the following kinds of errors: • Deadlock. • Unreachable states. • Livelock. • Incorrect behaviour.

  22. Deadlock. • Deadlock is a scenario, whereby state machines cannot progress to another state because they are waiting for an event that will never occur. • Timers can be used detect deadlock in most protocols.

  23. PROCESS Telephone PAGE 2( 2) Ringing LiftHandset Setup Connect Alert Ringing Active Deadlock Example msc doesntAnswerPhone Telephone PhoneUser AwayFromPhone NoCall Ring AwayFromPhone Won’t progress beyond this point because its waiting for a signal that wont come.

  24. PROCESS Telephone PAGE 2( 2) Ringing TakeMessage Setup Connect Alert Ringing Recording Voicemail NoCall NoCall Unreachable States msc doesntAnswerPhone Telephone PhoneUser AwayFromPhone NoCall LiftHandset * DeadlockTimer (3mins) RESET (AnswerTimer) DeadlockTimer Ring AwayFromPhone Connect Active

  25. Unreachable States • Prolific use of timers may prevent deadlocks, but their use may result in states that are never reached if the specification is faulty. • In the previous example the “Take Message” message is never sent and so the telephone never enters the TakeMessage state. • Need to know all possible combinations before it can be shown that a state is unreachable. • In the previous example the error will propagate because a generic deadlock timer expired that was unaware of the state specific actions to take at this point.

  26. Livelock • livelock is a scenario whereby sequences of messages is repeated in an endless loop. • Without appropriate safety mechanisms livelock can consume all of the resources in a network • Livelocks can occur depending on the value of data, such as an entity forwarding a message to itself • Loop counts are sometimes used in protocols to detect livelock, such as the use of steering digits in the telephone network.

  27. Disconnect Disconnect Disconnect Disconnect Livelock example msc doesntAnswerPhone Telephone PhoneUser Disconnect Disconnect Disconnect

  28. Poor specification • This kind of error cannot be automated, unless the requirements can be modeled in a formal language. • A better alternative is to animate a service specification using Message Sequence Charts , allowing the service designer to confirm that the specification is correct. • Even without automated validation tools, the service designer should always validate state machine descriptions for the “normal case” using message sequence charts.

More Related