For conformance test, we have two major procedure to go through. One is "ACTIVATE TEST MODE" and the other one is "CLOSE UE TEST LOOP". In RF Conformance, only "ACTIVATE TEST MODE" would be enough, but in Protocol Conformance we have to go through both "ACTIVATE TEST MODE" and "CLOSE UE TEST LOOP". (For the details refer to TS 36.509 '5 Test Control (TC) protocol procedures and test loop operation').

A test system needs a UE that sends back whatever the test system sends it. Only then can the test system measure throughput, block errors or protocol behaviour without an application on the UE. 36.509 defines that function as the UE test loop, and it controls the loop with its own Test Control messages.

• Which UE test loop modes are there ?
• Where does each loop sit in the UE protocol stack ?
• How does the SS put the UE into test mode and close the loop ?
• How is the CLOSE UE TEST LOOP message coded ?
• Reference

Which UE test loop modes are there ?

Let's start with the question of what the UE returns and where it returns it. Each loop mode answers that question differently, and each mode is mandatory only for a UE that supports the feature under test. The table below covers the three original modes, A, B and C.

Later releases added six more modes, and the current 36.509 v17.4.0 defines modes A to I. Modes D, E and F serve sidelink and SC-PTM testing. Modes G, H and I serve the Control Plane CIoT EPS optimization, where user data travels in NAS messages instead of on a DRB. The table below lists the later modes with the UE capability that makes each one mandatory.

• Mode A loops back every PDCP SDU on its own DRB : the UE ignores the contents and the TFT.
• Mode B loops back IP packets through the uplink TFT : so it tests the TFT handling and survives an inter-system change.
• Modes C to F never return downlink data : C and F count received packets, D and E count or transmit sidelink packets, and the SS reads the counters with separate request messages.
• Modes G, H and I serve Control Plane CIoT EPS optimization : the loop works on NAS and SMS containers instead of DRBs.

Where does each loop sit in the UE protocol stack ?

The mode names do not tell you where the returned data enters the uplink. That point decides which layers the test exercises. So let's put the three original modes next to each other in the UE protocol stack.

Overal function diagram for each test mode from TS 36.509 is as follows.

The diagram below shows three block diagrams side by side. Each one runs from the Test System at the bottom, through L1:PHY, L2:MAC, L2:RLC and L2:PDCP, up to L3:RRC, NAS and L3:Test Control. The UE test loop function is the box at the top right of each stack.

• Loopmode A : one RB LB Entity per DRB, from RB LB Entity#1 to RB LB Entity#n. Each entity sits on top of its own PDCP entity with ROHC and Ciphering, so the data goes back on the DRB it came from.
• Loopmode B : a single LB Entity sits above a Mapping SDF to EPS bearer block, marked UL TFT handling. The IP PDUs equal the PDCP SDUs, and the UL TFT picks the DRB for each one.
• Loopmode C : an MBMS Packet Counter sits on an RLC UM entity that receives the MTCH. There is no uplink path from the counter, because mode C only counts.
• In all three stacks, L3:Test Control is a separate entity next to NAS : EMM/ESM. Its messages travel over the SRBs like other NAS messages.

Look at the Mode B stack once more. The loop sits above the TFT handling, so a packet only comes back on the right bearer when the uplink TFT is correct. So mode B is the mode that can verify uplink TFT handling, which 36.509 clause 5.4.1 names as one purpose of the loop. The same clause also lists RF receiver and transmitter testing among the uses of the loop. So an RF test that needs uplink user data also closes the loop.

• Mode A tests the radio bearer path : the data returns below the TFT, on the same DRB.
• Mode B tests the EPS bearer path : the data returns through the uplink TFT, so a wrong TFT sends it to the wrong bearer.
• Test Control is a NAS level entity : its messages travel over the SRBs like EMM and ESM messages.

How does the SS put the UE into test mode and close the loop ?

A UE does not loop data back by default. The SS first has to put it into test mode, and only then can it close the loop on the bearers it has set up. Both steps use Test Control messages, so let's list them before we follow the sequence.

All Test Control messages use protocol discriminator 1111 of 24.007, which is reserved for test procedures. The message type in the second octet then names the message. The table below lists the messages of the activation and loop procedures from 36.509 clause 6.

The sequence has four steps. First, the SS sends ACTIVATE TEST MODE while the UE is in connected state, and the UE answers with ACTIVATE TEST MODE COMPLETE. The SS has to do this before the default EPS bearer context is active, otherwise the UE behaviour is unspecified for modes other than G and H. Second, the SS sets up the bearers that the chosen mode needs. Third, the SS sends CLOSE UE TEST LOOP, and the UE answers with CLOSE UE TEST LOOP COMPLETE. The loop now runs. Fourth, the SS sends OPEN UE TEST LOOP and later DEACTIVATE TEST MODE to return the UE to normal operation.

