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

540
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
540
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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)