Transcript A Telephone Switching System -

A Telephone Switching System
-- A Pattern Language
Robert Hanmer
Lucent Technologies
Naperville, Illinois, USA
[email protected]
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 1
Objectives
• At the end of this seminar you will:
– Be able to explain the difference between patterns and pattern languages
– Be able to describe the primary internal functions of a telephone
switching systems
– Be able to explain the “half call model”
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 2
Outline
• Background
– Patterns & pattern languages
– Telecommunications
•
•
•
•
Patterns of a Telecom System
The next step to building the system
Summary
References
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 3
Patterns
• A form of documentation for recurring solutions
• A pattern describes A solution to a problem and its relevant
context
• A pattern both describes a particular example and also provides
enough information to recreate it
• A pattern discusses and balances the tradeoffs present in the
problem
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 4
Pattern Languages
• A collection of patterns that work together to address a larger
problem.
• Pattern languages are generative in that they are able to
generate structures larger than the sum of the individual
patterns.
• Design is accomplished by constructing in our minds the
language needed for the problem at hand.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 5
How to use pattern languages
• Create a collection of patterns that are related to the problems
at hand.
• Identify the “biggest” or “highest level” starting point.
• Work through the patterns in sequence.
– Each pattern when applied will introduce a new context and new
problems.
– Resolve these problems by applying other patterns in the collection that
you’ve identified.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 6
Completeness
• Pattern languages are complete in 2 ways:
• Morphological:
– The patterns in a language, when applied as a whole, resolve the internal
forces that the individual patterns introduce.
• Functional:
– The patterns in a language create a whole something.
– That might be a whole component or a whole system.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 7
How to find patterns and pattern languages
• The Pattern Almanac
– Linda Rising’s book that indexes patterns up to mid-2000.
• Check for proceedings from the various PLoP conferences
– SugarLoaf PLoP, EuroPLoP, KoalaPLoP, VikingPLoP, PLoP
• Check for books
– Wide range of books available
•
•
•
•
•
Analysis
Business
Language/component specific
General patterns
Object patterns
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 8
Telecom Systems
• The basic problem
– Telephones introduced in late-1800’s.
– Initially each telephone was directly connected to another site.
• This led to an explosion of direct connections (n*(n-1)/2)
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 9
Telecom Systems (2)
• This lead to the need to “switch” the connections.
• Over the years many different ways to request (or “signal”) a certain
endpoint
–
–
–
–
Voice commands to live operator
Rotary dial
Touch tone
IP signaling
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 10
Telecom Systems (3)
• And many different ways to make the desired connections
– Humans and patch cords
– Electromechanical methods
– Computer controlled systems
• All have the goal of connecting two parties together so that
they can communicate
B
A
A
B
B
B
A
Traffic Flow
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 11
More about Telecom Systems
• Equipment Vendors design and build systems to exchange
information (such as data packets or telephone calls).
– Money made by sale of equipment and services to Carriers.
• Carriers buy these systems, install them and make the services
available to their Customers.
– Money made by selling services to customers.
• Customers use the systems to place telephone calls to conduct
their business or personal lives.
– Spend money with the carriers to contact their friends and business
colleagues.
• Note that all three have different interests.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 12
Patterns of a Telecom System
• Abstract
– The Switching pattern language discusses the high level components of
a telephone (or data) switching system. The system is contains the
elements required to create a highly available, self-maintaining
switching system.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 13
Patterns of a Telecom System
• Language Map
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
Fault Management
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 14
Patterns of a Telecom System
• Language Description
– Once the need for a switching system is identified, the first question to
ask is how should the call processing (i.e. application) functions be
organized. Half Call describes how the system should efficiently use a
“half call” model. To provide for flexibility and centralized switching,
Billing adds in the ability to keep the records required to bill the
customer for the service provided. A Measurements subsystem helps the
switch operator see how effectively they are making use of the
switching system. System Integrity monitors the system and invokes
Maintenance Software and Fault Management if errors are detected.
System Integrity also provides resources to Self Protection to aid in the
system handling periods of too many requests (overload). Switch Data
Store discusses the switch database that stores port to customer
mappings.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 15
Call Processing Functionality Then
• “Please connect me with Gloria.”
• Request interpreted by a human operator who then connected
wires to complete the call.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 16
Call Processing Functionality Now
• “1 312 555 1234”
• A computer processes the address digits and makes the
connections automatically.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 17
Call Processing Functionality
• How do we design the software to process the connection
requests?
• Considerations:
– We might have to vary the style of addressing and signaling we use
• Different protocols
• Different standards
– We want to be able to have many simultaneous connections
– We want it to be very flexible
– We want it to be efficient
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 18
Call Processing Functionality (2)
• We could use a single object to process both ends of the call
inside our system.
Switching Node
Call
Entity
• But when we need have the need to connect one protocol to
another we must have a duplicate object.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 19
Call Processing Functionality (3)
• We could use 3 objects
– One for the incoming side
– One for the outgoing side
– One as a mediator for the others
Switching Node
Endpoint
object
Call
Entity
Endpoint
object
• But this results in many objects!
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 20
Call Processing Functionality (4)
• Or we could use two objects
– One for incoming side
– One for the outgoing side
• And define a protocol between them
Switching Node
HalfCall
Entity
HalfCall
Entity
• This balances the explosion of different classes of the one
object case and the explosion of objects in the 3 object case
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 21
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
Half Call
Fault Management
• This two object case is the “Half Call” model.
• It is in use by a number of commercial switching products.
• The pattern Half Call is the specialization of a pattern Half
Object Plus Protocol (HOPP) by Gerard Meszaros
• Pattern Languages of Programming, chapter 8.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 22
What’s Missing?
• What functionality is missing that the system needs?
– How does the computer know where to route calls?
– How does the Carrier realize any revenue from connecting
the call?
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 23
“Non-Functional” Requirements
• What is required to maximize revenue for all concerned?
– The means to maintain the system to keep it operational.
– Ways to ensure that it is working correctly.
– Ways to ease the day-to-day workload.
• These attributes are important yet they are not the reasons that
the system is being built.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 24
Non-application functionality
• The first issue that was noted above as missing is the ability of
the system to know where to connect the call.
• This data changes occasionally – as people move or create new
service.
• The requests are almost always similar:
– How do we connect a call from 123.185.124.7 to 250.120.10.3?
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 25
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
Switch Data Store
Fault Management
Problem: How can the system dynamically handle connections that aren't
predefined?
Context: It is more efficient to reconfigure the connection for each call.
Half Call discusses how we can arrange the call processing components that
will participate in a connection between endpoints within our system.
Forces: Telephone systems once solved this problem with an intelligent agent.
As the number of possible connections grew, the amount of knowledge that
is required grows.
A small database can store the data needed for such a regular query. The
database must support the simple queries like those just described, and also
be able to support a number of administrative actions.
Since this database will be interrogated on every connection within the system
it must return its answer quickly.
If the database is unavailable due to a failure, the system cannot connect calls,
so the database system must be highly available and have few faults.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 26
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
Switch Data Store
Fault Management
Solution: Install a small, custom data storage system that will be able to
quickly and reliably decide how to connect two parties to the call.
Resulting Context: The system's database will not remain constant, as changes
will occur as customers enter or leave the network.
Switching Node
HalfCall
HalfCall
E
ntity
E
ntity
Customer
Data
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 27
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
Billing
Fault Management
• The Carrier wants to see some revenue for the services that are
being offered.
• They need some way of keeping track of how much each
customer actually used.
• The Half Calls have information about usage; but they don’t
have the time to deal with recording all the usage.
Therefore,
• Add a billing subsystem, that will take the usage information
from the Half Calls and record it so that a bill can be provided
to the customer for their usage.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 28
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
Measurements
Fault Management
• The carrier would like to install only as much capacity in their
network as they need to handle the traffic. This maximizes the
revenue/cost ratio.
• The carrier needs to know how effectively her network is being
used so that changes can be made and capacity moved or retired.
Therefore,
• Create a Measurements subsystem that will keep track of all of
the system components.
• Billing only sees a part of the system. Measurements will be
take across the whole system.
• Report the measurements on a periodic basis.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 29
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
System Integrity
Fault Management
• Measurements keeps track of performance metrics and reports
them to the carrier on a periodic basis.
• It doesn’t analyze any of the performance data to look for trends.
• In order to increase a system’s availability it must detect errors
and take corrective action quickly.
Therefore,
• Create a System Integrity object that is responsible for watching
the system for errors.
• This object won’t actually take the corrective action, instead it
will call the Fault Management and Maintenance Software.
• Sometimes it will decide that the problem is an overload and will
take actions to reduce the problems. (Self Protection)
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 30
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
Self Protection
Fault Management
• Too many requests for service can have a variety of causes:
– Too much traffic overall (e.g. after the big soccer game is won!)
– Localized disasters (e.g. hurricane, earthquake)
– Faulty peripheral hardware
• An effective strategy is to reduce the effects of overload is to
ask neighbors (network peers) to reduce what they are sending.
– But this won’t work in some situations
Therefore,
• Every system must take the steps necessary to protect itself.
This means it must have workload reduction strategies in place.
• Rely on System Integrity to identify whether it is an overload or
a fault.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 31
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
Maintenance Software
Fault Management
• Faults can exist in the system for a long time before they
manifest themselves and produce errors.
• When faults manifest themselves as errors the system must stop
call processing to handle the errors – this reduces availability.
• Hardware wears out. But software also degrades with time.
• The hardware/software platform might be
– Very knowledgeable about the switching application
– Very naïve about our application (e.g. general purpose hardware and OS)
Therefore,
• Build a framework of components that can test the hardware and
software to detect and correct faults before they trigger errors.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 32
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
Fault Management
Fault Management
• The first thing that must be done to isolate a fault is to determine
what is faulty.
• The hardware/software that isolate a fault can itself contain faults.
• Isolation might require that encapsulation be violated to access
data that is erroneous.
• System Integrity detects that there is a problem but doesn’t correct
it.
Therefore,
• Create a Fault Management class that can reach into other objects
as necessary to correct faults.
• Keep this class lean enough that it is unlikely to contain faults of
its own.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 33
Half Call
Billing
Switch DataStore
Measurements
System Integrity
Self Protection
Maintenance
Software
The Result
Fault Management
System Maintenance
• These patterns are mined
from a variety of systems,
including
– Lucent 4ESS™ Switch
– Lucent 5ESS® Switch
– Nortel DMS™-100 Switch
Fault
Treatment
Subsystem
Call Processing
Half Call
Half Call
Routine
Maintenance
Subsystem
Measurements
Subsystem
Half Call
CP Data
Subsystem
Billing
Subsystem
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 34
Going to the Next Level
• “Create a collection of patterns that are related to the problems
at hand…”
• Patterns of relevance might come from some of these sources:
–
–
–
–
–
–
–
Fault-Tolerant Telecommunications System Patterns
Real Time and Resource Overload
An Input and Output Pattern Language
Patterns for Time-Triggered Embedded Systems
Small Memory Systems
Doing Hard Time
And many other sources …
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 35
Supporting Functions
• This has created a nice stand-alone system.
• But it might be useful to build some systems around it.
– Network Element Manager
• To interface to System Integrity and Measurements to collect data from
several systems.
– Provisioning System
• To interface to Switch Data Store to allow more human-friendly interactions.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 36
Summary
• You’ve seen how the architecture of a system can be described
in patterns.
• You’ve seen that a large part of a system might be involved
with functions that don’t directly deal with the application that
the customer (not the carrier) is interested in.
• You’ve seen a set of patterns that work together to describe a
result that is bigger than any of the individual patterns.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 37
Objectives -- Revisited
• At the end of this talk you will:
– Be able to explain the difference between patterns and pattern languages
– Be able to describe the primary internal functions of a telephone
switching systems
– Be able to explain the “half call model”
– Be able to explain how a pattern language can be used to describe
the architecture of a computing system.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 38
References (1)
Adams, M., J. Coplien, R. Gamoke, R. Hanmer, F. Keeve and K. Nicodemus, “FaultTolerant Telecommunications System Patterns”, in [21], pp 549-562.
2. Alexander, C. The Timeless Way of Building. New York: Oxford University Press. 1979.
3. Beck, K. and R. Johnson, “Patterns Generate Architectures,” Object-Oriented
Programming 8th European Conference (ECOOP ’94), Springer-Verlag, 1994.
4. Coplien, J. O. and D. C. Schmidt, eds. Pattern Languages of Program Design. Reading,
MA: Addison-Wesley. 1995.
5. Coplien, J. O. Software Patterns. New York: SIGS Publications. 1996.
6. Coplien, J. O. “The Column Without a Name: Pattern Languages,” C++ Report, Vol. 9,
No. 1, 1997, pp 15-21.
7. Douglas, B., Doing Hard Time, Boston: Addison-Wesley, 1999.
8. Hanmer, R. S., “Real Time and Resource Overload”, PLoP 2000 Proceedings.
9. Hanmer, R. S. and G. Stymfal, “An Input and Output Pattern Language: Lessons from
Telecommunications”, in [14], pp 502-536.
10. Hanmer, R. S., “Call Processing”, PLoP 2001 Proceedings.
11. Hanmer, R. S. “Using Patterns to Teach Software Architecture,” Proceedings of the 6th
Biennial World Conference on Integrated Design and Process Technology, Pasadena, CA,
June, 2002.
1.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 39
References (2)
12. Hanmer, R. S., “OAM-1”, PLoP 2002 Proceedings.
13. Hanmer, R. S., “Operations and Maintenance 2”, Submitted to SugarLoafPLoP
2003.
14. Harrison, N., B. Foote, H. Rohnert, eds. Pattern Languages of Program Design-4.
Reading, MA: Addison-Wesley, 2000.
15. Meszaros, G. “Half Object Plus Protocol”, in [4], pp 129-132.
16. Meszaros, G, “A Pattern Language for Improving the Capacity of Reactive
Systems”, in [21], pp 575-591.
17. Noble, J. and C. Weir, Small Memory Software, Reading, MA: Addison-Wesley,
2001.
18. Pont, M., Patterns for Time-Triggered Embedded Systems, New York: ACM Press,
2001.
19. Rising, L. The Pattern Alamanac 2000. Reading, MA: Addison-Wesley, 2000.
20. Schmidt, D., M. Stal, H. Rohnert, and F. Buschmann. Pattern -Oriented Software
Architecture Volume 2 -- Patterns for Concurrent and Networked Objects. West
Sussex: John Wiley and Sons. 2000.
21. Vlissides, J., J. Coplien and N. Kerth, eds. Pattern Languages of Program Design-2.
Reading, MA: Addison-Wesley, 1996.
Copyright © 2003, Lucent Technologies. All Rights Reserved.
August 11, 2003 - 40