Slide 1 MSC and SDL

Slide 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 service, 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.

Slide 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 or service in SDL. An action in MSC maps to a task in SDL. Decomposed MSCs can be used to represent –Processes decomposed into services –BLOCKs decomposed into processes –Blocks decomposed into blocks –System decomposed into blocks

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

Slide 5 Example 1. MSC (answer) msc doesntAnswerPhone TelephonePhoneUser Ring Ringing NoCall OnPhone LiftHandset Setup Alert Connect Active NearPhone T T

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

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

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

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

Slide 10 Example 2. Process Diagrams PAGE 1( 1) PROCESS Initiator Disconnected ICONreq setting T ICON Wait For Resp PAGE 1( 1) PROCESS Responder Disconnected ICON ICONind Wait For Resp

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

Slide 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 Info SetupAck Info

Slide 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 Bid BidAccept Same State

Slide 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 allows for specifying iterations –opt allows for specifying optional sequence

Slide 15 MSC With Message Loss This Message is lost ::=

Slide 16 MSC Reference MSC Reference Symbol

Slide 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').

Slide 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

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

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

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

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

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

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

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

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

Slide 27 Livelock example msc doesntAnswerPhone TelephonePhoneUser Disconnect

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