OPEN BASE STATION ARCHITECTURE INITIATIVE

Transcription

1 OPEN BASE STATION ARCHITECTURE INITIATIVE Conformance Test Specification Appendix H UDPCP Test Cases Version.00 Issue.00 (38)

2 FOREWORD OBSAI description and specification documents are developed within the Technical Working Group of the Open Base Station Architecture Initiative Special Interest Group (OBSAI SIG). Members of the OBSAI TWG serve voluntarily and without compensation. The description and specifications developed within OBSAI represent a consensus of the broad expertise on the subject within the OBSAI SIG. The OBSAI SIG uses the following terminology in the specifications: "shall" expresses a provision that is binding "should" and "may" expresses non-mandatory provisions "will" expresses a declaration of purpose on the part of the OBSAI SIG. It may be necessary to use "will" in cases where the simple future tense is required Use of an OBSAI reference or specification document is wholly voluntary. The existence of an OBSAI Specification does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the OBSAI Specification. Furthermore, the viewpoint expressed at the time a specification is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the specification. Every OBSAI Specification is subjected to review in accordance with the Open Base Station Architecture Initiative Rules And Procedures. Implementation of all or part of an OBSAI Specification may require licenses under third party intellectual property rights, including without limitation, patent rights (such a third party may or may not be an OBSAI Member). The Promoters of the OBSAI Specification are not responsible and shall not be held responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights. The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of OBSAI Member s customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of OBSAI Management Board. The document has been prepared for use by professional and properly trained personnel, and the customer assumes full responsibility when using it. OBSAI Management Board, Marketing Working Group and Technical Working Group welcome customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between OBSAI members. However, the OBSAI Management Board, Marketing Working Group or Technical Working Group have made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Issue.00 (38)

3 OBSAI liability for any errors in the document is limited to the documentary correction of errors. OBSAI WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), that might arise from the use of this document or the information in it. This document and the product it describes are considered protected by copyright according to the applicable laws. OBSAI logo is a registered trademark of Open Base Station Architecture Initiative Special Interest Group. Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only. Copyright Open Base Station Architecture Initiative Special Interest Group. All rights reserved. Users are cautioned to check to determine that they have the latest edition of any OBSAI Specification. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of OBSAI, the OBSAI TWG will initiate action to prepare appropriate responses. Since OBSAI Specifications represent a consensus of OBSAI Member s interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason OBSAI and the members of its Technical Working Groups are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. Comments on specifications and requests for interpretations should be addressed to: 3 4 Peter Kenington Chairman, OBSAI Technical Working Group Linear Communications Consultants Ltd. pbk@linearcomms.com Issue.00 3 (38)

4 Contents Summary of changes...8 Current test case status Scope... 4 Message exchange success test cases Sending message without acknowledge 4.. Single fragment message without acknowledge 4.. Multiple fragment message without acknowledge 4 4. Sending message with acknowledge Multiple fragment message with acknowledge on each data packet Multiple fragment message where only the last fragment is acknowledged 7 5 UDPCP exception test cases Resending - Lost data Successful after resend Unsuccessful despite resends 5. Resending - Lost acknowledge 5.. Successful after resend 5.. Unsuccessful despite resends Checksum error Invalid header Reassembly of out of sequence fragments Data Packet with no payload Acknowledge packet with payload Duplicate fragment detection Duplicate message detection Message ID counter overflow 3 5. Synchronization after UDPCP reset 3 5. Interleaving Fragments from Two Sources Robustness against corrupted UDP Packets 34 6 Test setups...35 Issue.00 4 (38)

5 6. Test setup A 35 7 Abbreviations References...38 Issue.00 5 (38)

6 Figures Figure - Message transfer in unacknowledged mode (single fragment message)..3 Figure - Message transfer in unacknowledged mode (multiple fragment messages)...5 Figure 3 - Message transfer in multiple fragments; every packet shall be acknowledged...7 Figure 4 - Message transfer in multiple fragments; only the last fragment shall be acknowledged...9 Figure 5 - Acknowledge with payload...9 Figure 6 - UDPCP testing arrangement...36 Issue.00 6 (38)

7 List of Tables Table - Test case status...0 Table - Abbreviations...37 Issue.00 7 (38)

8 0 Summary of changes Version Approved by Date Comment.00 Management Board 5 th May 005 First Issue 3 Issue.00 8 (38)

