Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 2005, Monash University, Australia CSE5806 Telecommunications Management Lecturer: Dr Carlo Kopp, PEng Lecture 10-12 Telecommunications Network Strategy.

Similar presentations

Presentation on theme: "© 2005, Monash University, Australia CSE5806 Telecommunications Management Lecturer: Dr Carlo Kopp, PEng Lecture 10-12 Telecommunications Network Strategy."— Presentation transcript:


2 © 2005, Monash University, Australia CSE5806 Telecommunications Management Lecturer: Dr Carlo Kopp, PEng Lecture 10-12 Telecommunications Network Strategy and Design Aspects

3 © 2005, Monash University, Australia Network Planning Issues Internal factors current usage and forecast requirements constraints -  eg existing contracts, buildings, residual life of existing equipment technical needs of the applications -  eg mission criticality, hard or soft ‘real time’, timing variability External factors: technology available - now, future, costs involved (eg training) regulation - governments, codes of conduct etc labour and related issues:  skills needed, compared with those available  training - immediate, ongoing, future  surplus personnel - retrenchment, retraining etc financial appraisal of the proposal - including maintenance cost development and procurement plans

4 © 2005, Monash University, Australia System Life Cycle - Conceptual Ideas Decision Design Implement System Operations Review Operations GO NO-GO Progress Clockwise Strategy Studies

5 © 2005, Monash University, Australia Network Strategy Development Network Life Cycle is a sequence of: Network Strategy Determination;  Architectural Concepts Designing the network; Implementing the network; Operation and Maintenance of the network;  (Maintenance = Approx 10% of initial cost per annum) Modification of network as needs change; Upgrading equipment/software to remain current; and finally Closing Down, Dismantling, and Disposing of the equipment, documentation, circuits etc. ‘Technical Strategy’ should consider ALL of these steps Initial costs Costs approx equal to Initial costs

6 © 2005, Monash University, Australia Round the Loop, again and again… Most organisations have been around this loop several times  Many larger organisations have had computers since late 1960s communications networks of various kinds for many years:  telephones - from 1920s  telegraphic transfers via paper tape (using pre-allocated time windows) since 1960  Telex and TWX (dial up messages) 1960s  internal computer links - LANS from 1970s  WANs for computer data from 1980s  Yet people still have difficulty in realising that: planning is required most network design work is enhancement or replacement of existing networks. Few are ‘green fields’ design.

7 © 2005, Monash University, Australia Strategy Revision Strategy Study  Suggested 6 stages: Analysis of existing network(s) Identification of future network & facility requirements Definition & evaluation of options Strategy consolidation Reporting Recording the requirements and decisions

8 © 2005, Monash University, Australia Stage 1 Analysis of Existing Network This stage provides information & insight into organisation:  how the existing facilities work, and how well Network topology and organisation weaknesses & strengths – networks, applications, people satisfaction or unhappiness of the user community  traffic loads now in future, both existing systems (up/down) and future systems (really stage 2) dispersal and characteristics of communications traffic aggregated traffic collections criticality  working lives of existing equipments. It may be: worn out – needs replacement out of support - unmaintainable out of capacity - overloaded  contractual commitments/lease arrangements in place Constraints?, can be bought out?, must live with?, need updating?

9 © 2005, Monash University, Australia Stage 2 Future Network Requirements What is Required – (not how it will be achieved)  Characteristics loads & bandwidth switching requirements time profiles dispersion - centralised, distributed, remoted? growth pattern - application by application back-up & redundancy (service agreements) external access - other networks, databases interfaces, protocol converters, gateways  Functions and capabilities required  Available buildings and environmental support eg is the company vacating buildings somewhere?

10 © 2005, Monash University, Australia Stage 3 Consider Options Define and Evaluate Options and alternative solutions This is where you consider the questions:  ‘HOW to do it’ and  ‘HOW MUCH would it cost if done this way’ A major creative effort Can use brainstorming, think tanks, seminars, etc. Essentially draws from:  existing installed base  information about current & emerging technology and techniques  bright ideas  future requirements to produce a short list of options (combination of evolution and revolution)

11 © 2005, Monash University, Australia Stage 4 Strategy Consolidation Determine preferred approach or approaches  This stage requires plenty of discussions with stakeholders, covering: Requirements to be implemented Timetables when these will be implemented Budgets -  money  time  people Benefits identified at each stage

