ࡱ> $&!"#%` ]bjbj ̟̟NW <<<iiii<j(k^llll]]]#(%(%(%(%(%(%($+h .@I(-<]I( llAv(& l<l#(#(;<? lk >ri F7'(0(:L/L/? "a L/<'"]^?L]]]I(I(]]](0E#E  Implementation of First Time Right Practice in Software Development Process D. Duka and L. Hribar Ericsson Nikola Tesla Poljicka cesta 39, Split, Croatia Phone: +385 21 435820 Fax: +385 21 435834 E-mail:  HYPERLINK "mailto:denis.duka@ericsson.com" denis.duka@ericsson.com Abstract First Time Right (FTR) is the concept aimed to improve the software development process. This practice focuses on designing the quality (preventing actions) instead of solving problems (corrective actions). The overall initiative results in continuous improvements and provides a mechanism for propagating the lessons learned between projects to further improve the organization. It also provides clear and effective way to set and follow quality expectations at project level. FTR enables and emphasizes management commitment and control by using verifiable criteria for desired quality outcome and introduces a common measurement framework for systematical data collection, analysis and comparison. This paper gives an overview of FTR concept. Proposals for practice improvement and some initial results analysis are also presented. I. INTRODUCTION The pressure to improve software development process is not new, but in todays competitive environment there is even greater emphasis on delivering a better service at lower cost. Service providers care about quality of their services upon which they make investments. Software vendors care about their clients needs and efficiency in achieving them, a symptom of which is little to no rework i.e. get it done right the first time. The process named First-Time-Right (FTR) serves both these needs. It has both an external and an internal focus. Externally it focuses on the client; internally it can delineate where errors reside notably are they within or upstream of the performance measurement group or system. In other words, FTR splendidly balances customer focus and internal accountability. It delivers this balance at little cost in terms of both start up and ongoing maintenance. The First Time Right was established as a step towards the Operational Excellence program at Ericsson as an initiative mainly established for Quality Assurance (QA). In simple words Quality Assurance represents the planned and systematic activities implemented within the quality system and demonstrated as needed to provide adequate confidence that an entity will fulfill requirements for quality [1]. Time and cost are easily visible during project, while software quality can usually be assessed late in the project and effects of decisions/actions on quality improvements are difficult to evaluate [2]. Rework needed on developed products has a broad impact on the organization: Cost of faults found later are higher, Negative loops require additional resources, Customer and sponsor satisfaction, Organization capability. Benefits of less rework during all the development and testing phases and maintenance are the following: More resources are available instead of being involved with maintenance. More resources at Function Test (FT) are available for function failures instead of being involved with faults slipped through from previous verification phases. More resources are available instead of being involved with System Test (ST) and Design Follow-Up (DFU) activities i.e. activities between first official release and global deployment. Less temporary spill-over of competent resources due to emergencies from early development phases and design towards maintenance. All stated benefits per specific product development phases have its graphical interpretation on the Figure 1 [3] showing how positive spill-over of resources (green) is caused by reduced rework. On the other side, unwanted rework might cause negative spill-over of resources (red) causing jeopardizing the later phases.  SHAPE \* MERGEFORMAT  Fig. 1. Benefits of less Rework First Time Right practice has recently been applied at Ericsson to software development projects having a time frame of 6-12 months. As described in this paper, special principles and guidelines had to be followed while building FTR model as a part of regular software development process. Success factors and some important considerations needed to fulfill the intended effect are also presented here. In order to measure FTR effectiveness, Fault Slip Through (FST) metric was chosen. Although gathering data for more accurate statistical analysis will require longer period of time, some initial analysis was performed pointing to some potential areas of improvements in product life cycle. II. FTR PRINCIPLES The First Time Right practice is based on following quantitative criteria: Mandatory documents, Best practices, Quantitative specifications of processes, Specific measurements. Those criteria are specified for each one of the Quality Indexes: QI1, QI2, QI3, QI4, QI5 [3]. Each quality index includes a list of documents/practices to be performed during development process through five FTR phases: Always-on, Early phases, Design & implementation, Early verification, Verifications. The general meaning of the Quality Index can be summarized by the relevant position in the typical Project Management Triangle (see Fig. 2):  SHAPE \* MERGEFORMAT  Fig. 2. Project Management Triangle QI1 - characterizes fast prototypes/demonstrators development of new and innovative functionalities, either used as gap filler for a limited time span or eventually evolving towards a real product. QI2 - characterizes developments of products where time pressure is dominant, with the appropriate levels of quality and costs. QI2 allows prediction of product quality only on an approximated basis, while ensuring the achievements of the challenging time targets. QI3 - characterizes balanced developments as far as quality and time are concerned. It also allows prediction of product quality on a statistical basis, while providing confidence on the time targets. QI4 - characterizes developments of products where product quality is dominant, with the appropriate levels of time and costs. It allows a meaningful prediction of product quality, while providing a consistent level of confidence on the time targets. QI5 - characterizes developments of high quality products, while optimizing impacts on the levels of time and costs. III. FTR MODEL AND QUALITY GATES The relationship between the Quality Gates (QG) and the FTR practice is described on the Figure 3:   SHAPE \* MERGEFORMAT  Fig. 3. The FTR Model and Six Quality Gates QG1 - Risks and benefits of Feasibility Process tailoring are presented, discussed and validated. After TG1, discussions for selecting the Quality Index starts. QG2 - The Project Steering Meeting (PSM) uses the preliminary (or definitive) QI as one of the inputs. The purpose of PSM is to synchronize project needs and processes, methods and tools. Before Toll Gate 2 (TG2 project execution start), final decision of the Quality Index must be done. QG3 - Risks and benefits of Execution Process tailoring are presented, discussed and validated, taking into account the selected QI as one of the inputs. Between TG2 and Milestone 8 (MS8 first official release) at any important scope changes or change requirements, the already established QI is validated or changed. The Monthly Quality Report shows the status of application of the FTR criteria. QG4 - Process tailoring approaches are analyzed through Capability Maturity Model (CMM) assessment (such as defined at TG2) and also the implementation and effectiveness of the FTR criteria (according to the decided QI). QG5 - The preconditions for measuring the Requirement Implementation Coverage and relevant measurements are evaluated. QG6 - The implementation of the FTR criteria and the relevant effectiveness are validated. IV. FTR GUIDELINES During project feasibility study phase Project Manager and FTR local responsible analyze the feature that has to be developed, taking into account main project constraints (time, quality, cost) in order to propose the most appropriate QI (see Fig. 4). The Provisioning Office Manager provides the top management point of view about expected QI. In the next step, Project Manager evaluates the consequences on time schedule and cost of proposed QI. Final decision regarding QI is made on the Management Team meeting. Change Request (CR) regarding FTR requirements is issued when needed [4].  SHAPE \* MERGEFORMAT  Fig. 4. FTR Guideline Before Project Execution Start The Quality Plan (QP) prepared after project execution start has to be updated, taking into account FTR activities. Project can also add activities to the selected QI-s (documented in Quality Plan). At any important scope changes or requirements changes, the already established QI is validated and changed if needed. After execution phase is finished, Product Quality Assessment is performed by Line Manager, Project Manager, Configuration Manager, Process Owners and FTR local responsible in order to validate the implementation of the FTR criteria and its effectiveness. IV. FAULT SLIP THROUGH As the quality level of the final product is set at the beginning of the project, a large number of faults can result in project delays and cost overruns. The number of faults in a large software project has a significant impact on project performances. In order to keep project performances development teams require fast and accurate feedback on the quality at the early stages of the design cycle [5]. Figure 5 [6] demonstrates how the cost of faults typically rises by development stages. The implication of such a cost curve is that the identification of software fault earlier in the development cycle is the quickest way to make development more productive. In fact, the cost of rework could be reduced up to 30-50 percent by finding more faults earlier.  Fig. 5. Cost of Rework The FTR practice is applied to each deliverable individual. It aims to deliver features, with the expected functionalities, within the expected times and with a quality level which minimizes (ideally nullifies) and makes predictable the rework caused by faults found after function test i.e. the faults slipped through from previous verification phases and system test faults. Fault Slip Through (FST) represents the number of faults not detected in a certain activity. These faults have instead been detected in a later activity [7]. Figure 6 visualizes the difference between Fault Latency and FST:  Fig. 6. Example of Fault Latency and FST When measuring FST, the norm for what is considered right is the test strategy of the organization. That is, if the test strategy states that certain types of tests are to be performed at certain levels, the FST measure determines to what extent the test process adheres to this test strategy. This means that all faults that are found later than when supposed are considered as slipped [8]. The test strategy, test processes and complete development process define in which phase different kind of fault are supposed to be detected. Theprimary purpose of measuring FST is to make sure that the test process finds the right faults in the right phase, i.e. commonly earlier. The main effects of doing this are: Fewer stopping faults (slipping faults tend to be stopping). Less redundant testing (when finding the right faults in the right phase). Less process variation because fewer faults in late phases ! improved delivery precision. Avoid doing the same mistakes (faults) ! supports a learning organization. Improved product quality i.e. only some of the faults slipping from earlier phases are found in Integration and Verification (I&V). Earlier and cheaper fault removal. Although quality of a product is built in during early phases the FST can be related to the whole software development process, from specification to design and test. The test at the end is only meant to be a confirmation of the adherence to the requirements. However, FST is not supposed to be used just as a measure, it is a concept for continuous improvements. Otherwise its intentions will not be fulfilled [9]. Implementation process When getting started with FST measurements, some activities are required to make it work. Generic advice is hard in this area since many activities depend on how different organizations operate. In order to implement the FST in the organization, the following steps are recommended [8]: Determine the business goal of introducing FST i.e. whether the goal is to reduce the number of faults or to reduce the lead-time. Create a common understanding and commitment. Identify a driver. Someone with authority and true interest in implementing the concept is crucial to make the implementation successful. Otherwise, it will as most other improvement work be down-prioritized every time a project emergency occur (which tends to be very often). Make sure that the test strategy is well-defined and communicated throughout the organization. Perform a baseline measurement on a finished project (or at least a subset of defects from a project). Doing this is a good test to see that the measure is possible to apply in relation to the defined test. Add the measure to the local Trouble Report (TR) process. If the measure is included in the TR process, follow-up will be a lot easier. Educate. People most understand how to report the measure and even more importantly understand why it is important to measure. Identify a pilot project to apply it in. This first project needs extra attention regarding follow-up of how well the measurement reporting works. Visualize results early to determine status and to further show people that it is important (people tend to care more about visible measurements). Success factors / important considerations From experience, the concept will not have the intended effect in practice unless some factors are adhered to. Generic success factors are: One must accept the current situation and then improve on it; especially reward systems might cause accurate data to be withheld and contra-productive improvements to be implemented. Organizations with successful measurement programs actively respond to what the measurement data tell them. Appropriate and timely communication of metrics results are critical in order to be used - make the results visible. Measurement results must be examined in the context of the processes and environments that produced them. The effort to collect metrics should not add significantly to the organization's workload. The success of a measurement program is dependent on the impact it has on decision making, not the longevity of it. FST specific success factors are: When introducing FST measurement into the fault reporting process, a guard is needed at least in the beginning to make sure that the faults are classified as they should (for example Maintenance Handling Office expert, test leader or fault review board). Make sure to have a common and project independent test strategy developed and communicated because it is very tightly connected to the FST measure. Developing and deploying a common test strategy is in it self a driver for improvements since it tends to identify flaws in the process. V. FIRST TIME RIGHT RESULTS FTR practice was applied on SW development project at Ericsson. The main reason for that was the conclusion that many faults inherited from early development phases cause a lot of rework and significantly increase the final product cost. In order to address this problem, a central part of the process change was to introduce the First Time Right approach. The concept was implemented into a new product release and results were compared with the similar previous project. During both projects personnel turnover was very low and the root development processes were stable. The chosen metric was Fault Slip Through i.e. measuring the fault slippage from different development phases. Results are shown on the following table [10]: TABLE 1 FAULT STATISTIC PROJECT COMPARISON Without FTRWith FTRImprovementProduct FST to Function Test77%61%21%Product FST to System Test59%51%14% As can be seen from the table, slippage from Unit to Function test and from Function to System test were reduced. Lower result in second case can be explained by fact that one feature in Function test was not fully following the new approach (due to the specific test environment it was tested off site) causing the higher fault slippage than expected. However, in order to verify complete FTR results, new validating tool in form of additional fault codes has to be applied. Additional fault codes provide a flexible and standard way to collect and analyze data on defects found during development. Results coming from the additional fault codes analysis will be used to: Give feedback to the ongoing development project, Improve processes, Optimize and validate the FTR model. Additional fault codes will provide the following information: Error injection during development activities, Effectiveness of each verification activity, Fault pattern over project phases. Achieved FTR results, together with new info that will be obtained after implementation additional fault codes, will help us to improve the weak development areas and also to decrease the amount of rework needed in later phases of product cycle. VI. CONCLUSION FTR process re-focuses the attention on the quality requirements associated to the first delivery. It also takes into account the real development requirements (time dominant and quality dominant factors), while mitigating the risks of poor quality, when time is dominant. The practice allows to establish a clear agreement and commitment between the organization parties involved with the feature development (Project manager vs. Organization managers) by means of a shared decision about a QI. This process is build-up by a bottom-up approach by using experience and competence of relevant experts. A measurement framework exists, providing good Key Performance Indicators associated to the practice goal (e.g. fault slipping through at any development and test phases). The practice is applied to developments projects and the results are to be validated on a statistical basis, by means of a meaningful number of applications. The statistical prediction of rework level at ST/DFU/Maintenance requires time (e.g. 2-3 years) for gathering data and elaborating them into a consistent and proven statistical model. However, improvements might be visible in a shorter term. Nevertheless, the implementation of the FTR provides the opportunity to review/reinforce the under-lying processes, because it highlights process lacks and quantitative levels of process applications. It also provides the raw materials to produce a trend line of quality to see if the process has been measurably improved or not. REFERENCES A. U. Rehman, Quality Cost Analysis, Feditec Enterprise T. P. Ryan, First Time Right Ratio, Measuring the Measurers, November 2008 ***, FTR Practice, Internal Ericsson Documentation, Sweden 2006 ***, FTR Application Guideline, Internal Ericsson Documentation, Sweden 2006 L. Hribar, S. Sapunar and A. Burilovic, First Time Right In AXE using One track and Stream Line Development, Proceedings MIPRO, 2008 L-O Damm, Early and Cost-Effective Software Fault Detection, Blekinge Institute of Technology, 2007 ***, Fault Slip Through Measurements, Internal Ericsson Documentation, Sweden 2005 L-O Damm, L. Lundberg and C. Wohlin, Faults-slip-through A Concept for Measuring the Efficiency of the Test Process, Wiley Software Process: Improvement and Practice, Special Issue, 2006 Z. Antolic, FST Measurement Process Implementation in CPP Software Verification, Proceedings MIPRO, 2007 L-O Damm and L. Lundberg, Results from introducing component-level test automation and Test-Driven Development, Journal of Systems and Software, vol. 79, issue 7, July 2006 1 2 3 This colour indicates a new flow due to CR-s to be used when there are important impacts from CR-s. This color indicates the original flow CR: updated-QI CR: updating of Mgmt-QI CR: updating of Project Planning scenarios CR: updating of Project-QI PPO manager PA manager LM inputs Selected-QI Project Planning scenarios Preliminary proposal of a Mgmt-QI by PPO manager CR during design Preliminary proposal of a Project-QI FTR responsible inputs PM inputs Final decision Analysis of consequences Analysis of the Feature Costs are the most appropriate ones to support the application of the relevant QI-s. Time needs are dominant within a controlled quality Quality needs are dominant within the planned times QI5 QI4 QI1 QI2 QI3 Quality Time Cost D F Fault Latency Fault Slip Through B Maintenance DFU FT Design & Implementation Early Phases Development and assessments QG5: Functional Configurat. Audit Application of agreed QI Establishment and updating of a QI for each feature to be developed QG6: Product Quality Assessment QG4: CMM Assessment QG3: Internal TG2 Assessment QG2: Productivity Strategy Meeting QG1: Internal TG1 Assessment MS8 TG2 TG1 A C Fault found Fault supposed to be found Fault was inserted Operation System Test Function Test Unit Test Coding Design "+LMNPUYcdzʾʊsis\RERE7Rjhd=CJUmH sH h hd=CJmH sH hd=CJmH sH h < hd=CJmH sH h CJmH sH h < hd=CJmH sH hz(CJmH sH h hd=5\mH sH %h|~lhd=5CJ\]aJmH sH %h@hd=5CJ\]aJmH sH hd=5CJ\]aJhxhd=5CJ\]aJ%h@hd=5CJ\]aJmH (sH (%h@hd=5CJ\]aJmH sH ,MNdz    h j k | } ` $Pa$gdr=$PP`a$gdzTX $h^ha$gdd=$a$gdd= $7$8$H$a$gdT[$a$gdVkgdd=$a$gdd= $7$8$H$a$gdd=X]    " # $ 4 _ { h i j k Ǹǫ}q}h}_S@%h hd=B*CJaJmH phsH hT[hd=5CJaJhD;5CJaJhVk5CJaJh zhT[5CJaJhT[5CJaJh>5CJaJh zhd=5CJaJh hd=5CJ\mH sH h hd=CJmH sH hchd=0JCJmH sH jhd=CJUmH sH 'jhchd=CJUmH sH hd=CJmH sH hhd=CJmH sH k o p { | } 23QaGQeɹɱ~rdYNYF>ha9CJaJhd=CJaJh4zhd=CJaJhjhd=CJaJhx-hT[5CJ]aJhx-hx-CJ]aJhx-CJaJhh6CJaJhhT[6CJaJhCJaJhT[hT[CJaJhT[CJaJhd=B*CJaJmH phsH %h hd=B*CJaJmH phsH %h hd=B*CJaJmH phsH hd=B*CJaJmH phsH eilv?[]^_`c&ΪsiaVGhjhd=CJaJmHsHhr=hd=CJaJhpCJaJhd=CJmH sH h hd=CJmH sH h[CJmH sH hd=CJaJhjhd=CJaJhghd=PJnHtHh[CJaJhzTXCJPJaJnHtHh=.CJPJaJnHtH h4zhd=CJPJaJnHtHhKohd=0J6CJaJh4zhd=CJaJhzTXCJaJ&?Q3wrj$a$gdd=gdd= $Pa$gdh$ & FP^`a$gdh$ & FP^`a$gdr=$ & FP^`a$gdp $Pa$gdp $ & FPa$gdr=$ & FP^`a$gdr=$ & F^`a$gdr= &:;<?B- P:ABDEFMNRҿҷүүүҧҘyh h9*CJmH sH h9*CJmH sH h%CCJaJhhhd=CJaJmH sH hYRCJaJhp$CJaJhnxCJaJhcxhd=CJaJhd=CJaJhjhd=CJaJhpCJaJhjhd=CJaJmHsHhnmCJaJmHsH-RZklrz~ ./01234=@ۻ}rh^Shjhd=CJaJhd=CJmH sH hd=CJmH sH he hd=CJaJjhcxhK~CJUaJ&jhd=CJUaJmHnHsH ujhd=CJUaJh]hd=B*CJaJphhd=CJaJh%CCJaJh}CJaJhhCJaJho|CJaJh} CJaJhYRCJaJhhhh6CJaJ 345UVWXY$%q$ & F 5P^5`a$gd2 $`a$gdMt $h^ha$gd $Pa$gdp $P`a$gdh^hgdzh^hgdK~gdK~$a$gdd=$a$gdd=@OSTUVWXYj|&,ȸvvnvncnWLhh2CJaJhMtB*CJaJphh} h} CJaJhtCJaJhMth2CJaJhMthCJaJh} CJaJh=\CJaJhd=CJaJmH sH hd=B*CJaJmH phsH hB*CJaJmH phsH hd=B*CJaJmH phsH h6hd=CJmH sH hK~CJaJhjhd=CJaJh_#}CJaJ$%*/0459OYnpqɶxxxl`Q```h hMtCJaJmH sH hCJaJmH sH h}CJaJmH sH hMtCJaJmH sH h hCJaJmH sH %hhB*CJaJmH phsH hB*CJaJmH phsH %h hB*CJaJmH phsH %h hB*CJaJmH phsH hB*CJaJmH phsH %h hB*CJaJmH phsH  $PPa$gdK~$a$gdd=gdd=$a$gdd= $Pa$gd2$ & F pL^`La$gdd= $Pa$gdp$ & F 8^8a$gd79;<Mm =YǿǛǏǏǏǀthǀ\T\hd=mH sH jhd=UmH sH h2DCJaJmH sH hG~CJaJmH sH hgHhd=CJaJmH sH h CJaJmH sH hnxCJaJmH sH hghd=PJnHtHh4zhd=CJaJhd=CJaJhd=CJaJmH sH hG~hG~CJaJmH sH hG~hd=CJaJmH sH h hd=CJaJmH sH  #9:GZ]d]^͜zozzgzz_SzzSh$ hd=CJ\aJhzCJaJhH&CJaJh5hH&CJaJhd=CJaJh5hd=CJaJh5hd=CJaJmH sH h$ hd=CJ\aJmH sH hd=CJmH sH h2DCJmH sH h hd=CJmH sH hd=mH sH jhd=UmH sH jh:lhzUmH sH jhd=UmHnHsH u  jk { ~ !!!!uiVi$hOnh/oCJOJQJaJmH sH h/oOJQJmH sH h/oB*CJaJmH phsH %h h/oB*CJaJmH phsH %h h/oB*CJaJmH phsH h/oB*CJaJmH phsH %h h/oB*CJaJmH phsH h/oCJaJh/oh/oCJaJh$ hd=CJ\aJhd=CJaJh5hd=CJaJ{ !!!!!z!{!|!~!!!!!!$a$gd/o $7$8$H$a$gdK& 7$8$H$gd/o `gd/o $h^ha$gd/o$a$gdd=$a$gd/o $PPa$gdK~!5!6666667f7777888U8#999999999־ξֶ֮֠|m["hd=6B*CJaJmH phsH hnhd=B*CJaJph%hnhd=B*CJaJmH phsH  h4hd=CJPJaJnHtHhXCJPJaJnHtHhSCJaJhSWCJaJh$CJaJhNCJaJhnfCJaJhnhd=CJaJh{hd=B*CJaJphhBLCJaJhd=CJaJ#789999:q;;<n$ & F pPd\$^`a$gdp$ & F pdd[$\$^a$gd.!$ & F pP^`a$gdp $P`a$gdpgdd= $h^ha$gdd= $P`a$gdp$ & F^`a$gdp 999:::::";1;T;p;q;;<<c=j====> >>>>>p>w>0?1?@@ȪȪȪТКВЊzrghsJhd=CJaJhCJaJhBz CJaJhp,!CJaJhCCJaJh&CJaJhKCJaJhqCJaJh9CJaJh2hCJPJaJnHtHh2hCJaJh.!CJaJhnhd=CJaJhd=B*CJaJmH phsH (hsJhd=6B*CJaJmH phsH  <==p>>?@@C@D@wcWOW$a$gdd= $h^ha$gdd=$ & F p^a$gd.!$ & F pPP^`a$gdp$ & F pP^`a$gdp$ & F pdd[$\$^a$gd.!$ & F pPP^`a$gdp$ & F pPd\$^`a$gd @@'@(@)@*@B@C@D@@@@@@@@AAAOBkBBB/C0CCCC޾{ph`XPPHhd=CJaJhaVCJaJh!#CJaJh]\CJaJhjdCJaJh < hd=CJaJhsJhd=0J5CJaJh Nhd=CJaJmH sH hd^CJaJh[$hd=CJaJ%h[$hd=B*CJaJmH phsH (hsJhd=6B*CJaJmH phsH h6CJ\aJhsJhd=6CJ\aJ%hnhd=B*CJaJmH phsH D@@@AAlBB2CCCDEEEzz$a$gd@ $ & Fa$gd@ $ & FPP^`a$gd N $Pa$gd N$ & Fdd[$\$a$gd@ $ & FPP^`a$gd N$ & FP^`a$gd NPgd9* $7$8$H$a$gd N CCCC DDDDDDDDDDEEEEEEEEFFFھھھڶڶ|iYLF hCJh,hd=CJmH sH hd=B*CJaJmH phsH %h hd=B*CJaJmH phsH %h hd=B*CJaJmH phsH hd=B*CJaJmH phsH hd=B*CJaJph3fh3hd=CJaJhd=CJaJhaVCJaJhjdhjd6CJaJhjdCJaJh[$hd=CJaJhwTGhd=5CJaJhwTGhd=0J5CJaJEFFnGJHHHHIII"I&I+I/I;I$$7$8$H$Ifa$gd $7$8$H$Ifgd $7$8$H$a$gd/^-HB1Mj `h5mƘ"Q (JBLPRH4r6 ~#!7μnrdnwfv~}#xt# R\ҪeBϺQe@ ׏n@0X&" OP&*@Ee(C!%cag< / L|>B0 !Xx\n23g r~*>ӛnԻs6#\ny$_/8^ٱg;1B{Y=UcmXa%_?:r._%OZˮFkꀾh O|f2 GɮZ_wUҽ,b? ;{<ݟn+ZB}u5Yeo`mv dQYmk GQۏ Qg~\EtX|6zgAW +Iw+!m/+'>G~{Y=r|HO/,ۻ)\&EYŹMI'a^D9،I2t}ܼqbv-c}k@HAo ׆j͞5šxqf..mBme1v7aOK׮=Lww=Lyg>rYT߮?xUZ(@d uH)pLu@P7b,͘Cb:u9yttZ5qY6s5q|bl n~}.8} ) / ~56oucv1V>c]|XtYp/ xc2E MŃoSa#阄M \MHiRKakXDڍt_T!DH7DvR/H6>,w%1m_tlڸ QLqaďbz G-<ۨl:Qwbr E|ӱO%j/XӋ6sωFě0mF~SE.2Ѷ3v|#xwM׮G>ˢ@HFK;Ju Ja%T2XֲUȥw2~!|-yFu$_OG]016T/gBwZ }f,,CgL[,Cx^+TdGϚ 'G\C:ҳK+];hNX:#gfoj51Է݊Dž%v*_ˤ_BF} ʏ9a&q~muoW5^継6{`IfcUB}No |s˅|m;;dhM*Z'F!fbdJbdMvX0FF5찏,jJåB BZק{伌9q itf:Mی6$iKfm\Iqj+;ۤ*xaF:zj>m֮{_1s{t;ǃcǒ$ā=6XQ3 È,;vHrcl07ckv5:Ϝݤf]ژ5:\ng[;+ɝ,ZjЩM%"b:6gL'];s^G4o~f kƼU+FTAB jg_bgy7xm>_:y21&] GgY/34fL T 4O_Ve1㇓ҧQ ˘AfCޮ(cƘ2Pٜ֝b8Uiy|e,b'zNigΥDq#]*$oJ{8w7Veu_/%Xa'ҙfNxov߽ؓ\GɘǸY6l+BczK9Z=E ao (#ztx )Y#T\U|+(c~"NU7Y>0J ⱡoo 5l_~v8a=_]u\3 x65$$If!vh54555#v4#v#v#v:Vl t654555ayt ]T$$If!vh54555#v4#v#v#v:Vl t654555ayt ]T$$If!vh54555#v4#v#v#v:Vl t654555ayt ]T @@@ d=NormalCJ_HaJmHsHtH P@P Heading 1$$@&a$6OJQJ]mH sH R@R Heading 2$7$8$@&H$CJOJQJmH sH \@\ Heading 3$7$8$@&H$6CJOJQJ]aJmH sH P@P Heading 4$@&56CJOJQJ\]^Jh@h Heading 5$$7$8$@&H$a$#5B*CJOJQJ\^JaJphd@d Heading 6$$7$8$@&H$a$5B*CJOJQJ\^JphD@D Heading 7$$@&a$ 5CJ \: @: Heading 9 $@&5\DA@D Default Paragraph FontVi@V  Table Normal :V 44 la (k(No List FB@F Body Text$a$B*CJaJph6U@6 Hyperlink >*B*phPP@P Body Text 2 7$8$H$CJOJQJmH sH VQ@"V Body Text 3$7$8$H$a$CJOJQJmH sH $O1$ goohl0$OA$ goohl1$OQ$ goohl2&Oa& uauthors.X@q. 4zEmphasis6]\O\ @ references$ & FdL(a$CJ_HmH sH tH bOb 4figure caption$ & FPa$CJ_HmH sH tH *W@* [$Strong5\e@ JaHTML Preformatted7 2( Px 4 #\'*.25@9CJOJ QJ ^J aJmH sH 0O0 Y mediumb-text,O, Y small-textFOF /?@A5UVY{|!T.u0}d5,MNdzhjk|}`  & ? Q 345UVWXY$%q{z{|~lt5!6!7!T!U!!!!!#####{%&&&&&&u(U)W)X)Y)Z)[)\)])^)))++S,,,8-- .-.////1112,33455.6/6Z6[6667888I999:;;;<<=a>?? ?/?0?1?9?=?B?F?R?S?p?t?x?|?}??????? ABKB}BBBB#CPCsCtCmDnDoD~DDErFGIeJfJgJrJsJJJ=KKLzLLMMNNNNNNNOO=O>OMONO_OgOhOOOOOOOOOOOOOOOPP-P.P?P@PUPePfPvP}P~PPPPPPPPPPPPPPPQ%Q&Q>QZQ[QvQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQRRRRR*R+RGRHRXRdRjRkRRRRRRRRRRRSSSS S2S?SJSKSYShSiSmSnSrSsSwSxSzS{S}S~SSSSSSSSSSSSSSSSSSSSSSSSST000000000000000000 0 0 0 00 0 0 0 00000000000000000 0 0 0 00 0 0 0 0 000000000000000000000000000@0@0000000000000000000000000000000000000000000000 0 0 0 0 0 000000 0 0 0 0 0 0 0 0 000000 0 0 0 0 0 00 0 0000000000000 00 00 0 0 0 0 0 0 0 0 0 0 0 0 0000 0 0 00 0 0 0000000000000000 0 0 0 0 0 0 0 0 0 0 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000@0@00000@000@0@000@000@000@0@000@000000000000000@000@00000@000@000@0@000000X0,MNdzhjk|}`  & ? Q 345UVWXYq{z{|~lt6!7!T!!!!!####{%&&&&&&u(U)W)X)Y)Z)[)\)])^)))++S,,,8-- .-.////1112,33455.6/6Z6[6667888I999:;;;<<=a>?? ?/?0?1?=?F?R?S?p?t?x?|?}??????? ABKB}BBBB#CPCsCtCoD~DDErFGeJfJgJrJsJJJ=KKLzLLMMNNNNO=OMO_OgOOOOOOOOOOPP-P?PUPePvP}PPPPPPPPQ%Q>QZQvQQQQQQQQQQQQQQQQRRGRXRdRjRRRRRRRSSS2S?SJSYShSmSrSzS}ST000000000000000000 0 0 0 00x 0x 0x 0x 0x0x@0x0x0x0x0x0x0x0x0xZ0%0Z0+0@0xA 0xA 0xA 0x0 06 x 06 x 06 x 06 xB 06 @0@0x000x0x0x0x0x0x@0@0@0x@0x@0x@0x@0x@0x@0x@0x@0x@0x@0x@0x@0x@0x@0x@0x@0x@0xZ0U0VDz00@000@0x0@00@00000(0(0(0(00000@0000000000000 0 0 0 0 0 000000 0B 0B 0B 0B 0B 0B 0B 0B 00000@0@ 0@ 0@ 0@ 0@ 0@ 0@0@ 0 00000H@03@03@03@03@03@03@03@03@03@03@03@03@03@03@03@03@03@03@03@03@03@03@030x0x0x 0x 0x0x0x 0x 0x 0x0x0xZ000x0x0x0x@00000 0 0 0 0 0 0 0 0 00@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0k e&R@!!($&W)+.1b139@CFcI`MnQQTUuXYZZ~[[\\g]]/234679:<=>@ACDEGHIKLNPRTVZ\]^_acdfhikm3!)U17<D@E;IeIIKgNXYZ[\B]]]058;?BFJMOQSUWXY[`begjln]1.1~7!O!R!TX____01/XR$VA#vR$|9Xeg[.E{@@0 @(  t B P!16 3  s"*?n  c $X99?"`B P!16lB  0D2X> ) .)R  H7uuf32Xl )B, 7R  H6uuf32X)B, 6R  H5uuf32X))-B, 5fB  s *D2X B, (/  H4uuN2XB .n1 4fB  s *D2X)2  H3uuN2X25 3fB  s *D2XIB,J/  H2uuN2X/*2 2fB  s *D2X)2  H1uuN2X22 4 1fB  s *D2Xp-B,q-.  H0uuN2X)./^2 0lB  0D2X>"Q-"lB  0D2X1"1K$lB  0D2Xp"pK$lB  0D2Xg"gK$lB  0D2X^"^K$lB  0D2X"K$lB  0D2X8#"8#K$lB  0D2X> .&Q-B&  H.uuN2X"`P$% .lB  0D2X.&'lB  0D2XR.&R'lB  0D2X.&'lB  0D2X.&'lB  0D2X!.&!'lB   0D2Xb%.&b%'lB   0D2XY).&Y)'   H-uu N2X'2.\6 -   H,uu N2X X'( ,fB   s *D2X)B,)&2J B &0tC 23  s"*?` 3 c $X99?B &0tCfB G s *D2XFP(F) F NllFf2X"`&( B 4 Hll42X)/ B 5 Hll52XL0!w6 B 6 Hll62X>$7t+.= fB 7 s *D2X{ ,,`B 8 c $D2Xl }*l ,fB 9B s *D2X,,`B : c $D2X}*,`B ; c $D2XF/F33fB < s *D2XUB3DB3fB =B s *D2X B3h&B3fB > s *D2Xs:M$:`B ? c $D2Xsw6s:fB @B s *D2X+:f.:`B A c $D2Xf.17f.:fB B s *D2X'<'> C HllC2X (+  D HllD2X}(+  E HllE2X/2  H B llH2X8#/},R3   I B llI2X6$9   J B llJ2X >'?   K B llK2X(R3X07   L H llLf2X13'E6   M HllMf2X@;=$>  N HllNf2X 3(V6  O BllOf2X(=q/?  P HllP2XS"'0)  Q HllQf2XS"*0\/  R HllRN2Xu%<#'>  S HllSN2X~7,K9  T HllTN2X\/41  B @ 73F U3  s"*?` V c $X99?B @ 73FfR W s *>7 %F X H n7 n7XN2X F4  Y H n7 n7YN2X'@    Z H n7 n7ZN2X '/4  [ H n7 n7[2X!^A  \ H n7 n7\2X r  ] H n7 n7]2Xp  ^ H n7 n7^f32X   _ H n7 n7_2X!#  ` H n7 n7`N2X"`"l.  a H n7 n7aN2Xi + f b s *3N2X$$% f c s *N2X  d H n7 n7dN2XB qj .  B *3  e3  s"*?` f c $X99?B *3 lB g 0D2XԔ 1'fB hB s *D2XԔfS`B i c $D2X -rfB j s *D2XԔ"1"C`B k c $D2X1'1' l H+rrlN2X"` 1 + m H*rrmN2X"`? * n H)rrnN2X"`!? ) o H(rroN2X"`O#&= ( p H'rrpN2X"`(p 0K 'b q TJtY&rrqf32XB *0 &fr r s *;[f32Xb !Ffr s s *;[f32X&1&_ w H"rrwN2Xz()  "fB x s *D2X)L1LfB y s *D2X)1fB z s *D2X%)1fB { s *D2XD)y1yb | T]!rr|E2X3k  ! } H rr}N2Xs     H8rrN2X*k+ 8  H%rrN2XDo.  %  H9rrN2X!# 9@ 0*81 Z  3 BM/81 BZ  3 AM/" 81 AZ  3 @" M/ 81 @Z  3 ? M/81 ?Z  3 >M/81 >Z  3 =M/81 =t  S <"`- / <t  S ;"` -/ ;t  S :"`-/ :fB  s *D b-d-fB  s *Dx+y+t  S $"`,a- $t  S #"` 0*Kv+ #  H/w;w;N2X /B S  ?/|P!U)Teh#t U t < t"t 2tW_t 2`2`J 2`$J 2`dJ 2`J 2`J 2`$J 2`dJ 2`J 1K1KKKLLT7K7KKKLLT9*urn:schemas-microsoft-com:office:smarttagsplace8 *urn:schemas-microsoft-com:office:smarttagsCityB*urn:schemas-microsoft-com:office:smarttagscountry-region Ț -L"$46{}h25QRefvw [ c   % & > B   P Q  89AFMNZ[rtz{  =TYjk/0&(,-~89#$9:]^de]^tu  OPjk~45y{~ACx,-k/?BY34HKbcABNOprvw1!2!!!!!!R"U""""#x%{%%%%%&&&'+',';')))))5)6)T)q))))))) + + ++++,,,,,,--5-8---. .*.-.j.k.=/>/////0111k1l1111122>3?3a3b33333-4/44444H5I555-6/6>6A6Y6[6666666&7'7 88f8g8888888F9I99999):*:::::;<<<d=e=======a>d>>>>>>?.?1?OLONOfOhOOOOOOOOOOO,P.P0P1P>P@PdPfP|P~PPPPPPPPP$Q&QYQ[QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQRRRRR)R+RFRHRKRMRiRkRRRRRRRRRRRSSSSS S#S%S2S6S?SBSISKSNSPSgSiSlSnSqSsSvSxSzS{S|S~SSSSSSSSSSSSSSSSSST-Lg_ c   % & > B P Q =TYz{yk(U!Y!l!r!!##z%{%&8' ((()T))++++R,S,,,,,7-8---. .,.-.//11111122+3,333445555-6/6Y6[6666677 888888H9I99999::;<==`>d>?? ? ?.?1?8?9?OLONO^O_OfOhOOOOOOOOOOOOOOOOOOOPPPP,P.P>P@PTPUPdPfPuPvP|P~PPPPPPPPPPPPPQQ$Q&Q=Q>QYQ[QuQvQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQRRRRR)R+RFRHRWRXRcRdRiRkRRRRRRRRRRRRRSSSSS S1S6S>SBSISKSXSYSgSiSlSnSqSsSvSxSzS{S}S~SSSSSSSSSSSSSSSSSSSSSSSSSSSST33333"+Ndhl ? =Wr##)^),,S,//114466>? ?S?p?}???}BBJKNNNNNN>OLONOfOOOOOOOOOP,P.P>PfP|P~PPPPPPPPQ$Q&Q>Q[QvQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQRRRRR)R+RFRHRiRkRRRRRSSS SISKSgSiSlSnSqSsSvSxSyS{S|S~SSSSSSSSSSSSSSSSSSTNT k:2 0PO)h3#`hF:fZUXTy~:=hOvW+4.p;K=lZV&iJYc"wH6zzxoM 83 J }  e P @ kXk^d==-90/oR,}W6ASnfdg:)8:Vk,afr L Np@my}t Bz p,!et!!#fc#O>$A0%A&E&K&z''4'*=)I*R~* K,c,~,tF-a-x-=.N/t/T2r2V3657 8 <8G8a9 :D;<x=>CA5xBDD2DSDwTGHJbsJsJALBLOGM5N8NSNQO Pw/PhQ~R;R6TUVUaVzTXMZWyZT[:g[=\ ]~`K aJa-{a-kb cc3cee/ u#w".w#xcxnx{:yFyXyfy4zT@z4|o|_#}G~K~j=GbG|5nI2@49r=8rS(;Lmr#.SY4jnX`fH&LoE]_$Qy'np RDv|{G}%C459 0M*Im$ /\{*iv]<"4eOU]\jdz(`c&d^E[$k8.!~JjK]t @Nu SW LDZrY1[gHc9*$djoNbKJ'Sp$6\3,b:*<lbD[d!q F}9-K#:=2M fQ[T&CYjw'GYRRyIth 0J]I@Miw)[66? ?/?0?1?=?F?R?S?p?t?x?|?}??????eGNKSTcs'@++}RR++(-.TP@P6Pp@Unknown G:Ax Times New Roman5Symbol3& :Cx Arial;(SimSun[SOkTimesNewRomanPSMTTimes New RomanG5  jMS Mincho-3 fg3:Ax Times7& [ @VerdanaY Arial-BoldItalicMTArial?5 :Cx Courier New;Wingdings"qhIy[&A B( B(24dNN 2qHP(?O>$2~Coupled with the growing interest in the Universal Mobile Telecommunication System (UMTS) as a standard for future mobile commIlonkaetkdedu                           Oh+'0(4DP\l |    Coupled with the growing interest in the Universal Mobile Telecommunication System (UMTS) as a standard for future mobile commIlonkaNormaletkdedu65Microsoft Office Word@?6@:q@y 3@/r B՜.+,D՜.+,h hp|  Ght(N' Coupled with the growing interest in the Universal Mobile Telecommunication System (UMTS) as a standard for future mobile comm Title 8@ _PID_HLINKSAx-Vmailto:denis.duka@ericsson.com  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnoprstuvwxz{|}~      %Root Entry F>r'Data q1Tabley/WordDocumentSummaryInformation(DocumentSummaryInformation8CompObjq  FMicrosoft Office Word Document MSWordDocWord.Document.89q