Your SlideShare is downloading. ×
Use of ITU-T languages in Nokia
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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
  • Transcript

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