12 © 2005, Monash University, Australia Stages 5 and 6 Stage 5 - Report to Management Basically, keep management informed Stage 6 - Record the Requirements and decisions Even if the decision is not to proceed, the strategy study results need to be recorded. If decision is to proceed, then move along towards implementation:  design  install  operate, support, maintain

13 © 2005, Monash University, Australia Project Lifecycle - Engineering Processes System Specifications System Specifications System and Sub-System Specifications Detail Design Ideas Sub-system Testing System Testing Acceptance Testing Progress Clockwise Review Operations Strategy Studies Operations Analysis Architectural Design User Requirements Specification User Oriented Testing - Functional and Performance System Oriented Testing- Technical Functionality, plus Connectivity and Interfacing Acquire and Implement Sub-systems Sub-system Oriented Testing- Detailed Functionality, plus Connectivity and Interfacing

14 © 2005, Monash University, Australia General Design Approach Network design is a complex task -  as much people-handling & political as technical issues  requires patience and endurance Starting conditions:  Usually a request ‘to install a network’  Sometimes with written ‘brief’, such as the document from Strategy Studies “Stage 6 - Recording Concept for Later” Ending Conditions:  A detailed specification of the technical design, from which the network could be built, tested, and implemented. Frequently, the designer then also implements the network

15 © 2005, Monash University, Australia Major Stakeholders & Roles Customer Has: Money to pay for products & services Business Needs & Expectations Employees ( Operators and Users) Designer Has: Knowledge (education &training) Wisdom (experience) Vendors Have: Products & Services Skilled Workforce All are needed to implement and support the network

16 © 2005, Monash University, Australia Project Engineer/Designer Role Network Implementation Tasks (build, install, test, train staff etc) Project Engineer/Designer is Buffer between the (demanding) customer and the implementers Customer (With Needs & Money ) Needs & Expectations Money to pay costs Specifications & Requirements Costs Problems and Resolutions

17 © 2005, Monash University, Australia Main Design Drivers Network Design driven by five main issues:  Functionality Required  What is the network to do?  Performance Required  How fast is to be?  Reliability and Availability Required  When is it needed, and impact of not being available when needed  Facilities and Capabilities Available - (sometimes a constraint)  What buildings/rooms/equipment are available - must they be used?  Price or Cost  If lucky, you get what you pay for, but rarely more than that

18 © 2005, Monash University, Australia Components within Computer Network The computer communications network will essentially consist of:  Processor(s) of all kinds;  Mainframes, Servers, email servers, etc  Node(s);  Hubs, Switching Centres, routers, bridges PABX  Line(s) and possibly modems;  Communications circuits linking sites/hubs etc  Terminal(s);  Desktop computers, printers, POS terminals, IVR units etc  Miscellaneous Components  Crypto gear, firewalls, telemetry interfaces etc

19 © 2005, Monash University, Australia Design Issues The design will need to comply with some constraints, and answer some questions, including:  How many nodes, and where?  logically and physically  Which terminals and/or processors will connect to each node(s)?  Eg where will the colour printer be placed and connected?  Is this a centralised or distributed network?  How will they be connected (within node)?  What configuration - star, daisy chain? One (or two) way loop?  How will nodes connect to each other?  Leased lines, VPN, high speed links (eg ATM, fast Ethernet)?

20 © 2005, Monash University, Australia Key Points The key points when approaching network design are:  Proper definition & specification of the technical problem, AND  Well specified evaluation criteria - eg  What is `good response'?  What is `a reliable system'?  What constitutes `an expandable network'?  Don't rely on intuition or assume that you know what is wanted, this is usually dangerous. Remember: ‘Assume’ makes an ass (donkey) out of you and me ( Ass / u / me )

21 © 2005, Monash University, Australia Design is an Iterative Process Design Activity Goals Demand Resources Adjust Criteria Review Results Network Design Temper Design Order Circuits Order Equip't Iterative Design Process Design Documents Spec’ns Drawings Plans

22 © 2005, Monash University, Australia Design Goals The major design goals are to:  Deliver the functionality, performance and connectivity required  Mininise costs  Optimise performance Speed Capacity  Efficiently use the Facilities provided (efficient use of space etc)  Meet Objectives in: Implementation Ease Availability and Reliability Maintainability Servicing Flexibility Robustness

23 © 2005, Monash University, Australia Performance Required Performance requirements drive the ‘dimensioning’ of the network ie number of circuits/components, and the bandwidth required for their connection