Test mode also changes how the UE behaves between the first and the third step. The UE accepts any request to set up a DRB with its EPS bearer context, as long as it is within the UE capabilities. It also sends no uplink PDCP SDU of its own on the PDN connections, apart from the traffic it needs to obtain an IP address. So the SS sees only the data that it asked for. The four control messages ACTIVATE TEST MODE, DEACTIVATE TEST MODE, CLOSE UE TEST LOOP and OPEN UE TEST LOOP are integrity protected and ciphered like normal NAS messages.

• Activate first, close second : ACTIVATE TEST MODE prepares the UE, and CLOSE UE TEST LOOP starts the loop on existing bearers.
• Send ACTIVATE TEST MODE early : the default EPS bearer context must not be active yet.
• A UE in test mode stays quiet : it sends no uplink user data of its own, so every uplink packet is loop data.
• Test Control messages are protected NAS messages : they need NAS security like any EMM or ESM message.

How is the CLOSE UE TEST LOOP message coded ?

CLOSE UE TEST LOOP carries the mode and the setup for that mode. For mode A the setup can also change the size of the returned PDCP SDU. This lets the SS drive a large uplink with a small downlink.

Message structure of CLOSE UE TEST LOOP is as follows.  (For the details refer to TS 36.509 '5 Test Control (TC) protocol procedures and test loop operation').

The two screenshots below come from an earlier version of 36.509 clause 6.1. The upper one shows the message content table and the codings of the message type, the UE test loop mode and the mode A LB setup list. The lower one continues with the coding of one LB setup DRB IE.

• Protocol discriminator and Skip indicator are half an octet each, and together they form the first octet of the message.
• Message type is 1 0 0 0 0 0 0 0, which is 0x80 for CLOSE UE TEST LOOP.
• UE test loop mode uses X2 and X1 in the screenshot, so it covers only modes A, B and C. The current version uses X4 to X1 for modes A to I.
• UE test loop mode A LB setup is an LV element. Its length octet is followed by N LB setup DRB IEs of 3 octets each, so the element runs from octet 1 to octet N*3+1.
• The screenshot gives mode C setup a length of 1. The current version codes it as 3 octets, which carry the MTCH ID.
• Each LB setup DRB IE has 16 bits Z15 to Z0 for the uplink PDCP SDU size in bits, from 0 to 12160, and 5 bits Q4 to Q0 for the DRB. The DRB field carries DRB-Identity - 1, as the text under the lower screenshot says.

Let me give you an example for the message to help you understand the message structure.

HEX String : 0F 80 00 03 01 00 01

Analysis Result :

• 0  : Skip indicator
• F  : Protocol discriminator
• 80 : Message type (10000000)
• 00 : UE test loop mode (000000AB), where A=B=0 when Loopback mode is mode A
• 03 : Length of UE test loop mode A LB setup list in bytes
• 01 00 : Uplink PDCP SDU Size = 256 bits
• 01 : Data Radio Bearer ID = 2, because this field carries DRB-Identity - 1

Let's read the two less obvious octets. The first octet is 0F, because 24.007 puts the protocol discriminator in bits 4 to 1 and the skip indicator in bits 8 to 5. The last octet is 01, so Q4 to Q0 is 1 and the loop applies to DRB-Identity 2. To loop DRB-Identity 1 instead, the SS would send 00.

The size field changes the uplink. With 01 00, the UE returns each PDCP SDU on this DRB as 256 bits, which is 32 octets, whatever size the downlink SDU had. The size must be a multiple of 8 bits. If the message has no LB setup DRB IE for a DRB, the UE returns each SDU at its received size. The length octet 03 shows one IE here, and one message can carry up to 8 of them within its 25 octets.

• The first octet is 0F for every Test Control message : skip indicator 0 in the upper half and protocol discriminator F in the lower half.
• The DRB field is DRB-Identity - 1 : a value of 01 in the example means DRB-Identity 2.
• The UL PDCP SDU size scales the uplink : the UE returns the SDU at this size, up to 12160 bits.
• Without an LB setup DRB IE the loop keeps the size : the UE returns each SDU exactly as large as it arrived.

Reference

• 3GPP TS 36.509 v17.4.0 : Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC); Special conformance testing functions for User Equipment (UE). Clause 5 Test Control protocol procedures and test loop operation, and clause 6 Test Control messages.
• 3GPP TS 24.007 v20.0.0 : Mobile radio interface signalling layer 3; General aspects. Clause 11.2.3.1.1 Protocol discriminator and clause 11.2.3.1.2 Skip indicator.