1. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 1 A Telephone Switching System -- A Pattern Language Robert Hanmer Lucent Technologies Naperville, Illinois, USA hanmer@lucent.com

2. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 2 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

3. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 3 Outline Background –Patterns & pattern languages –Telecommunications Patterns of a Telecom System The next step to building the system Summary References

4. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 4 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

5. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 5 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.

6. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 6 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 youve identified.

7. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 7 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.

8. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 8 How to find patterns and pattern languages The Pattern Almanac –Linda Risings 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

9. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 9 Telecom Systems The basic problem –Telephones introduced in late-1800s. –Initially each telephone was directly connected to another site. This led to an explosion of direct connections (n*(n-1)/2)

10. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 10 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

11. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 11 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

12. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 12 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.

13. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 13 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.

14. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 14 Patterns of a Telecom System Language Map

15. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 15 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.

16. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 16 Call Processing Functionality Then Please connect me with Gloria. Request interpreted by a human operator who then connected wires to complete the call.

17. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 17 Call Processing Functionality Now 1 312 555 1234 A computer processes the address digits and makes the connections automatically.

18. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 18 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

19. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 19 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.

20. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 20 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 But this results in many objects!

21. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 21 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 This balances the explosion of different classes of the one object case and the explosion of objects in the 3 object case

22. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 22 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.

23. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 23 Whats 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?

24. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 24 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.

25. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 25 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?

26. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 26 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.

27. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 27 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.

28. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 28 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 dont 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.

29. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 29 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.

30. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 30 System Integrity Measurements keeps track of performance metrics and reports them to the carrier on a periodic basis. It doesnt analyze any of the performance data to look for trends. In order to increase a systems 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 wont 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)

31. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 31 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 wont 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.

32. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 32 Maintenance Software 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.

33. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 33 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 doesnt 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.

34. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 34 The Result These patterns are mined from a variety of systems, including –Lucent 4ESS Switch –Lucent 5ESS® Switch –Nortel DMS-100 Switch

35. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 35 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 …

36. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 36 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.

37. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 37 Summary Youve seen how the architecture of a system can be described in patterns. Youve seen that a large part of a system might be involved with functions that dont directly deal with the application that the customer (not the carrier) is interested in. Youve seen a set of patterns that work together to describe a result that is bigger than any of the individual patterns.

38. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 38 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.

39. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 39 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.

40. Copyright © 2003, Lucent Technologies. All Rights Reserved.August 11, 2003 - 40 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.