Presentation on theme: "Use of ITU-T languages in Nokia"— Presentation transcript:
1 Use of ITU-T languages in Nokia Experiences and ChallengesColin WillcockNokia Research CenterITU-T WorkshopGeneva, July 2004
2 Contents Specification Languages Testing Languages Future Trends MSC ASN.1SDLTesting LanguagesTTCN-2TTCN-3Future 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 messagestrace output notationto 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.1Used 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 toolsSDL. Note: not following Z.105 but defined own mapping of ASN.1 to SDL data.
5 Specification: SDLSDL 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 architecturefunctional specification: text with embedded MSC diagramsStage 2 - Protocol specificationobject-oriented analysis and design with UMLdetailed protocol specification as an SDL-modelmessages and information elements described as ASN.1 protocol data unitslayer interfaces described as ASN.1 abstract service primitivesStage 3 - Protocol implementationmay use code generation from SDL or other methods based on SDL specificationsStep 1 - System architecturefunctional specification: text with embedded MSC diagramsin our case: JAFFA project deliverablesStage 2 - Protocol specificationobject-oriented analysis and design with UMLdetailed 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 1messages and information elements described as ASN.1 protocol data unitsvalidation and verification of the specified protocolslayer interfaces described as ASN.1 abstract service primitivesin our case: GUN project deliverablesStage 3 - Protocol implementationmay use code generation from SDL or other methodsin our case: 3gen product development777
7 Introduction of TTCN-2 Testing Since 1993 TTCN-2 testing has been used in testing ofGSM network elements: MSC/VLR, HLR, BSC, MSOther 2nd generation mobile phones: D-AMPSTransmission systems: V5.xIN systems: SSP, SCPIn-house TTCN-2 tool developed with HUTfirst compiler based on DIS version of the TTCN language intight 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 PCOswell-designed test suites can be executed and analyzed automaticallyTTCN test suites are designed by a test team, which is independent from the product development teamtools for TTCN programming are availabledevelopment of an ETS based on TTCN ATS still requires some programming for test adaptorsTTCN based method is not as flexible for interactive probing as protocol emulatorsvalidation of TTCN test suites prior to testing against SUT is a must
9 Evolution of TTCN-2 Testing Test automation has evolved with TTCNModular and Concurrent TTCN in network element testingImproved integration with other languages => TTCN-2Modelling of PDUs in ASN.1 also for non-ASN.1 protocolsCosimulation with SDL as means for test case validationMSC tracing of test case executionsStandardized test suites, especially by ETSIAutomatic test case generation – still a promise?TTCN testing has expanded to new systems within NokiaGPRS: SGSNUMTS: Node-B, RNC, MSC Server, MGWVoIP: 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
12 Future Testing Challenges Pressure to shorten time to marketNew systems and services must be available quickerHow can we reduce testing time?Pressure to improve qualitySW outage average time for Network elements measured in seconds per yearHow can we improve testing quality (and quantify it)New types of testingIP based protocolsText based protocolsUnified testing approach for software and protocol testing
13 Why is TTCN-3 Important TTCN-3 More Productive Easier to learn Easier to useMore PowerfulExtended functionalitySupport for IP protocolSupport text-based protocolsMore FlexableNot tied to OSI modelFor many types of testingMore ExtendableExtensibility built-inTTCN-2Software TestingProtocol TestingFunctionModuleLayerUnitIntergrationTTCN-3
14 TTCN-3Nokia 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 systemsInvestigation 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 termUML 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 implementationMedium TermAs UML 2.0 tools mature and become available there will be a general move from SDL to UML for functional specificationLong TermUML 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 protocolsPossible 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)