9 3 Current test case status Table presents all UDPCP test cases and their current progress status (Changed, Waiting for comments, Work in process, Approved) 4 Test case Status Last change Single fragment message without acknowledge TC_RP_UDPCP_0 Multiple fragment message without acknowledge TC_RP_UDPCP_0 Fragment amount is zero TC_RP_UDPCP_03 Single fragment message with acknowledge on each data fragment TC_RP_UDPCP_04 Multiple fragment message with acknowledge on each data TC_RP_UDPCP_05 Multiple fragment message where only the last fragment is acknowledged TC_RP_UDPCP_06 Single fragment message with acknowledge only the last fragment TC_RP_UDPCP_07 Resending - Lost data, Successful after resend TC_RP_UDPCP_08 Resending - Lost data, Unsuccessful despite resends TC_RP_UDPCP_09 Resending - Lost acknowledge, Successful after resend TC_RP_UDPCP_0 Resending - Lost acknowledge, Unsuccessful despite resends TC_RP_UDPCP_ Approved Approved Deleted Deleted Approved Approved Deleted Approved Approved Approved Approved 3-May May Mar Apr May May Apr May May May May-005 Issue.00 9 (38)

10 Checksum error TC_RP_UDPCP_ Invalid header TC_RP_UDPCP_3 Invalid header, Length smaller than actual TC_RP_UDPCP_4 Invalid header, Fragment number larger than fragment amount TC_RP_UDPCP_5 Total length bigger than actual TC_RP_UDPCP_6 Total length smaller than actual TC_RP_UDPCP_7 Reassembly of out of sequence fragments TC_RP_UDPCP_8 Data Packet with no payload TC_RP_UDPCP_9 Acknowledge packet with payload TC_RP_UDPCP_0 Duplicate fragment detection TC_RP_UDPCP_ Duplicate message detection TC_RP_UDPCP_ Message ID counter overflow TC_RP_UDPCP_3 Duplicate message, Same message ID, IP address but different port (no duplication) TC_RP_UDPCP_4 Duplicate message, Same message ID, port but different address (no duplication) TC_RP_UDPCP_5 Synchronization after UDPCP reset TC_RP_UDPCP_6 Interleaving Fragments from Two Sources TC_RP_UDPCP_7 Robustness against corrupted UDP Packets TC_RP_UDPCP_8 Approved Approved Deleted Deleted Deleted Deleted Approved Approved Approved Approved Approved Approved Deleted Deleted Approved Approved Approved 3-May May Mar Mar Mar Mar May May May May May May Mar Mar May May May-005 Table - Test case status Issue.00 0 (38)

11 Scope This document describes conformance tests needed to perform for UDPCP implementation in order to guarantee its compliance with the UDPCP protocol specification according to OBSAI Reference Point Specification Version..07 [RP] Appendix A. Chapter 3 contains test cases for testing UDPCP message exchange under normal conditions. Test cases to test the UDPCP implementation in exceptional situations are described in chapter 4. The test setting (Test Setup A) to be used is defined in chapter Issue.00 (38)

12 Message exchange success test cases The purpose of the following test cases is to test that the normal operation of the UDPCP is implemented as specified. 0.0 Sending message without acknowledge Single fragment message without acknowledge Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_0 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: Verify that the UDPCP IUT can correctly receive and send application messages that fit into a single UDPCP data packet. Test both cases: Fragment Amount = 0 and Fragment Amount =. Unacknowledged transfer mode is used without a checksum. Command the tester to send a message smaller than the MTU to the IUT and receive the same message back from the IUT. Verify that sent and received messages are the same. Test with Fragment Amount = 0 and with Fragment Amount =. Tester UDPCP stack and UDPCP IUT are configured to unacknowledged transfer mode, i.e. the N-bit is. Checksum is not used. Procedure: 0. Tester application commands tester UDPCP stack to set Fragment Amount = in the next UDPCP data packet.. Tester application sends an application message smaller than the MTU to its UDPCP stack.. Tester UDPCP stack sends the application message to the UDPCP IUT in one UDPCP data packet. Fragment Amount shall be. 3. UDPCP IUT receives the UDPCP data packet and sends the application message to the echo functionality. 4. The echo functionality sends the same application message back to the UDPCP IUT. 5. UDPCP IUT sends the application message to the tester UDPCP stack in Issue.00 (38)

13 Test setup: Minimum acceptance criteria: one UDPCP data packet. 6. Tester UDPCP stack receives the UDPCP data packet and sends the application message to the tester application. 7. The tester application commands the tester UDPCP stack to set Fragment Amount = 0 in the next UDPCP data packet. 8. Repeat the steps from to 7. In step 3, Fragment Amount shall be 0. Test setup A In the both cases (Fragment Amount =0 and ): The application messages sent and received by the tester application are the same. Only one UDPCP data packet is sent inboth directions without an acknowledge. Parameters Value Limit Comments MTU Implementation Maximum Transmission Unit size specific 3 Figure - Message transfer in unacknowledged mode (single fragment message) 4 Issue.00 3 (38)

