slide 1 msc and sdl. slide 2 relationship of msc to sdl an msc describes one or more traces of an...
Post on 21-Dec-2015
223 views
TRANSCRIPT
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
Telephone PhoneUserG1
[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
Telephone PhoneUser
Ring
Ringing
NoCall
OnPhone
LiftHandset
Setup
Alert
Connect Active
NearPhone
T
T
Slide 6
Example 1. MSC (no answer)msc doesntAnswerPhone
Telephone PhoneUser
Ring
Ringing
NoCall
Setup
Alert
NoAnswer
NoCall
AwayFromPhone
AwayFromPhone
T
Slide 7
Example 1. Process DiagramsPAGE 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.
T1009650-96/d47
T
ResponderInitiator
Disconnected
ICONreq ICONreq
ICONind ICON ICONind
Wait_For_Resp
Sysdecomposed
msc decomposition msc Sys
Slide 9
Example 2. Block Diagramblock Sys
Initiator ResponderG1
[ICON] [ICONind][ICONreq]
G2 G3
Slide 10
Example 2. Process DiagramsPAGE 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
BidAccept
Bid
BidAccept
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<min,max> allows for specifying iterations
– opt allows for specifying optional sequence
Slide 15
MSC With Message Loss
T1009580-96/d40
T
Initiator Responder
Disconnected
ICONreq
ICONResponder
Wait_For_Resp
IDISind
Disconnected
msc failure
This Message is lost
T1009300-96/d12
T1009310-96/d13
<lost message symbol> ::=
<found message symbol> ::=
Slide 16
MSC Reference
T1009700-96/d52
T
Initiator Medium Responder
data_transmission
data_transmission
Initiator Medium Responder
msc data_transmission
IDATreq(d) MDATreq(DT,data,num) MDATind(DT,data,num) IDATind(d)
MDATind(AK,num) MDATreq(AK,num)
msc ref
T1009460-96/d28
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').
T
T
T
T1009660-96/d48
Initiator Responder
Disconnected
ICONreq ICON ICONind
Wait_For_Resp
alt
IDISind
Disconnected
ICONF ICONresp
ICONconf
Connected
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
T
T
T
T1009670-96/d49
Initiator Responder
Disconnected
ICONreq ICON ICONind
Wait_For_Resp
exc
IDISind
ICONF ICONresp
ICONconf
Connected
msc exception
Disconnected
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 i1waiting
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 Examplemsc doesntAnswerPhone
Telephone PhoneUser
Ring
Ringing
NoCall
Setup
Alert
AwayFromPhone
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
Telephone PhoneUser
Ring
Ringing
DeadlockTimer (3mins)
NoCall
Setup
Alert
NoCall
AwayFromPhone
AwayFromPhone
PAGE 2( 2)PROCESS Telephone
LiftHandset
RESET(AnswerTimer)
Connect
Active
TakeMessage
Connect
RecordingVoicemail
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 examplemsc doesntAnswerPhone
Telephone PhoneUser
Disconnect
Disconnect
Disconnect
Disconnect
Disconnect
Disconnect
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.