1 / 4

charge@once systems

charge@once systems. Overload protection. General statements. Each charge@once system operates with a mandatory overload protection mechanism which is defined by the software architecture

kimberley-hanson
Download Presentation

charge@once systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. charge@once systems Overload protection

  2. General statements • Each charge@once system operates with a mandatory overload protection mechanism which is defined by the software architecture • In addition a configurable traffic limitation mechanism is part of each system determined by the different access interface groups like SS7 or IP • For SS7 traffic a global traffic limit [GL_TrafficLimit] can be configured by Nokia Siemens Networks: • The customer traffic model determines the required hardware system configuration which is chosen • The parameter is defined by maximum traffic model which is part of the customer contract • The parameter value will be calculated by the max. SS7 BHCA including SMS as x * 1000 transaction per second

  3. Performance test results Test environment:Sun Fire SF890 with charge@once select 1.5 Load Mix: 90% SMS:10%MOC / GL_TrafficLimit was set to maximum released load for given configuration Load test workflow & Results 1. 100% load 20min --> OK (CFR < 0,01 %, Q95 < 250ms) 2. Jump to 200% load 40min --> system stabile, CFR ca. 55%, Q95 ca. 100ms. 3. Jump to 300% load 360min --> system stabile, CFR ca. 66%, Q95 ca. 3-5sec , CCC_CAP Restarts 4. Back to 100% load --> settling time max. 20 min --> OK 5. Jump to 300% load 40min --> system stabile, CFR ca. 66%, Q95 ca. 3-5sec , CCC_CAP Restarts 6. Back to 150% load 20min --> system stabile, CFR ca. 33%, Q95 ca. 300ms. 7. Jump to 300% load 40min --> system stabile, CFR ca. 66%, Q95 ca. 3-5sec , CCC_CAP Restarts 8. Back to 150% Last 20min --> system stabile, CFR ca. 33%, Q95 ca. 300ms. CFR …call failure rate Q95 …95 % of all calls below the mentioned call setup time

  4. conclusion A charge@once system with overload protection and set max SS7 global traffic limit works stabile also with up to 300% traffic load and still performs up to 33 % of the calls successfully. • In case of unexpected network related traffic overload (not calculated within a customer project) a Live System Analysis (LSA) can be offered to determine or refine the traffic limitation settings: • Professional service LSA: - using a monitor tool, which collects performance relevant data for a 24h time period- an offline evaluation determines the real traffic model, bottle necks or reserves- proposals for adaptation of system configurations can be calculated

More Related