14 .0.0 Multiple fragment message without acknowledge Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_0 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: Verify that the UDPCP IUT can correctly receive and send application messages that don t fit into a single UDPCP data packet. Unacknowledged transfer mode is used with checksum. Command the tester to send a message longer than the MTU to the IUT and receive the same message back from the IUT. Verify that sent and received messages are the same. Tester UDPCP stack and UDPCP IUT are configured to unacknowledged transfer mode, i.e. the N-bit is. Checksum is used, i.e. C-bit is set to. Procedure: 0. Tester application sends an application message longer than the MTU to its UDPCP stack and requires it to use a checksum. Test setup: Test setup A Minimum acceptance criteria:. Tester UDPCP stack sends the application message to the UDPCP IUT in multiple fragments and includes a checksum.. UDPCP IUT receives all fragments and sends the application message to the echo functionality. 3. The echo functionality sends the same application message back to the UDPCP IUT. 4. UDPCP IUT sends the application message to the tester UDPCP stack in multiple fragments. 5. Tester UDPCP stack receives all fragments and sends the application message to the tester application. Application message sent and received by the tester application are the same. Multiple UDPCP data packets are sent in both directions without acknowledge but with checksum. Parameters Value Limit Comments MTU Implementation Maximum Transmission Unit size specific Issue.00 4 (38)

15 Figure - Message transfer in unacknowledged mode (multiple fragment messages).0 Sending message with acknowledge Multiple fragment message with acknowledge on each data packet Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_05 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: Verify that the UDPCP IUT can correctly receive and send application messages that don t fit into a single UDPCP data packet. Every packet shall be acknowledged. Command the tester to send a message longer than the MTU to the IUT and receive the same message back from the IUT. Verify that sent and received messages are the same. Tester UDPCP stack and UDPCP IUT are configured to acknowledge every packet, i.e. the N-bit is 0 and the S-bit is 0. Procedure: 0. Tester application sends an application message longer than the MTU to its UDPCP stack. Issue.00 5 (38)

16 Test setup: Test setup A Minimum acceptance criteria:. Tester UDPCP stack sends the application message to the UDPCP IUT in multiple fragments.. UDPCP IUT acknowledges every data packet with an acknowledge packet. 3. UDPCP IUT sends the application message to the echo functionality. 4. The echo functionality sends the same application message back to the UDPCP IUT. 5. UDPCP IUT sends the application message to the tester UDPCP stack in multiple fragments. 6. Tester UDPCP stack acknowledges every data packet with an acknowledge packet. 7. Tester UDPCP stack sends the application message to the tester application. Application messages sent and received by the tester application are the same. Multiple UDPCP data packets are sent in both directions with an acknowledge for every data packet received from its counterpart. UDPCP IUT accepts every acknowledge packet and does not resend the data after timeout period. Parameters Value Limit Comments MTU Implementation Maximum Transmission Unit size specific Timeout Implementation specific Timeout whilst waiting for an acknowledge before retransmission Issue.00 6 (38)

17 3 4 Figure 3 - Message transfer in multiple fragments; every packet shall be acknowledged Multiple fragment message where only the last fragment is acknowledged Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_06 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Verify that UDPCP IUT can correctly receive and send application messages that don t fit into a single UDPCP data packet. Only the last fragment that completes the message shall be acknowledged. Issue.00 7 (38)

18 Test Models: Method of Test: Test Conditions: Assumptions and Limitations: Command the tester to send a message longer than the MTU to the IUT and receive the same message back from the IUT. Verify that the sent and received messages are the same. Tester UDPCP stack and UDPCP IUT are configured to acknowledge only the last fragment, i.e. the N-bit is 0 and the S-bit is. Procedure: 0. Tester application sends an application message longer than the MTU to its UDPCP stack. Test setup: Test setup A Minimum acceptance criteria:. Tester UDPCP stack sends the application message to the UDPCP IUT in multiple fragments.. UDPCP IUT acknowledges only the last fragment that completes the message. 3. UDPCP IUT sends the application message to the echo functionality. 4. The echo functionality sends the same application message back to the UDPCP IUT. 5. UDPCP IUT sends the application message to the tester UDPCP stack in multiple fragments. 6. Tester UDPCP stack acknowledges only the last fragment that completes the message. 7. Tester UDPCP stack sends the application message to the tester application. Application messages sent and received by the tester application are the same. UDPCP IUT acknowledges only the last fragment that completes the message.. UDPCP IUT accepts the acknowledge packet and does not resend the data after timeout period. Parameters Value Limit Comments MTU Implementation Maximum Transmission Unit size specific Timeout Implementation specific Timeout whilst waiting for an acknowledge before retransmission Comment [KR]: The sentence replaced. Comment [PK]: Not sure if I ve corrected this in the right way, as the meaning of the original sentence was unclear. Deleted: Multiple UDPCP data packets are sent in both directions with an acknowledgement that only the last fragment that completes the message is received from in each case Deleted: counterpart Issue.00 8 (38)

