170 likes | 326 Views
Use of ITU-T languages in Nokia. Experiences and Challenges. Colin Willcock Nokia Research Center ITU-T Workshop Geneva, July 2004 colin.willcock@nokia.com. Contents. Specification Languages MSC ASN.1 SDL Testing Languages TTCN-2 TTCN-3 Future Trends.
E N D
Use of ITU-T languages in Nokia Experiences and Challenges Colin Willcock Nokia Research Center ITU-T Workshop Geneva, July 2004 colin.willcock@nokia.com
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 2nd 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
Evolutionof 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 Specifications2290
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
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 Function Module Layer Unit Intergration Why is TTCN-3 Important TTCN-2 Software Testing Protocol Testing TTCN-3
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)