Use of ITU-T languages in Nokia


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 7 7 7 Step 1 - System architecture functional specification: text with embedded MSC diagrams in our case: JAFFA project deliverables Stage 2 - Protocol specification object-oriented analysis and design with UML detailed protocol specification as a SDL-model => needs to pass validation (by human observation) and verification (by computer-aided analysis); the latter serves the same purpose as simulation studies w.r.t. multiple-access method selection on layer 1 messages and information elements described as ASN.1 protocol data units validation and verification of the specified protocols layer interfaces described as ASN.1 abstract service primitives in our case: GUN project deliverables Stage 3 - Protocol implementation may use code generation from SDL or other methods in our case: 3gen product development
  • Use of ITU-T languages in Nokia

    1. 1. Use of ITU-T languages in Nokia Colin Willcock Nokia Research Center ITU-T Workshop Geneva, July 2004 [email_address] Experiences and Challenges
    2. 2. Contents <ul><li>Specification Languages </li></ul><ul><ul><li>MSC </li></ul></ul><ul><ul><li>ASN.1 </li></ul></ul><ul><ul><li>SDL </li></ul></ul><ul><li>Testing Languages </li></ul><ul><ul><li>TTCN-2 </li></ul></ul><ul><ul><li>TTCN-3 </li></ul></ul><ul><li>Future Trends </li></ul>
    3. 3. Specification: MSC <ul><li>used in two ways: </li></ul><ul><li>design and requirements notation </li></ul><ul><ul><li>to clarify interactions of components in a system (both in standards and in implementations) </li></ul></ul><ul><ul><li>used extensively for the representation of design and requirements for software object interaction with messages </li></ul></ul><ul><li>trace output notation </li></ul><ul><ul><li>to show how system behaved(in environments that naturally support this (=Telelogic tools)) </li></ul></ul><ul><ul><li>used with phone trace output to provide a clear representation of the phones behaviour. A number of tools are used to provide MSC representation from phone software trace output. </li></ul></ul>
    4. 4. Specification: ASN.1 <ul><li>Used a lot. Partly because it is used in a lot of standards in mobile communication. But also it has been found a convenient means to define protocols and to get codecs generated automatically. </li></ul><ul><li>Used extensively in conjunction with TTCN-2 and SDL to define data types used in the protocol software implementation and testing. i.e. both products and product test systems. </li></ul><ul><li>Internal CASN compiler tools </li></ul><ul><li>SDL. Note: not following Z.105 but defined own mapping of ASN.1 to SDL data. </li></ul>
    5. 5. Specification: SDL <ul><li>SDL is used to create protocol emulators for testers. This is enabled by 3G SDL library project. </li></ul><ul><li>Nokia NET has own version of the SDL that is is used quite extensively in some products. </li></ul><ul><li>On the NMP side used extensively for the design of many protocol software sub-systems (embedded and workstation based simulation). These models are used as the basis for automatic code generation using various SDL->C code generators. </li></ul>
    6. 6. Current Specification Process <ul><li>Step 1 - System architecture </li></ul><ul><li>functional specification: text with embedded MSC diagrams </li></ul><ul><li>Stage 2 - Protocol specification </li></ul><ul><li>object-oriented analysis and design with UML </li></ul><ul><li>detailed protocol specification as an SDL-model </li></ul><ul><li>messages and information elements described as ASN.1 protocol data units </li></ul><ul><li>layer interfaces described as ASN.1 abstract service primitives </li></ul><ul><li>Stage 3 - Protocol implementation </li></ul><ul><li>may use code generation from SDL or other methods based on SDL specifications </li></ul>
    7. 7. Introduction of TTCN-2 Testing <ul><li>Since 1993 TTCN-2 testing has been used in testing of </li></ul><ul><li>GSM network elements: MSC/VLR, HLR, BSC, MS </li></ul><ul><li>Other 2 nd generation mobile phones: D-AMPS </li></ul><ul><li>Transmission systems: V5.x </li></ul><ul><li>IN systems: SSP, SCP </li></ul><ul><li>In-house TTCN-2 tool developed with HUT </li></ul><ul><li>first compiler based on DIS version of the TTCN language in 1990-91 </li></ul><ul><li>tight integration with Nokia in-house ASN.1 tools </li></ul>
    8. 8. Early Experiences on TTCN-2 Testing <ul><li>testing with several PCOs : some PCOs are used as means for triggering test events to other PCOs </li></ul><ul><li>well-designed test suites can be executed and analyzed automatically </li></ul><ul><li>TTCN test suites are designed by a test team, which is independent from the product development team </li></ul><ul><li>tools for TTCN programming are available </li></ul><ul><li>development of an ETS based on TTCN ATS still requires some programming for test adaptors </li></ul><ul><li>TTCN based method is not as flexible for interactive probing as protocol emulators </li></ul><ul><li>validation of TTCN test suites prior to testing against SUT is a must </li></ul>
    9. 9. Evolution of TTCN-2 Testing <ul><li>Test automation has evolved with TTCN </li></ul><ul><li>Modular and Concurrent TTCN in network element testing </li></ul><ul><li>Improved integration with other languages => TTCN-2 </li></ul><ul><ul><li>Modelling of PDUs in ASN.1 also for non-ASN.1 protocols </li></ul></ul><ul><ul><li>Cosimulation with SDL as means for test case validation </li></ul></ul><ul><ul><li>MSC tracing of test case executions </li></ul></ul><ul><li>Standardized test suites, especially by ETSI </li></ul><ul><li>Automatic test case generation – still a promise? </li></ul><ul><li>TTCN testing has expanded to new systems within Nokia </li></ul><ul><ul><li>GPRS: SGSN </li></ul></ul><ul><ul><li>UMTS: Node-B, RNC, MSC Server, MGW </li></ul></ul><ul><ul><li>VoIP: CPS, HSS </li></ul></ul>
    10. 10. Testing: TTCN-2 Summary <ul><li>Still under development at international bodies, e.g. Bluetooth and the test system for 3G UEs. </li></ul><ul><li>Used extensively in Workstation and HW platform test environments for testing protocol software. This includes sub-system integration, system integration, release, regression and conformance testing. </li></ul><ul><li>Quite successful in conformance testing but limitations in flexibility and ease of learning have stopped it spreading to other areas of testing </li></ul>
    11. 11. Future Testing Challenges <ul><li>Increasing complexity of products </li></ul><ul><ul><li>GSM Specifications 1306 </li></ul></ul><ul><ul><li>3G Specifications 2290 </li></ul></ul>
    12. 12. Future Testing Challenges <ul><li>Pressure to shorten time to market </li></ul><ul><ul><li>New systems and services must be available quicker </li></ul></ul><ul><ul><li>How can we reduce testing time? </li></ul></ul><ul><li>Pressure to improve quality </li></ul><ul><ul><li>SW outage average time for Network elements measured in seconds per year </li></ul></ul><ul><ul><li>How can we improve testing quality (and quantify it) </li></ul></ul><ul><li>New types of testing </li></ul><ul><ul><li>IP based protocols </li></ul></ul><ul><ul><li>Text based protocols </li></ul></ul><ul><ul><li>Unified testing approach for software and protocol testing </li></ul></ul>
    13. 13. Why is TTCN-3 Important <ul><li>More Productive </li></ul><ul><ul><li>Easier to learn </li></ul></ul><ul><ul><li>Easier to use </li></ul></ul><ul><li>More Powerful </li></ul><ul><ul><li>Extended functionality </li></ul></ul><ul><ul><li>Support for IP protocol </li></ul></ul><ul><ul><li>Support text-based protocols </li></ul></ul><ul><li>More Flexable </li></ul><ul><ul><li>Not tied to OSI model </li></ul></ul><ul><ul><li>For many types of testing </li></ul></ul><ul><li>More Extendable </li></ul><ul><ul><li>Extensibility built-in </li></ul></ul>Software Testing Protocol Testing TTCN-2 TTCN-3 Function Module Layer Unit Intergration
    14. 14. TTCN-3 <ul><li>Nokia has been from the very beginning actively involved in the development of the TTCN-3 language at ETSI. </li></ul><ul><li>The first product testers using TTCN-3 where introduced in Nokia in 2002. </li></ul><ul><li>TTCN-3 especially strong in the text based protocol area like SIP. </li></ul><ul><li>Used for almost all new test systems </li></ul><ul><li>Investigation about usage in application areas that are not typical protocol testing such as software module testing. </li></ul><ul><li>Area of active research and development. Conversion of test systems from TTCN-2 to TTCN-3 already started . </li></ul>
    15. 15. Future Trends : Specification <ul><li>Short term </li></ul><ul><ul><li>UML 2.0 tools will mature and the gaps will be filled to enable UML to be used not just at the abstract specifications (requirements) phase but further down towards implementation </li></ul></ul><ul><li>Medium Term </li></ul><ul><ul><li>As UML 2.0 tools mature and become available there will be a general move from SDL to UML for functional specification </li></ul></ul><ul><li>Long Term </li></ul><ul><ul><li>UML will become the glue which finally enables MBD to be realised </li></ul></ul>
    16. 16. Future Trends: Testing <ul><li>Short term: </li></ul><ul><ul><li>Replacing TTCN-2 in functional and conformance testing as standard language. </li></ul></ul><ul><ul><li>Increasing use within the IP world especially for text based protocols </li></ul></ul><ul><ul><li>Possible key technology in the IP/telecom convergence. </li></ul></ul><ul><li>Medium term: </li></ul><ul><ul><li>Expanding from pure protocol testing to software testing and interworking testing. </li></ul></ul><ul><ul><li>Possible key technology for unifying testing technology across whole product development. </li></ul></ul><ul><li>Long term: </li></ul><ul><ul><li>Real time and performance testing? (European INTERVAL project) </li></ul></ul><ul><ul><li>Integration with UML (UML testing profile) </li></ul></ul>