19 3 4 Figure 4 - Message transfer in multiple fragments; only the last fragment shall be acknowledged 5 Issue.00 9 (38)

20 UDPCP exception test cases The purpose of the exception test cases is to test that the UDPCP implementation operates as specified in the exception situations. 0.0 Resending - Lost data The purpose of the following test cases is to simulate a situation when a data fragment is lost in transmission Successful after resend Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_08 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: It is checked that the message transfer is successful after a resend is performed. Simulate a situation where a single data fragment is lost in transmission and resending succeeds. Tester UDPCP stack is configured to acknowledge only the last fragment, i.e. the N- bit is 0 and the S-bit is. Procedure: 0. Tester application commands tester UDPCP stack to not send the last of many data fragments.. Tester application sends application message longer than MTU to tester UDPCP stack and UDPCP stack doesn t send the last data fragment.. UDPCP IUT receives all data fragments but not the last and starts waiting. 3. Tester UDPCP stack waits for an acknowledge and after timeout resends (actually sends for the first time) the last data fragment. 4. UDPCP IUT receives the data fragment and responses to the fragment with an acknowledge packet. 5. UDPCP IUT sends the received application message to the echo functionality. 6. The echo functionality sends the same application message back to the tester application Issue.00 0 (38)

21 Test setup: Test setup A Minimum acceptance criteria: Application messages sent and received by the tester application are the same. An acknowledgement is not sent before the last fragment has arrived. Parameters Value Limit Comments MTU Implementation Maximum Transmission Unit size specific Timeout Implementation specific Timeout whilst waiting for an acknowledge before retransmission.0.0 Unsuccessful despite resends Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_09 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: Message transfer fails despite resends. To verify that the IUT is able to continue with another message. Simulate a situation when a data fragment is lost in transmission and resending doesn t succeed. Tester UDPCP stack is configured to acknowledge only the last fragment, i.e. the N- bit is 0 and the S-bit is. Procedure: 0. Tester application commands tester UDPCP stack to not send last data fragment. Test setup:. Tester application sends an application message longer than the MTU to the tester UDPCP stack and the UDPCP stack doesn t send the last data fragment.. UDPCP IUT receives all data fragments but the last and starts waiting. 3. Tester UDPCP stack sends no more data fragments to simulate the case where the last data fragment is lost in transmission. 4. UDPCP IUT waits until final timeout. 5. After final timeout repeat TC_RP_UDPCP_06 Test setup A Issue.00 (38)

22 Minimum acceptance criteria: UDPCP IUT doesn t deliver the message to the echo functionality and doesn t send any acknowledgement for that last data fragment. TC_RP_UDPCP_06 shall pass. Parameters Value Limit Comments MTU Implementation Maximum Transmission Unit size specific Final timeout Timeout * maximum number of retransmissions Implementation specific timeout for waiting acknowledge before notifying of the failed transmission Resending - Lost acknowledge Purpose of the following test cases is to simulate a situation when an acknowledge packet is lost in transmission Successful after resend Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_0 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: To verify that the UDPCP IUT resends a message and that message transfer is successful after a resend is performed. Simulate a situation when an acknowledge packet is lost in transmission and resending succeeds. Tester UDPCP stack and UDPCP IUT are configured to acknowledge every packet, i.e. the N-bit is 0 and the S-bit is 0. Procedure: 0. Tester application commands tester UDPCP stack to ignore a single received data packet.. Tester application sends an application message smaller than the MTU to the tester UDPCP stack.. Tester UDPCP stack sends the data packet to the UDPCP IUT. 3. UDPCP IUT responds to the data packet with an acknowledge packet. 4. UDPCP IUT sends the received application message to the echo functionality. Issue.00 (38)

23 Test setup: Test setup A Minimum acceptance criteria: 5. The echo functionality sends the same application message back to the UDPCP IUT. 6. The UDPCP IUT sends the data packet to the tester UDPCP stack. 7. The tester UDPCP stack ignores a single received data packet and doesn t send an acknowledge to the UDPCP IUT. 8. UDPCP IUT resends the data packet after a timeout. 9. Tester UDPCP stack sends an acknowledge and the UDPCP IUT delivers an application message. 0. Verify that the UDPCP IUT does not resend the data packet after a second timeout period. Application message sent and received by tester application are the same. Parameters Value Limit Comments MTU Implementation Maximum Transmission Unit size specific Timeout Implementation specific Timeout whilst waiting for an acknowledge before retransmission.0.0 Unsuccessful despite resends Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_ RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: To verify that the UDPCP IUT performs re-sending for the maximum number of retransmissions, and after the final attempt, discards the message and notifies of the transmission failure. Simulate a situation when an acknowledge packet is lost in transmission and the resending doesn t succeed. Tester UDPCP stack and UDPCP IUT are configured to acknowledge every packet, i.e. the N-bit is 0 and the S-bit is 0. Procedure: 0. Tester application commands tester UDPCP stack to ignore all received data packets. Tester application sends application message smaller than MTU to tester UDPCP stack. Deleted: in Issue.00 3 (38)

