Use of ITU-T languages in Nokia
Upcoming SlideShare
Loading in...5

Use of ITU-T languages in Nokia






Total Views
Slideshare-icon Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 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 Use of ITU-T languages in Nokia Presentation Transcript

  • Use of ITU-T languages in Nokia Colin Willcock Nokia Research Center ITU-T Workshop Geneva, July 2004 [email_address] Experiences and Challenges
  • Contents
    • Specification Languages
      • MSC
      • ASN.1
      • SDL
    • Testing Languages
      • TTCN-2
      • TTCN-3
    • Future Trends
  • 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.
  • 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.
  • 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.
  • 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
  • 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
  • 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
  • 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
  • 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
  • Future Testing Challenges
    • Increasing complexity of products
      • GSM Specifications 1306
      • 3G Specifications 2290
  • 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
  • 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
  • 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 .
  • 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
  • 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)