6.5 RLC test method and architecture
34.123-33GPPPart 3: Abstract test suite (ATS)TSUser Equipment (UE) conformance specification
6.5.1 Testing architecture
Figure 6.5.1 illustrates a typical realization of the RLC ATS.
Figure 6.5.1: RLC ATS single party test method
The single party test method is used for RLC testing.
Separation of TTCN test cases from the configuration of the tester and initialization of the UE is achieved by using test steps. For each RLC test case, common test steps will be used to perform the configuration of the tester and the appropriate generic setup procedures as described in 3GPP TS 34.108 [3]. These test steps will make use of PCOs AM, UM, TM, CRLC, CMAC, and CPHY.
Three PCOs are provided at the top of the RLC emulation in the tester, one corresponding to each of the available RLC modes: acknowledged, unacknowledged, and transparent. Routing information for different radio bearers used at these PCOs will be provided in ASP parameters.
The queues shown in the RLC emulation in Figure 6.5.1 indicate that normal RLC transmit and receive buffering will be used to isolate the TTCN test suite from the real time issues involved if messages are sent directly to the MAC layer.
The RLC TTCN test cases make also use of the NAS TTCN test steps in order to bring UE to Idle state. The NAS test steps, which are called by the RLC test cases or steps, interface with the Dc PCO.
6.5.2 Test method
Figure 6.5.2.1 illustrates an example configuration for downlink UM testing. Uplink and AM tests will use similar configurations. A Tr-Entity is established on the tester side using a CRLC-CONFIG-REQ. A corresponding UM‑Entity is created in the UE by sending a Radio Bearer Setup PDU. RLC PDUs are specified in the TTCN test suite, and sent to TM PCO. These PDUs shall be carefully designed so that the Tr-Entity will not perform any segmentation. The system simulator is responsible for direct encoding the abstract representation of transmitted PDUs into a bitstring to be sent by the Transmitting Tr entity. Direct encoding is performed by concatenation of all of the present fields in the abstract representation. It is the TTCN author’s responsibility to ensure that the PDU is valid. To test reassembly in the UE side, the segmentation must be explicitly coded in TTCN. To test various aspects of the RLC header (e.g. sequence numbering, length indications, etc.), the RLC header must be explicitly coded in TTCN. Ciphering will not be tested using this approach, and will be disabled in the UE UM Entity.
The segmentation block in the SS Tr-entity is shown in grey to indicate that the functionality is present in the SS, but the test cases shall be carefully designed to ensure that segmentation is not used in the SS Tr-entity for RLC testing.
The deciphering block in the UE UM-entity is shown in grey to indicate that the functionality may be present in the UE, but shall be disabled for RLC testing.
Figure 6.5.2.1: Example configuration for downlink RLC UM testing
The TFCS used for RLC testing must guarantee that Tr mode segmentation will not occur. This is to prevent transmission of more than one Tr PDU per TTI.
All RLC tests that require uplink data will make use of the UE test loop mode 1 defined in 3GPP TS 34.109 [4]. The UE test loop mode 1 function provides all Upper Tester (UT) functionality required, so an UT PCO is not required for RLC tests. Test Loop mode 1 is only available in the user plane, so all RLC tests will be performed in the user plane, using DTCH and DCCH logical channels mapped to DCH transport channels.
Ciphering will be disabled for all RLC test cases. Ciphering will be tested implicitly by other test cases that have ciphering enabled.
Figure 6.5.2.2 illustrates an example configuration for uplink UM testing, and reception of an example UMD PDU. Figure 6.5.2.3 illustrates an example configuration for uplink AM testing, reception of an example STATUS_PDU, and the use of the superFields and superFieldsRec fields.
The ciphering and deciphering blocks in the UE RLC entities are shown in grey to indicate that the functionality may be present in the UE, but shall be disabled for RLC testing.
The reassembly blocks in the SS Tr-entities are shown in grey to indicate that the functionality is present in the SS, but the test cases shall be carefully designed to ensure that reassembly is not used in the SS Tr-entity for RLC testing.
Figure 6.5.2.2: Example configuration for uplink RLC UM testing
Figure 6.5.2.3: Example configuration for uplink RLC AM testing
Uplink data uses a similar approach to downlink, but the received data must be decoded in the correct way, depending on the current UE configuration. In the example in Figure 6.5.2.2, the SS must decode the data received at the TM PCO into an abstract representation of the structure defined in the TTCN for a UMD_PDU, using 7 bit length indicators. This structure is then compared with an abstract representation of the expected data to see if the receive event is successful. Refer to TR 101 666 [27], clause B.5.2.10 for more information.
For RLC testing, the following RB Ids are used within the system simulator, depending on the RLC mode, and length indicator size being simulated.
|
RLC mode |
LI Size |
RB Id |
|
UM |
7 |
-10 |
|
UM |
15 |
-11 |
|
AM |
7 |
-12 |
|
AM |
15 |
-13 |
|
UM/AM (Rel-7 or later ) |
7/15 |
-25 |
The SS decoder can use the RB Id to determine which abstract structure to create during the decode process. The SS decoder must also understand the RLC peer-to-peer protocol enough to determine which fields are present.
EXAMPLE 1: The semantics of LI extension bits must be known to determine how many LIs are present.
EXAMPLE 2: The contents of the LIs must be interpreted to determine how many octets of data, and how many octets of padding are present.
The SUFI list and any subsequent padding in a received STATUS_PDU or PiggyBackedSTATUS_PDU shall be decoded as a HEXSTRING, and put in the ‘superFieldsRec’ field of the abstract representation of the STATUS PDU. The "superFields" and "padding" fields shall be omitted for received STATUS PDUs. This is illustrated in Figure 6.5.2.3.
As in downlink testing, the TFCS must be defined to guarantee that the Tr entity does not perform any reassembly. This is to prevent reception of more than one Tr PDU per TTI so that the TTCN does not need to manage possible interleaving problems due to multiple PDUs received at the same time (i.e. they may be placed on the PCO queue in any order).
6.5.2.1 Handling SUFIs in TTCN
The SUFIs are a very flexible set of information elements contained in the RLC protocol. The order of the fields varies, the existence of a field may depend upon the presence of another one. A field can be present multiple times. For matching received SUFIs, it is convenient to define the SUFIs as a HEXSTRING which is treated by a TSO o_SUFI_Handler.
Depending upon which SUFIs and which aspects of SUFIs are to be checked, the TSO is provided with the information (SUFI_Params) on what checking it is expected to perform. If the check is successful the result TRUE will be returned, otherwise FALSE. Additionally the TSO will return an object which is structured as the SUFIs used in transmission (SuperFields). This will allow to make use of information received and needed to establish SUFIs to be transmitted.
The input parameters to o_SUFI_Handler to be used as checking criteria are collected in tabular data structure SUFI_Params which is filled each time before the TSO is called. These data are to allow the checking of the presence and the value of SUFIs. All entries shall be set to well-defined values if these are to be used by o_SUFI_Handler. As a principle values specifically set are used as criteria for checking, values omitted are used as AnyOrOmit values. The resulting SUFI list is established by o_SUFI_Handler and can be retrieved in the data structure returned by the TSO. Details have to be defined in the TSO itself.
Tasks o_SUFI_Handler has to perform:
– Transfer the SUFIs received into the structure of SuperFields; this is the SUFI list structure existing today.
– If multiple occurrences of SUFI are found then use the last one to fill the SuperFields structure. The LIST SUFI is an exception: multiple SUFIs may be used to transfer the complete LIST information.
– Check for all parameters in SUFI_Params set to a specific expected value that one of the SUFIs using this value is present and that the value received matches the specific expected value.
– Check that if SUFIs are received for which an expected value of Any is specified, the SUFI is consistent if that SUFI is received.
– Check that if SUFIs are received for the presence of which no entry is specified in SUFI_Params, the SUFI is consistent.
– Check that sequence numbers are in the range between LB and UB if specific values are set.
Entries in SUFI_Params.
|
Element Name |
Significance |
Comment |
|
LB |
Lower bound of sequence number range |
Lowest SN for checking SNs acknowledged |
|
UB |
Upper bound of sequence number range |
Highest SN for checking SNs acknowledged |
|
WSN_presence |
Window Size SUFI present |
To check the presence of the Window Size SUFI |
|
MRW_presence |
Move Receive Window SUFI present |
To check the presence of the MRW SUFI |
|
Nack1 |
SN of 1st PDU negatively acknowledged |
For the NackList to check SN to be negatively acknowledged |
|
Nack2 |
SN of 2nd PDU negatively acknowledged |
For the NackList to check SN to be negatively acknowledged |
|
Nack3 |
SN of 3rd PDU negatively acknowledged |
For the NackList to check SN to be negatively acknowledged |
More entries may be required in the future if specific SUFI field values are to be checked. The concept allows to add more fields easily.