24 Test setup: Test setup A Minimum acceptance criteria:. Tester UDPCP stack sends the data packet to the UDPCP IUT. 3. UDPCP IUT responds to the data packet with an acknowledge packet. 4. UDPCP IUT sends the received application message to the echo functionality. 5. The echo functionality sends the same application message back to the UDPCP IUT. 6. UDPCP IUT sends the data packet to the tester UDPCP stack. 7. Tester UDPCP stack ignores all data packets and doesn t send an acknowledge for them. 8. UDPCP IUT resends the data packet until the maximum number of retransmissions is reached. UDPCP IUT should report that message transmission has failed. Parameters Value Limit Comments Maximum number of retransmissions implementation specific MTU Number of retransmissions required before the transmission is deemed failed. Implementation specific Maximal Transfer Unit size..0 Checksum error Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_ RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: Verify that the UDPCP implementation detects checksum errors and discards a corrupted packet where the checksum detects an error. Verify that the UDPCP implementation is able to receive uncorrupted packets after timeout. Simulate a situation where a checksum error has occurred in transmission. Tester UDPCP stack is configured to acknowledge every packet, i.e. the N-bit is 0 and the S-bit is 0. Checksum shall be used, i.e. the C-bit is. Procedure: 0. Tester application commands tester UDPCP stack to generate one checksum error in a data packet, i.e. set a random checksum value.. Tester application sends an application message smaller than the MTU to the Issue.00 4 (38)

25 Test setup: Test setup A Minimum acceptance criteria: tester UDPCP stack containing a checksum use request.. The tester UDPCP stack sends to the UDPCP IUT a data packet with an incorrect Checksum value. 3. The UDPCP IUT discards the received corrupted data packet and doesn t send an acknowledge. 4. After timeout repeat TC_RP_UDPCP_05 using a checksum with the correct data packets. UDPCP IUT should not send an acknowledge for the corrupted data packet and should not send the application message to the echo functionality. TC_RP_UDPCP_05 with correct data packets shall pass. Parameters Value Limit Comments MTU Implementation specific Maximal Transfer Unit size. Timeout Implementation specific Timeout whilst waiting for an acknowledge before retransmission 3.0 Invalid header Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_3 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: Verify that the UDPCP IUT can detect invalid values in the header: The value of the Message Data Length is bigger or smaller than the Payload Data actual length of the message. The value of the Fragment Number is larger than the Fragment Amount value Simulate a situation when header corruption has occurred in transmission. Tester UDPCP stack is configured to acknowledge every packet, i.e. the N-bit is 0 and the S-bit is 0. Procedure: 0. The tester application commands the tester UDPCP stack to generate the following error which is placed into the data packet: Value of the Message Data Length in the header is bigger than the actual length of the Payload Data.. The tester application sends application message longer than the MTU to the Issue.00 5 (38)

26 Test setup: Test setup A Minimum acceptance criteria: tester UDPCP stack.. The tester UDPCP stack sends corrupted data packets to the UDPCP IUT. 3. The UDPCP IUT shall not pass the message to the upper layers, i.e. the message shall not be looped back by the IUT and shall not send acknowledge packets. 4. After timeout repeat TC_RP_UDPCP_05 to verify that the IUT is able to continue normal operation. 5. Repeat procedure from the step to 5 where in step the following errors should be generated: Value of the Message Data Length in the header is smaller than the actual length of the Payload Data. Value of the Fragment Number in the header is larger than Fragment Amount value IUT should not send acknowledge for corrupted data packets and the message should not be looped back to the echo functionality. TC_RP_UDPCP_05 shall pass. Parameters Value Limit Comments MTU Implementation specific Maximal Transfer Unit size. Timeout Implementation specific Timeout whilst waiting for an acknowledge before retransmission 4.0 Reassembly of out of sequence fragments Test Case ID: Test Case status: Optional Relevant to: TC_RP_UDPCP_8 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: To verify that UDPCP IUT is able to handle correctly the out of sequence received fragments. Simulate a situation when the UDPCP IUT receives fragments out of sequence in the transmission of a long message. Tester UDPCP stack is configured to acknowledge every packet, i.e. the N-bit is 0 and the S-bit is 0. Procedure: 0. Tester application commands tester UDPCP stack to generate application message fragments in reversed order.. Tester application sends application message longer than MTU to tester Issue.00 6 (38)

