Optoelectronics' Jan Financial Highlights

460 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
460
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Optoelectronics' Jan Financial Highlights

  1. 1. UMTS terminal testing: A practical perspective <ul><li>Olaf Bergengruen </li></ul><ul><li>May , 200 3 </li></ul>
  2. 2. „ We will not survive without a proper regression test system“, an Optimay engineer
  3. 3. Overview <ul><li>Virtual testing </li></ul><ul><ul><li>Logical view (what we want to test) </li></ul></ul><ul><ul><li>Why virtual testing </li></ul></ul><ul><ul><li>Requirements to the test system </li></ul></ul><ul><li>3GPP approach </li></ul><ul><ul><li>Test model </li></ul></ul><ul><ul><li>Test cases </li></ul></ul><ul><li>Optimay‘s implementation </li></ul><ul><ul><li>GSM/GPRS virtual test system </li></ul></ul><ul><ul><li>GSM/GPRS/UMTS virtual test system </li></ul></ul>
  4. 4. Test environment / logical view (conformance testing, FTA)
  5. 5. Test environment / logical view (2)
  6. 6. Why virtual test environment <ul><li>We need a SW only environment (no specific HW) </li></ul><ul><ul><li>HW is expensive or does not exist </li></ul></ul><ul><ul><li>HW debugging is difficult and time consuming </li></ul></ul><ul><ul><li>SW developers don‘t want to be bothered with HW issues or don‘t have the specific skills </li></ul></ul><ul><li>We need to be much faster than real time </li></ul><ul><li>Developers want to use standard tools (compilers, editors, debuggers) </li></ul>
  7. 7. Requirements to the virtual test system <ul><li>Test system shall be much faster than real time </li></ul><ul><li>Support the design of test scenarios at a high level of abstraction </li></ul><ul><li>All test suites need to run ‚over night‘: GSM/GPRS tests (GSM 11.10), UMTS test (3GPP 34.123), STK tests (GSM 11.10-4), MMI test cases and possibly other suites (TCP/IP, WAP, ...) </li></ul><ul><li>Test system shall be available to anybody, at anytime, on any PC </li></ul>
  8. 8. GSM/GPRS test architecture
  9. 9. GSM/GPRS test architecture
  10. 10. Great approach: L1 simulated interface <ul><li>Basic communication with the Tester via three functions: RxRadioBlock, TxRadioBlock, TimerTick </li></ul><ul><li>These functions can be extended as needed to simulate DSP code or other HW related functionality </li></ul><ul><li>MS is the master of system ‚ticks‘, about 100 times faster than real time </li></ul><ul><li>Tester and MS are tightly coupled which allows debugging using standard tools </li></ul>
  11. 11. Debugging GMM code ... <ul><li>static void GM M DoRoutingAreaUpdate ( GM_IE_UPDATE_TYPE RauType, BOOLEAN FirstAttempt ) </li></ul><ul><li>{ </li></ul><ul><li>MMRAUpdPending = FALSE; </li></ul><ul><li>GMRauType = RauType; </li></ul><ul><li>GMStopT3302( ); </li></ul><ul><li>GMStopT3311( ); </li></ul><ul><li>if ( ! FirstAttempt ) </li></ul><ul><li>{ </li></ul><ul><li>GMT3330Expiries = 0; </li></ul><ul><li>if ( GMActState == GMActDetachInit ) </li></ul><ul><li>{ </li></ul><ul><li>GMStopT3321( ); </li></ul><ul><li>GMDetachPending = TRUE; </li></ul><ul><li>} </li></ul><ul><li>} </li></ul><ul><li>if ( GMTriggerAction == GM_GS_ATTACH_COMP ) </li></ul><ul><li>{ </li></ul><ul><li>/* Reinitialise the trigger action variable. */ </li></ul><ul><li>GMTriggerAction = GM_NO_TRIGGER_ACTION; </li></ul><ul><li>/* Confirm the end of the ATTACH procedure to GS */ </li></ul><ul><li>SEND( GSGMEstCnf ) ( ); </li></ul><ul><li>} </li></ul>
  12. 12. Highlights of our GSM/GPRS virtual test system <ul><li>Extremely efficient performance (around 1300 tests in 20 minutes) </li></ul><ul><li>Includes testing of DSP code </li></ul><ul><li>About 30 man-years development effort (including test case development) </li></ul>
  13. 13. Drawbacks of our GSM/GPRS simulation <ul><li>Tester uses proprietary (in house) test script languages and encoders which are difficult to maintain </li></ul><ul><li>It is difficult to write test cases </li></ul><ul><li>Tester is not nicely layered as shown in the previous slide, so it is difficult to extend and maintain </li></ul><ul><li>Summarizing: the system can not be extended to implement an UMTS System Simulator </li></ul>
  14. 14. 3GPP test model (TS 34.123-3)
  15. 15. Why we need a Test Model <ul><li>Main reason for us : If we comply with the 3GPP Test Model we can use the TTCN test cases developped here at ETSI / STF 160 </li></ul><ul><li>In general: </li></ul><ul><ul><li>Clear and stable interfaces to the SS enables manufacturers to develop the test equipment </li></ul></ul><ul><ul><li>It reduces ambiguities within test case scenarios </li></ul></ul><ul><ul><li>It enables outsourcing of testing activities and SW re-use </li></ul></ul><ul><ul><li>It provides a common consens or understanding of the complete system to manufacturers and operators </li></ul></ul>
  16. 16. A test case (1/2) ... <ul><li>Configure SS </li></ul><ul><ul><li>Configure PHY / L1 </li></ul></ul><ul><ul><li>Configure MAC </li></ul></ul><ul><ul><li>Configure RLC </li></ul></ul><ul><li>Schedule and send System Information Blocks </li></ul><ul><li>Test case preamble </li></ul><ul><ul><li>Bring UE into initial state (e.g. CS and PS registration) </li></ul></ul><ul><ul><ul><li>Perform Location Update procedure </li></ul></ul></ul><ul><ul><ul><li>Perform GPRS Attach procedure </li></ul></ul></ul>
  17. 17. <ul><li>Test case body </li></ul><ul><ul><li>Stimulate the UE, e.g. </li></ul></ul><ul><ul><ul><li>Send X message to the UE, or </li></ul></ul></ul><ul><ul><ul><li>Change cell power levels, or </li></ul></ul></ul><ul><ul><ul><li>Trigger the UE via AT command to initiate a call </li></ul></ul></ul><ul><ul><li>Verify responses </li></ul></ul><ul><ul><ul><li>Match messages from the UE to expected values </li></ul></ul></ul><ul><ul><ul><li>Assign a verdict (PASS, FAIL, INCONC) </li></ul></ul></ul><ul><li>Test case postamble </li></ul><ul><ul><li>Complete signalling to bring UE into stable state </li></ul></ul>A test case (2/2) ...
  18. 18. So, how to design a Virtual Tester which matches the 3GPP model and our requirements ?
  19. 19. Problems designing an overall GSM/GPRS/UMTS Test Env. <ul><li>The clean 3GPP model is not enough for a complete MS test environment </li></ul><ul><li>We need to re-use tools, tracers, and most of all test cases developed for GSM in the new environment </li></ul><ul><li>We can not afford to develop the UMTS test suite in house, we need to re-use the 3GPP tests </li></ul><ul><li>The L1 and DSP simulation strategies for GSM do not match those of UMTS </li></ul>
  20. 20. Current approach (a compromise) <ul><li>Multi-threaded system: The proper MS, the GSM SS, the UMTS SS and the SIM simulator </li></ul><ul><li>All communicating via shared buffers </li></ul><ul><li>The tick-master is the MS, when all jobs for current frame are completed, it issues a ‚tick‘ and all System Simulators prepare data (radio blocks) for next frame. </li></ul><ul><li>Each SS will send a ‚tick-ack‘ to the MS when it is ready for next frame </li></ul><ul><li>When all SSs are done: the MS L1 engine will fetch or store a radio block </li></ul>
  21. 21. GSM/GPRS/UMTS Test Environment
  22. 22. Summary <ul><li>A Virtual Test Environment is an essential tool </li></ul><ul><ul><li>for development </li></ul></ul><ul><ul><li>for quality assurance </li></ul></ul><ul><li>3GPP test model </li></ul><ul><li>A rough overview of our implementation </li></ul>
  23. 23. Thank you.

×