24 © 2005, Monash University, Australia Response Time Response time is performance in interactive mode Typical User view:  The time from pressing the key that `commits' the input command, and viewing the full output screen. (ie end-to- end delay) Typical Specialist view:  Time from last input character going to line, and first output character being received at the computer(ie transit delay). Need agreed definition  Either view is valid - but remember the golden rule, and who has the gold.  Try for peak or busy hour definition EG. “95% of traffic items shall be handled within ‘n’ seconds” What should ‘n’ be?

25 © 2005, Monash University, Australia Throughput Related to response time figure but effect is quite different. Throughput is a `batch' type of concept  Inevitably difficult to define  Inevitably difficult to specify meaningfully  Interrelates with response time -  good response times imply good throughput  TRY: “Throughput is the bulk traffic able to be handled by the network.”  eg 1000K file transfer in one minute.  NOTE: If no priority system for traffic, a bulk file transfer will cause the communications link loading to approach 100% utilisation for short periods, thereby creating significant delays for interactive traffic.

26 © 2005, Monash University, Australia End-to-End Delay The total time for an item to transit the network - including all:  communications transit times (usually negligible, except for satellite links)  queuing times at intermediate nodes  error recovery delays  etc  and sometimes includes processing times Ensure that you know whether ‘allowable delay’ includes processing times. It is often included in the ‘perceived comms delay’

27 © 2005, Monash University, Australia Busy Rate Goal Usually related to ‘LOSS’ aspects  ie. those situations like a busy line on a telephone, where the request is lost if unable to be satisfied immediately. Dial up circuits Port Selection Virtual Circuits Usually set to an acceptable criteria (`grade of service’ or ‘degree of congestion’) say 1% in busy hour is a typical rate for congestion of outgoing telephone calls being unable to be completed due to circuit/switch congestion.

28 © 2005, Monash University, Australia Maintenance Goal How much effort is management prepared to expend on Hardware and on Software for both  fault correction, and  environmental maintenance (keeping up with technology)  eg Should they buy high reliability equipment, even though it costs much more than commercial grade equipment? Mean Time Between Failures (MTBF)  concept For each critical component For the communication carrier's circuits Needs to be specified carefully  eg `Over six months, the MTBF shall be greater than xxx hours.'

29 © 2005, Monash University, Australia Servicing Goal Mean Time to Restore (MTTR) concept  Central or Capital City installations Service personnel are less than an hours drive away Spares warehouses are close to hand  Remote Installations Service personnel may have to fly in Consider holding extended spares stocks on site  Communications Carrier's MTTR (probably very high, but …) Needs to be specified carefully  Define whether MTTR is to respond, repair, restart or RESTORE;  EG `Over six months, the MTTR shall not exceed three hours on average, nor five hours for any single incident.’ NOTE: Many other terms apply to these concepts - eg  Inherent availability, mean down time, etc

30 © 2005, Monash University, Australia Implementation Ease Goal The ease or difficulty of implementation -  closely related to ‘Technical Risk’ How long to achieve implementation? How much upheaval in the organisation? What is the risk of project failure:  equipment inadequate  supplier/vendor failure to deliver  traffic estimates grossly inappropriate  facilities not available on time  Training  state-of-the-art equipment on a par with kindergarten art Leading Edge technology is BLEEDING edge for managers

31 © 2005, Monash University, Australia Robustness Goal How well the network stands up to stress and shocks Electrical and installation aspects  Over/Under Temperatures  Uninterruptable/No-Break Power Supplies Circuit aspects  Overloads  Zero Loads  Circuit transients - `hits' and `failures'  Circuit major outages Application Dependencies  Peaky interactive loads  Unexpected large batch loadings MUST BE COST_JUSTIFIED - no system can be perfect  Many people demand high robustness, but cost is 200% to 500% more

32 © 2005, Monash University, Australia Security Goals ALWAYS treat security as exercise in RISK MANAGEMENT  (AS/NZS 4444 of 1999 “Information Security Management” and AS/NZS ISO/IEC 17799:2001 “Code of Practice”) Base security on impact assessments and costs Avoid knee jerk reactions and quick fixes Match network security to application/installation security

33 © 2005, Monash University, Australia Performance Issues Regarding performance issues, concentrate on:  Network and Line Capacity Line BPS or Char/Sec Nodes Packets etc per second  Delays Waiting in queues for service Service Times For all lines, actual throughput is always less than the theoretical maximum possible throughput due to:  polling  error block retransmissions  synch frames and overheads  effect of random traffic patterns  Line utilisation = (Actual Load handled / Maximum Possible)

34 © 2005, Monash University, Australia Traffic Characteristics Design is significantly affected by  Type of traffic activity being handled  Volume of traffic to be handled eg average transaction (packet) size eg average number of packets/second during the busy hour Strange as it may seem, you will spend more time determining and analysing these issues than actually ‘designing’ the network. Informal studies have indicated that actual network loads experienced within a short time of commissioning the new system are often 100% above the ‘design load’

35 © 2005, Monash University, Australia BATCH Traffic These types of traffic flows were the norm before interactive terminals became common. Still in widespread use today. Examples: Overnight backups, End of Day POS dump. One major direction of flow at any time  Usually very asymmetrical at any point in time Many records - size & number determinable (more or less) Performance objectives `hours’ rather than seconds  Usually this traffic type is ‘overnight’ Impacts N/W performance badly  Line and switch gear utilisations approach maximums during large batch flows - thus there is little capacity left for other network users at that time.

36 © 2005, Monash University, Australia Transaction Oriented Traffic This traffic type is a cross between Batch and Interactive It has become very common via the internet Bursty - Random Traffic patterns Performance objectives `minutes’ (or tens of seconds)  Consider the delays caused by downloading the ‘pretty effects’ of many web pages - the authors may not realise it, but the psychological impact from to the ‘pretty effects’ is drastically reduced due to the slow nature of the transactions. Impact is frequently negative due to the excessive delays. One major direction of flow Variable record sizes and numbers

37 © 2005, Monash University, Australia Interactive (eg Query/Response) This type of traffic normally appears as Query/Response situations, where the response is required within one or seconds of the query. Typically, the traffic volumes are very asymmetrical (short query, large response)  Bursty - Random Traffic patterns  Two way flow, (although one predominates)  Performance objectives `seconds’  Variable sizes and numbers of records

38 © 2005, Monash University, Australia Message Volumes Traffic volumes are critical to response time/throughput. `Communication item' sizes Average size - best by application if available Statistical distribution of sizes Are these figures constant throughout the day/week/month? Totals in-out for each application Volumes of traffic - by application if available Peak Times (NOTE: WA is 2-3 hours later) Special Days (Holidays, Religious festivals) Identifying the peak times for each application may be very useful NEED TO UNDERSTAND BUSINESS / LOCAL PEAKS First Tuesday in November = holiday for many, peak for TAB

39 © 2005, Monash University, Australia `Turnpike Effect' and Growth (AKA as `Suppressed Demand’, Freeway Effect, etc) Well designed systems encourage greater use -  especially enquiry systems Need to add a contingency allowance for the unknown suppressed demand Martin 1968:  "If terminals provide a useful service, their utilisation will expand to fill the system capacity"