27 Test setup: Test setup A Minimum acceptance criteria: UDPCP stack.. Tester UDPCP stack sends data packets of the fragmented message in reversed order to UDPCP IUT. 3. UDPCP IUT acknowledges every data packet with an acknowledge packet. 4. UDPCP IUT sends the application message to the echo functionality. 5. The echo functionality sends the same application message back to the UDPCP IUT. 6. The UDPCP IUT sends the application message to the tester UDPCP stack in multiple data packets. 7. The tester UDPCP stack sends the application message to the tester application. UDPCP IUT should reorder fragments and assemble correct application message. Application message sent and received by tester application are the same. Parameters Value Limit Comments MTU Implementation specific Maximal Transfer Unit size. 5.0 Data Packet with no payload Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_9 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: Procedure: Test setup: To verify that UDPCP IUT is able to handle a data packet with no payload. Send data packets with no payload. Perform test case Single fragment message without acknowledge utilizing an empty application message. Test setup A Minimum acceptance criteria: Returned application message should be empty as well. Parameters Value Limit Comments Issue.00 7 (38)

28 6.0 Acknowledge packet with payload Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_0 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: Verify that UDPCP IUT discards acknowledge with payload. Send acknowledge packet with payload to UDPCP IUT. Tester UDPCP stack and UDPCP IUT are configured to acknowledge every packet, i.e. the N-bit is 0 and the S-bit is 0. Procedure: 0. Tester application commands tester UDPCP stack to send first acknowledge packet with payload. Test setup: Test setup A Minimum acceptance criteria:. Tester application sends an application message smaller than MTU to its UDPCP stack.. Tester UDPCP stack sends the application message to UDPCP IUT in one UDPCP data packet. 3. UDPCP IUT acknowledges the data packet with acknowledge packet. 4. UDPCP IUT sends the application message to echo functionality. 5. Echo functionality sends the same application message back to UDPCP IUT. 6. UDPCP IUT sends the application message to tester UDPCP stack in one data packet. 7. Tester UDPCP stack acknowledges the data packet. Acknowledge packet includes payload, i.e. Message Data Length > UDPCP IUT discards the acknowledge packet and after timeout resends the data packet. 9. Tester UDPCP stack acknowledges with a correct acknowledge packet and delivers the application message to the tester application. Application message sent and received by the tester application are the same. UDPCP IUT shall resend the data packet because IUT shall discard the acknowledge packet that has a payload. Parameters Value Limit Comments MTU Implementation Maximum Transmission Unit size specific Timeout Implementation specific Timeout whilst waiting for an acknowledge before retransmission Issue.00 8 (38)

29 3 Figure 5 - Acknowledge with payload 7.0 Duplicate fragment detection Test Case ID: Test Case status: Optional Relevant to: TC_RP_UDPCP_ RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: To verify that the UDPCP IUT can detect a duplicate fragment and can handle it correctly. Send one data fragment twice. Tester UDPCP stack is configured to acknowledge every packet, i.e. the N-bit is 0 and the S-bit is 0. Procedure: 0. Tester application commands tester UDPCP stack to generate one data fragment twice.. Tester application sends application message to tester UDPCP stack.. Tester UDPCP stack sends first data fragment twice to UDPCP IUT. 3. UDPCP IUT responses to the first data fragment with an acknowledge packet with D-bit set to UDPCP IUT responses to the second data fragment with an acknowledge packet with D-bit set to. 5. UDPCP IUT sends the received application message to the echo Issue.00 9 (38)

30 Test setup: Test setup A Minimum acceptance criteria: functionality. 6. The echo functionality sends the same application message back to the UDPCP IUT. 7. The UDPCP IUT sends the same application message back to the tester application. Two acknowledge packets received. The first with the D-bit set to 0 and the second with the D-bit set to. The application messages sent and received by the tester application are the same. Parameters Value Limit Comments 8.0 Duplicate message detection Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_ RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: To verify that UDPCP IUT can detect duplicate messages and that it will acknowledge (with D-bit set to ) and discard a duplicate message in acknowledged mode. Send the data message with the same message ID as it was in the previously sent data message. Tester UDPCP stack is configured to acknowledge every packet, i.e. the N-bit is 0 and the S-bit is 0. Procedure: 0. Tester application commands tester UDPCP stack to generate a data message with the same message ID as it was in the previously sent data message. Test setup: Test setup A Minimum acceptance criteria:. Tester application sends to the tester UDPCP stack an application message longer than the MTU.. UDPCP IUT discards all fragments of this message and sends acknowledge packets (with D-bit set to ) in response to every data packet. UDPCP IUT shall send acknowledge packets with the D-bit = Parameters Value Limit Comments MTU Implementation specific Maximal Transfer Unit size. Deleted: the Issue (38)

