copyright © 2003, lucent technologies. all rights reserved.august 11, 2003 - 1 a telephone...

Copyright © 2003, Lucent Technologies. All Rights Reserved. August 11, 2003 - 1

A Telephone Switching System-- A Pattern Language

Robert HanmerLucent Technologies

Naperville, Illinois, [email protected]


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”


Outline

• Background– Patterns & pattern languages

– Telecommunications

• Patterns of a Telecom System

• The next step to building the system

• Summary

• References


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


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.


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.


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.


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


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)


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


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

A

A

A

B

B

B

B

Traffic Flow


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.


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.



• Language Map

Fault Management

Maintenance Software

Self Protection

System Integrity

Billing

Measurements Switch DataStore

Half Call



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


Call Processing Functionality Then

• “Please connect me with Gloria.”

• Request interpreted by a human operator who then connected wires to complete the call.


Call Processing Functionality Now

• “1 312 555 1234”

• A computer processes the address digits and makes the connections automatically.


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


Call Processing Functionality (2)

• We could use a single object to process both ends of the call inside our system.

• But when we need have the need to connect one protocol to another we must have a duplicate object.

Switching Node

CallEntity



• We could use 3 objects– One for the incoming side

– One for the outgoing side

– One as a mediator for the others

• But this results in many objects!

CallEntity

Endpointobject

Endpointobject

Switching Node



• Or we could use two objects– One for incoming side

– One for the outgoing side

• And define a protocol between them

• This balances the explosion of different classes of the one object case and the explosion of objects in the 3 object case

Half-CallEntity

Half-CallEntity

Switching Node


Half Call

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

Fault Management


Self Protection

System Integrity

Billing


Half Call


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?


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


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?


Switch Data Store

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.

Fault Management


Self Protection

System Integrity

Billing


Half Call


Switch Data Store

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.

Half-Call

Entity

Half-Call

Entity

Switching Node

Customer Data

Fault Management


Self Protection

System Integrity

Billing


Half Call


Billing

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

Fault Management


Self Protection

System Integrity

Billing


Half Call


Measurements

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

Fault Management


Self Protection

System Integrity

Billing


Half Call


System Integrity

• 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)

Fault Management


Self Protection

System Integrity

Billing


Half Call


Self Protection

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

Fault Management


Self Protection

System Integrity

Billing


Half Call



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

Fault Management


Self Protection

System Integrity

Billing


Half Call


Fault Management

Fault Management


Self Protection

System Integrity

Billing


Half Call

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


The Result

• These patterns are mined from a variety of systems, including – Lucent 4ESS™ Switch

– Lucent 5ESS® Switch

– Nortel DMS™-100 Switch

Call Processing

System Maintenance

Half Call Half Call

Half Call

Routine Maintenance Subsystem

Measurements Subsystem

Billing Subsystem

CP Data Subsystem

Fault Treatment Subsystem

Fault Management


Self Protection

System Integrity

Billing


Half Call


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 …


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.


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.


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.


References (1)

1. Adams, M., J. Coplien, R. Gamoke, R. Hanmer, F. Keeve and K. Nicodemus, “Fault-Tolerant 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.


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 - 1 a telephone...

Documents

collection of patterns

individual patterns

problem slide

switching pattern language

model slide

telephone switching

completeness pattern

system summary references