remote axe 10 subscriber switch in a container an optical fibre line ...

More documents

Recommendations

Info

210ModelsIn order to carry out a capacity analysisof the system it is necessary to create amodel that describes the internal"mechanism" of the system. A model isalways a simplification of reality. However,in order for a model to be of anyuse, the essential functional characteristicsmust be adequately represented.The practicability of the modelas a working tool is of course also dependenton how suitable it is for mathematicaltreatment or computer simulation.The following models have been used inthe project of analysing the capacity ofthe AXE 10 processor:- the Queue Flow Model- the simulation model- analytical models• queueing network models• models of the central processor.During the work on the models certainassumptions were made regarding thebehaviour of the subscribers. On thebasis of the results of many measurementsthe call arrival process has beenassumed to be a Poisson process. Theoperating times of different functionalblocks in CP and RP have been determinedby means of measurements, orsimply by counting the number of instructionsin each block.THE QUEUE FLOW MODELA Queue Flow Model shows how thevarious equipments (with their programs)interwork when carrying outtheirjobs. This model formsthebasisforfurther work on the project.Fig. 4 shows a basic Queue Flow Modelof the whole AXE 10 processor system.This model takes into consideration CP,RP, RPH-I and RPH-O, all of which aredepicted as individual Queue Flow Modelsin themselves. For example, CP isdivided into a server, the processor itself,and several queues, JBA-JBD.The connections between the differentunits in the model represent the flowpaths, i.e. the paths of the signals in thesystem. Physically they consist of thebus system. Most signal sequences atthe various priority levels use thesepaths, but to a varying extent. A completeQueue Flow Model would thereforebe extremely complicated. More-Fig. 4Basic Queue Flow Model for the AXE 10 processorsystemCPJBA-JBDMALTHLBALRPRP-LICRPH-IRPH-0Central processorJob queuesMalfunction levelTraffic handling levelsBasic levelsRegional processorsRegional processor tor line circuitsUnit for sensing incoming calls from RPUnit for distributing output signals to RP
211over, the type of traffic handled by anexchange differs depending on its sizeand application. In order to obtain amanageable model a configuration hastherefore been studied for a traffic casewhere the traffic handling signals mainlyuse a single priority level. This case isused in fig. 5 to give a somewhat simplifieddescription of the conversion to aQueue Flow Model. The process ofevents when detecting a call attempt isas follows: A signal for the detected callis created in RP, NEW CALL, and istransmitted to CP. This means that thesignal comes in over the RP buses andRPH-I to JBB. If there is a queue, thesignal has to wait there, after which afunctional block in CP is activated,which in its turn initiates one or moresignals, in this case two. One of theseimmediately activates a new functionalblock in CP, which in its turn generates anew signal, this time to an RP. The othersignal generates a shorter sequence forcertain secondary functions, and thissequence is eventually completed. Thisgeneration of several output signalsleads to activities being performed inparallel, a fact which is of importance forthe model.The setting-up sequence can thus be describedas a job, NEW CALL, arriving atRP, where it receives a certain service,and then continuing to CP. where it receivesservice several times. Sometimesthe job receives new service immediately,at other times it has to queue inJBB. Sometimes the job leaves CP directly,and other times it returns to anRP. The basic principle is the same regardlessof traffic case or level.The Queue Flow Model contains no informationregarding, for example, thearrival process and service time in differentsubsystems Such factors arespecified in connection with the furtherchoice of model. In this respect simulationmodels offer better possibilitiesthan the analytical models.SIMULATION MODELA simulation model can be made "asaccurate as one likes". It is possible tomodel the internal behaviour of a systemin the most minute detail, and the simulationprogram will then behave exactlylike the reality it depicts. However, themodel development should not betakenso far in practice. There must be a balancebetween the effort put into themodel and the results that can be expected.Fig. 5aSignal flow diagram for level THL3RP functional block'[ CP functional blockFig. 5bQueue Flow Model for level THL3
Page 1: ERICSSONREVIEW41982REMOTE AXE 10 SU
Page 4 and 5: ;2Remote AXE 10 Subscriber Switchin
Page 6 and 7: Fig. 3The container is brought out
Page 8 and 9: An Optical Fibre Line Systemfor 34
Page 10 and 11: Fig. 3Repeater spacings and hardwar
Page 12 and 13: 182The primary alarms are those rec
Page 14 and 15: 184Technical dataDigital interface
Page 16 and 17: Fig. 2, leftThe transmultiplexer as
Page 18 and 19: 188Fig. 9Synchronization of the tra
Page 20 and 21: Fig. 13The M5/BYB bay equipped with
Page 22 and 23: Fig. 17ZAJ 5x24/2x60, transmultiple
Page 24 and 25: ERITEX10 for Teletex and WordProces
Page 26 and 27: Fig. 5The central processing unit i
Page 28 and 29: 198Fig. 8The floppy disc unit with
Page 30: 200- finding space for a document o
Page 33 and 34: Local Area Radio System-LARSHans Li
Page 35 and 36: Fig. 5One of the thick film hybrids
Page 37 and 38: 207Technical data for LARSSelective
Page 39: 209BERTH EKLUNDHDAVID RAPPDepartmen
Page 43 and 44: 213Models of CPA comparison between
Page 45 and 46: ETable 2The table shows the differe
Page 48: ERICSSONISSN 0014-0171 T E L E F O

remote axe 10 subscriber switch in a container an optical fibre line ...

Create successful ePaper yourself

Delete template?

Save as template?