6.9 PDCP test

34.123-33GPPPart 3: Abstract test suite (ATS)TSUser Equipment (UE) conformance specification

Figure 6.9: PDCP testing architecture 1: single party test method, with test loop mode 1

6.9.1 PDCP test architecture

The single party test method is used for PDCP testing. All PDCP tests that require uplink data will make use of the UE test loop mode 1 defined in 3GPP TS 34.109 [4]. Test Loop mode 1 is only available in the user plane, so all PDCP tests will be performed in the user plane, using the same logical channels mapped to transport channels as defined in RLC test cases, except for test case, clause 7.3.2.2.4, where a configuration of combined radio bearers used only for this test case is defined.

Separation of TTCN test cases from the configuration of the tester and initialization of the UE is achieved by using test steps. For PDCP test cases, common test steps and newly defined test steps for PDCP configuration will be used to perform the configuration of the tester and the appropriate generic setup procedures as described in 3GPP TS 34.108 [3] and in clause 7.3 of 3GPP TS 34.123-1 [1]. These test steps will make use of PCOs RLC AM, RLC UM, CRLC, CMAC, and CPHY.

The PDCP TTCN test cases make also use of the NAS TTCN test steps in order to setup a PS session.

For PDCP testing, the IP Header Compression protocol as described in RFC 2507 [30] is used as optimization method. The IP header compression and decompression mechanisms as described in RFC 2507 [30] is not part of PDCP TTCN. PDCP testing make use of uncompressed, compressed and decompressed TCP/IP header packets of a certain packet stream and uncompressed, compressed and decompressed UDP/IP header packets of a certain generation. This parameters are given as test parameter (PIXIT information).

PDCP testing includes transmission/reception of compressed/decompressed IP header packets, PDCP sequence numbering while lossless SRNS relocation and PID assignment rules as well as PDCP configuration tests as described in 3GPP TS 25.323 [19]. It does not test optimization specific protocol behaviour as error recovery and packet reordering as described in RFC 2507 [30].

6.9.2 PDCP test method

For PDCP testing, the RB test mode is used with test loop mode 1. After establishing a PS session with RB in RLC UM or/and AM, the UE is configured to support a negotiated PDCP configuration. UDP/IP header packets are used as Non-TCP/IP header packets as PDCP test data.

There are different input parameter as PIXIT values necessary for PDCP testing.

For TCP/IP header packets, uncompressed TCP/IP header packets shall be defined as PIXIT input parameter. In addition, there are the corresponding RFC 2507 [30] FULL_HEADER packet, COMPRESSED_TCP packet and COMPRESSED_TCP_NONDELTA packet given for each TCP/IP header packet as PIXIT information.

For UDP/IP header packets, uncompressed UDP/IP header packets shall be defined as PIXIT input parameter. In addition, there are the corresponding RFC 2507 [30] FULL_HEADER packet and COMPRESSED_NON_TCP packet given for each UDP/IP header packet as PIXIT information.

To check the use of certain PID values assigned to IP compressed header types, a given IP header packet (PIXIT) will be sent to the UE. The UE shall return a appropriate valid IP header packet type, which corresponds to the previous sent IP header packet. The usage of valid compressed/uncompressed IP header packets shall be checked by comparing the given PIXIT IP header packet types for each IP header packet previously sent.

The IP header packet order as described in RFC 2507 [30] shall be applied within a test case.

If for example an TCP/IP header packet of type "COMPRESSED_TCP" shall be sent, the TTCN uses the given TCP/IP header packet (PIXIT) for transmission to the UE. The UE shall decompress the received packets appropriate, afterwards it will be returned by the loop back entity and it shall be sent by applying IP header compression rules as described in RFC 2507 [30] and as configured. Then, the SS receives returned IP header packets and compares it with all valid IP header packets given as PIXIT parameter corresponding to the previously sent IP header packet. It is checked, whether or not the IP header packet with assigned PID is valid and a configured PDCP PDU where used for transmission. In this way, it is checked, that the UE performs IP header compression as configured and is able to assign the correct PID values.

6.9.2.1 CS voice over HSPA

For PDCP CS voice over HSPA tests, the RB test mode used is test loop mode 1 with loopback of PDCP SDUs (as per 3GPP TS 34.109 [4], clause 5.3.2.6.1). The CS domain voice RAB is associated with one RB and one PDCP entity. The two RLC entities (DL/UL) are configured in UM with SN_delivery mode. The PDCP entity serving CS service does not use header compression, therefore no ROHC is configured.

6.9.2.2 Network initiated secondary PDP context

Figure 6.9.2.2: Network initiated secondary PDP testing architecture

For the network initiated secondary PDP context tests using data loopback, the UE test loop mode 4 is applied with loopback of IP PDUs (as per 3GPP TS 34.109 [4], clause 5.3.2.8.1). No header compression is tested, therefore no ROHC is configured.