40 © 2005, Monash University, Australia Network Delay and Response Times A small example

41 © 2005, Monash University, Australia Network Delays What is involved in the delay?  Node delays: Usually small (and consistent)  Specialised processors etc used in switches and hubs Delays Affected by CPU and buffer numbers  Low processor CPU power means less nominal ‘packets per second’  Low memory size means lower capability for switching (buffer overflows etc)  Line Delays Trunk Lines and Branch Lines Generally, Comms lines are the bottle neck points in a network aa they are the slowest  Note: These delays are for each node and line transited.

42 © 2005, Monash University, Australia Response Times example Query (1000 bytes) / response (10,000 bytes) using a mainframe / 10Mbps LAN Response Time = the SUM of : Inbound Terminal Delay (usually small - say 50 milliseconds) Inbound Queuing Delay (queued traffic held in terminal waiting for LAN access. Time delayed depends on other terminals & traffic - say 20 milliseconds) Inbound Service Time (time to transmit a packet on the network)  (depends on line speed and message size - say 10 milliseconds) Front End Processor (FEP) Delays (should be small - say 10 milliseconds) Mainframe delays (could be comparatively large - say 1000 milliseconds) FEP Delays on output (say 100 milliseconds) Outbound Queuing (held in FEP while waiting for LAN access - 1000 ms) Outbound Service Time (say 50 milliseconds) Outbound Terminal Delay (say 50 milliseconds) Total time - 2290 milliseconds - of which 60 can be assigned directly to ‘network’ (the inbound and outbound service times). Most of the rest is waiting times.

Download ppt "© 2005, Monash University, Australia CSE5806 Telecommunications Management Lecturer: Dr Carlo Kopp, PEng Lecture 10-12 Telecommunications Network Strategy."

Similar presentations

Ads by Google