Design a Simple Two Telephone System

1
Design a Simple Two Telephone System

• Concentrating on the control aspects (not data).
• Requirements
• Each phone has a handset that may be picked up
  and replaced, a button that can be used to alert
  the other the other telephone of the desire to
  communicate, and a bell that alerts a user of an
  incoming call.
• A call be terminated by either party.
• Suggested States
• Idle - handset is down, there is no connection.
• Dial - ready to dial
• Ringing - handset is ringing
• Calling - call has been placed, but not yet
  connected
• Talk - connection is established.

2
Informal Description of Tel. Behaviour

• Idle
• 1. Pickup handset(become caller) proceed to
  Dial.
• or 2. Phone rings proceed to ringing.
• Dial
• 1. Replace handset proceed to Idle.
• or 2. Press button proceed to Calling.
• Calling
• 1. Abandon call-replace handset proceed to
  Idle.
• or 2. Called party picks up proceed to Talk.
• Ringing
• 1. Pickup handset(become called) proceed to
  Talk.
• or 2. Caller rings out - receive signal proceed
  to idle.
• Talk
• 1. Replace handset proceed to Idle.
• or 2. Other party disconnects - receive signal
  proceed to Dial.

3
Informal Description of Tel. Behaviour

• Idle
• 1. Pickup handset (become caller) proceed to
  Dial.
• or 2. Phone rings proceed to Ringing.
• Dial
• 1. Replace handset proceed to Idle.
• or 2. Press button generate signal to called
  party proceed to Calling.
• Calling
• 1. Abandon call-replace handset generate a
  signal to called party proceed to Idle.
• or 2. Called party picks up - receive signal
  proceed to Talk.
• Ringing
• 1. Pickup handset(become called) generate a
  signal to caller proceed to Talk.
• or 2. Caller rings out - receive signal proceed
  to Idle
• Talk
• 1. Replace handset generate a signal to other
  party proceed to Idle.
• or 2. Other party disconnects - receive signal
  proceed to Dial.

4
Process Diagram
handset1
handset2
link21
button2
Phone 2
Phone 1
button1
link12
bell1
bell2

• (generic) channel signal
• handset up,down
• button press
• bell ring
• link alert,answer,
• cutoff

5
Parameterised Description of Tel. Behaviour of
Phone n

• Call link from phone n to phone m linkout.
• Call link from phone m to phone n linkin.

6

• Idle
• 1. Pickup handset proceed to Dial.
• or 2. Phone rings on receipt of alert on linkin
  proceed to Ringing.
• Dial
• 1. Replace handset proceed to Idle.
• or 2. Press button generate alert on linkout
  proceed to Calling.
• Calling
• 1. Abandon call-replace handset generate a
  cutoff on linkout proceed to Idle.
• or 2. Called party picks up - receive answer on
  linkin proceed toTalk.
• Ringing
• 1. Pickup handset(become called) generate
  answer on linkout proceed to Talk.
• or 2. Caller rings out - receive cutoff on
  linkin proceed to Idle
• Talk
• 1. Replace handset generate cutoff on linkout
  proceed to Idle.
• or 2. Other party disconnects - receive cutoff
  on linkin proceed to Dial.

7
Message Sequence Charts

• Describe communication in a particular scenario.
• vertical axis
• defines ordering of events
• indication of state
• horizontal axis
• defines message/signal occurrences

8
Message Sequence Charts

• Example Call setup and clear down (1 to 2)
• Phone 1 Phone 2
• Idle
  Idle
• handset1.up
• Dial
• button1.press
• link12.alert
• bell2.ring
• Calling
  Ringing
• handset2.up
• link21.answer
• Talk Talk
• handset1.down
• link12.cutoff
• Idle Dial

9
Message Sequence Charts

• More Examples
• Call setup and clear down (2 to 1)
• 1 calls 2, but rings out before 2 answers.
• 1 picks up handset, but puts down handset before
  dialing.
• Call setup and clear down (1 to 2) but 2
  terminates call.
• 1 calls 2 and 2 calls 1.

10
Message Sequence Charts

• Example 1 calls 2 and 2 calls 1
• Phone 1 Phone 2
• Idle
  Idle
• handset1.up handset2.up
• Dial Dial
• button1.press button2.press
• link12.alert
• link21.alert
• Calling Calling
• DEADLOCK !
• (except to return to Idle)

11
A Solution Communication Protocol

• When a process needs to output a control signal,
  then it does so in parallel with receiving a
  response.
• When a process receives an unsolicited signal, it
  must eventually acknowledge it.
• Why? To prevent infinite blocking of signal
  sender.

12
Telephone Process Specification

• Assume all sends on linkout, all receives on
  linkin.
• Idle
• choose handset.up Dial
• linkin.alert send ack
• ring bell Ringing
• Dial
• choose handset.down Idle
• button.press send alert
• receive response
• if response is ack then Calling
• else
• if response is alert then
• Talk
• Calling
• choose handset.down send cutoff
• receive response
• Idle

13

• Ringing
• choose handset.up send answer
• receive response
• if response is ack then Talk
• else
• if response is cutoff then
• Dial
• linkin.cutoff send ack
• Idle
• Talk
• choose handset.down send cutoff
• receive response
• Idle
• linkin.cutoff send ack
• 
  Dial

14
Message Sequence Charts

• Examples with Acks
• Call setup and clear down (2 to 1)
• 1 calls 2, but rings out before 2 answers.
• 1 picks up handset, but puts down handset before
  dialing.
• Call setup and clear down (1 to 2) but 2
  terminates call.
• 1 calls 2 and 2 calls 1.

15
Inadequacies of FSA/Transition Systems

• Inherently sequential
• no representation of concurrency.
• No outputs
• no explicit way to deal with the generation of
  events.
• No state variables
• e.g. remembering the number dialled.
• No depth/hierarchy/modularity
• needed for structuring large systems.
• State and edge explosion
• no way to deal with interrupts, common
  behaviour.