31 9.0 Message ID counter overflow Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_3 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Verify that the UDPCP IUT works properly when the message ID counter overflows during normal operation. Generate a situation where the UDPCP IUT message ID counter should overflow. Force the UDPCP IUT to send more than 6 messages and verify that the UDPCP IUT is still able to transport messages correctly. Assumptions and Limitations: Procedure: 0. The tester application sends a message by tester UDPCP stack to UDPCP IUT. Test setup: Test setup A Minimum acceptance criteria: The UDPCP IUT shall not crash.. UDPCP IUT receives the message and sends the message to the echo functionality.. The echo functionality sends the same message back to the UDPCP IUT. 3. The UDPCP IUT sends the message back to the tester UDPCP stack. The UDPCP IUT shall generate a unique Message ID. 4. The Tester UDPCP stack receives the message and sends it to the tester application. 5. Repeat steps to 5 at least 6 + times. All application messages sent and received by the tester application are the same. Parameters Value Limit Comments Synchronization after UDPCP reset Test Case ID: TC_RP_UDPCP_6 Test Case status: Mandatory Relevant to: RP Transport Layer UDPCP protocol Issue.00 3 (38)

32 Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: Verify that after a reset, the UDPCP IUT is able to synchronize with the receiver. Verify that the UDPCP IUT is able to detect that the transmitter is reset.. Reset UDPCP IUT and force IUT to transmit its first message with the synchronization procedure. Simulate a situation where the transmitter is reset and starts synchronization with UDPCP IUT. Tester UDPCP stack is configured to acknowledge every packet, i.e. the N-bit is 0 and the S-bit is 0. Procedure: 0. Reset UDPCP IUT. Test setup:. Tester application sends to the tester UDPCP stack an application message which is smaller than the MTU and the tester UDPCP stack passes the message to the UDPCP IUT. UDPCP IUT sends the received application message to echo functionality and echo functionality sends the same application message back to UDPCP IUT 3. Verify that UDPCP IUT sends to the tester UDPCP stack the Sync Msg as first data packet. The Sync Msg shall have: Message ID = 0 Type = Data Packet Message Data Length = 0 N-bit =0 and S-bit = Tester UDPCP stack sends acknowledge to UDPCP IUT with Message ID = Verify that UDPCP IUT sends to tester UDPCP stack the data packet with Message ID =. 6. Tester UDPCP stack sends the application message to tester application 7. To simulate transmitter reset tester application commands tester UDPCP stack to generate the Sync Msg (UDPCP data packet where Message ID = 0 and Message Data Length = 0). 8. Tester UDPCP stack sends the generated Sync Msg to UDPCP IUT in acknowledged mode (N-bit =0 and S-bit = 0). 9. Verify that UDPCP IUT sends acknowledge packet to tester UDPCP stack where Message ID = 0. Test setup A Deleted: to Deleted: UDPCP IUT Comment [KR3]: Sentence changed Comment [PK4]: Not sure I haven t changed the meaning here! Original sentence was unclear. Deleted:. Issue.00 3 (38)

33 Minimum acceptance criteria: UDPCP IUT shall send to the tester UDPCP stack the Sync Msg with Message ID =0 in the step 4 UDPCP IUT shall send to the tester UDPCP stack the data packet with Message ID = in the step 6 Application message sent in step and received in step 7 by the tester application are the same UDPCP IUT shall acknowledge the data packet with Message ID=0 in step 0. Parameters Value Limit Comments MTU Implementation specific Maximal Transfer Unit size..0 Interleaving Fragments from Two Sources Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_7 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: Assumptions and Limitations: To verify that the UDPCP IUT is able to simultaneously receive fragmented messages from two sources. Simulate a situation, where the IUT is receiving two messages simultaneously. Use two testers or one tester with two protocol stacks (stack A and stack B) so that the tester is able to simulate two UDPCP sources. Use two messages M and M with different content, both split into three fragments. Both testers stacks are configured so that the last fragment shall be acknowledged, i.e. the N-bit is 0 and the S-bit is. Procedure: 0. Reset all UDPCP message counters. (there should not be any other traffic including testers or UDPCP IUT) Test setup:. Send fragment of M from tester stack A.. Send fragment of M from tester stack B 3. Send fragment of M from tester stack A. 4. Send fragment of M from tester stack B 5. Send fragment 3 of M from tester stack A. 6. Send fragment 3 of M from tester stack B 7. Verify that the IUT acknowledge both messages correctly within timeout. 8. Verify that the UDPCP IUT echoes back both messages properly. Verify also that the data is not mixed up between messages. Test setup A. Use two testers or a dual stack tester stack, which is able to simulate the situation where the IUT is receiving messages simultaneously from two sources. Ether IP addresses or ports shall be different between stacks. Issue (38)

34 Minimum acceptance criteria: UDPCP IUT shall echo both messages back correctly. Parameters Value Limit Comments Timeout Implementation Timeout whilst waiting for an acknowledge specific before retransmission.0 Robustness against corrupted UDP Packets Test Case ID: Test Case status: Mandatory Relevant to: TC_RP_UDPCP_8 RP Transport Layer UDPCP protocol Source reference: [RP], Appendix A UDPCP Specification and Example of SOAP Binding Ch A.3, A.4 Test Purpose: Test Models: Method of Test: Test Conditions: To verify that UDPCP IUT is robust against incorrect packets received from underlying UDP API. Command the tester to send UDP packets with data, which does not conform to legal UDPCP data packets, to the port where the UDP IUT is listening for UDPCP packets. Verify that the IUT discards corrupted UDP packets and is able to send and receive UDPCP messages. Assumptions and Limitations: Procedure: 0. Execute test case TC_RP_UDPCP_0. Send an empty UDP packet to the IUT.. Send an UDP packet with random data, the packet size shall be smaller than the MTU of the IUT. 3. Send an UDP packet with random data, the packet size shall be maximum theoretical UDP packet size i.e. 64kb. 4. Repeat the TC_RP_UDPCP_0 Test setup: Test setup A. The tester application shall be able to bypass the UDPCP stack and send packets directly to the tester s UDP API. Alternatively, the tester application shall be able to command the UDPCP stack to generate an empty UDP packet and a UDP packet containing random data. Minimum acceptance criteria: The IUT shall not crash and TC_RP_UDPCP_0 shall pass both in step and in step 5. Parameters Value Limit Comments MTU Implementation specific Maximal Transfer Unit size. 3 Issue (38)

35 5 Test setups Test setup A This section describes a proposed test setup, which has been used in the test case descriptions in this document. Other test setups may be used as long as they are able to generate equivalent UDPCP communication over the Ethernet interface. In the test cases described in this document it is assumed that the module under test is in the UDPCP test category sub state test mode. UDPCP messages loop-back functionality for the module under test is activated successfully using the <updcpechoreq> command (see [TM], Ch UDPCP Echo Request and Response). Testing is performed with an external tester unit that is able to send/receive UDPCP messages. The tester consists of the tester application and the tester UDPCP stack functionality. The UDPCP implementation under test needs an echo functionality that will simulate the application level for UDPCP IUT. The echo is simulating the UDPCP peer application that the external tester application communicates via UDPCP. See Figure 6. An IP protocol analyzer is used to trace the message traffic between two UDPCP implementations. There is an interface between tester application and tester UDPCP stack that enables the tester to command the UDPCP stack to generate errors that are needed for exception test cases. The following errors can be generated: 0. To not send the last of many data fragments. Ignore once a received data packet.. Ignore all received data packets. 3. Generate the UDPCP data packet with defined values in the header fields Checksum, Version, Fragment Amount, Fragment Number, Message ID, Message Data Length. Comment [PK5]: This is very badly phrased and I m not sure what it is saying! Could you rephrase it? Deleted: Not send last data fragment from many. Issue (38)

36 Generate application message fragments in reverse order. 5. Generate one data fragment twice. 6. Generate the first data message with the same message ID as it was in the previously sent data message. 7. Send next acknowledge packet with payload 8. Generate an empty UDP packet and a UDP packet with random data. 8 Echo functions in the UDPCP message level Echoing each whole UDPCP message back to its sender, not in UDPCP fragment level. Tester application Application messages Tester UDPCP stack Commands to introduce errors IP anayzer Ethernet UDPCP messages UDPCP Echo functionality Application messages UDPCP IUT 9 0 Figure 6 - UDPCP testing arrangement 3 4 The echo functionality and tester application should both log the following information: Received application message. Sent application message. 5 Issue (38)

37 3 6 Abbreviations For the purposes of the present document, the following abbreviations apply: ABBREVIATION DESIGNATION BBM Base Band Module BTS Base Transceiver Station CCM Clock and Control Module CRC Cyclical Redundancy Check GND Ground IP Internet Protocol IUT Implementation Under Test LVDS Low Voltage Differential Signalling MTU Maximum Transmission Unit OBSAI Open Base Station Architecture Initiative RFM Radio Frequency Module RP Reference Point RP Reference Point RP3 Reference Point 3 SIG Special Interest Group SW Software TM Transport Module TWG Technical Working Group UDP User Datagram Protocol UDPCP UDP based Communication Protocol 4 Table - Abbreviations 5 Issue (38)

38 3 7 References [RP] OBSAI Reference Point Specification Version [TM] RP Test Messages Version 0. 5 Issue (38)