As far as I understand, 'Retry Test' is not a strict 3GPP terminology, but you may often hear about this test since some of network operator requires this test as an IOT level.

It also seems that many people is using 'Retry Test' interchangeably with 'Negative Test' or 'Reject Test'. Whatever it is called, they all means the same thing (at least similar things)

Whatever name the test carries, it checks one thing. The network makes a procedure fail on purpose, and the tester watches what the UE does next. Let's take it in three steps. First we look at what makes the UE retry and how long 3GPP says it must wait. Then we list what a test plan has to settle before the test runs. Finally we walk through four common scenarios, from an RRC Connection Reject to a missing Tracking Area Update Accept, and compare each one with the timers in 36.331, 36.321 and 24.301.

• What makes the UE retry, and how long does it wait ?
• What should a test plan settle before the test runs ?
• How does the UE behave in the four common retry scenarios ?
• Reference

What makes the UE retry, and how long does it wait ?

A retry test needs two things, a trigger and a waiting rule. The trigger is something the network does, or deliberately does not do. The waiting rule decides how soon the UE may try again. 3GPP defines that rule for some triggers and leaves it to the UE for others, so you should know which case you are testing.

As the term says, 'Retry Test' is the test in which Network put DUT in a condition where the DUT has to 'retry' 'something'.

Then what is the 'something' ? meaning 'In what situation UE has to retry something'. There can be many different cases for this. One of the most typical cases is when UE get some reject message to the message it sent to the network.

One example for this is 'RRC Connection Request' retry and overall sequence is as follows.

i) UE --> NW : 'RRC Connection Request'

ii) UE <-- NW : 'RRC Connection Reject'.

iii) < UE waits for a certain period of time. UE does not resend 'RRC Connection Request' during this period >

iv) UE --> NW : 'RRC Connection Request' (Retry)

It seems that network operators are more interested in step iii). They want to specify this timing as they like and make it sure that UE should not retry during the time frame. I think it is understandable since if UE retry something too often it would generate huge load on the network, but if UE does not retry it too long, it will give the bad user experience.

For this RRC example, the waiting period in step iii) is not left open. The RRCConnectionReject message carries a mandatory waitTime field with a value of 1 to 16 seconds. When the UE receives the message, it stops T300, resets MAC and starts T302 with the waitTime value. While T302 runs, the access barring check in 36.331 treats the cell as barred for mobile originating calls and signalling. A mobile terminating connection attempt fails too. When T302 expires, RRC tells the upper layers that the barring is alleviated. NAS can then start a new RRC Connection Request.

Two details matter in a test. First, T302 stops on cell reselection, so a UE that reselects to another cell may retry at once. A single cell setup avoids that. Second, the emergency call branch of the establishment procedure does not check T302. So an emergency call can still go out while T302 is running.

Later releases added three optional fields to the same message. The field extendedWaitTime-r10 carries 1 to 1800 seconds for delay tolerant access, and RRC forwards it to NAS instead of starting T302 with it. The field deprioritisationReq-r11 asks the UE to deprioritise the current frequency or all of E-UTRA for 5 to 30 minutes, and T325 runs for that period. The field rrc-SuspendIndication-r13 tells a UE that tried to resume a suspended connection to keep its stored context. A test that uses any of these fields checks a different wait than waitTime alone.

• A retry needs a trigger and a waiting rule : the trigger is a reject or a missing response, and the waiting rule decides how soon the UE may try again.
• The waitTime field sets the minimum wait after an RRC reject : the UE starts T302 with 1 to 16 seconds and treats the cell as barred until T302 expires.
• T302 stops on cell reselection : a UE that reselects can retry before waitTime ends, so a single cell setup gives a cleaner result.
• A wait longer than waitTime is still compliant : 36.331 gives a lower bound, not an exact retry time. NAS decides when to try again after the barring is alleviated.

What should a test plan settle before the test runs ?

The four questions below come up in almost every retry test. Some of them have a clear answer in the specifications, and some do not. Let's list the questions first, and then see where 3GPP answers them for the scenarios on this page.

For most of this kind of test, there a several common things to be clarified (if you are the person who has to develop a test case or write test plan/requirement, you have to have answers to these questions first).

i) What is the trigger for retry ? (Is it an explicit reject message ? or 'absense of response' (Ignoring Request)? or anything else ?)

ii) When a DUT has 'Reject' ? or get its request 'ignored', does it have to retry the request ? or simply give up the request right away ?

iii) If the DUT is expected to 'retry', does it simply has to send 'request' message again or does it goes even further backward and go through the whole process again ?

iv) If it gets rejector or ignored even with the retry, does it have to 'try again' or give up right away ? if it has to retry, how many times it has to retry ?

For some case, you will get those answers from 3GPP specification, but unfortunately there are many cases where they are not specified by the specification explictely. In that case, you have to ask about the requirement to whoever wants to perform the test or setup the test criterial on your own by observing the DUT behavior on real network or network simulator.

The table below puts the three layers side by side. Each column is one kind of failure, and each row answers one of the questions above with the rule from the specification. An entry of "Not defined" is a point where the test plan needs its own number.

Compare the three columns. The RRC reject case has a clear lower bound but no limit on the loop. The random access case has a short, random wait inside one T300 run. The NAS case has a complete retry rule with a counter and two timers. What 3GPP leaves open is mostly the outer loop: how many times an RRC connection attempt repeats, and when the UE stops trying one cell. Those are the points where the operator requirement has to give a number.

• Settle the trigger first : a reject message and a missing response start different timers, so they are different test cases.
• Separate the RRC wait from the NAS wait : T302 and the random access backoff belong to RRC and MAC, while T3411 and T3402 belong to NAS.
• An open point needs a written criterion : where 3GPP sets no retry limit, the pass criterion comes from the operator requirement or from an agreed reference UE behaviour.

How does the UE behave in the four common retry scenarios ?

The four diagrams in this section come from tests on a network simulator. Each one breaks the connection sequence at a different message, and each one asks how many times the loop should run. The notes inside the diagrams are observations from the UEs that were tested. The bullets under each diagram add what the specification says about the same step, so you can see where the UE follows a rule and where it follows its own design.

RRC Connection Reject with waitTime

In this scenario the network answers every RRC Connection Request with an RRC Connection Reject. The diagram shows PRACH, RACH Response, RRC Connection Request and RRC Connection Reject with WaitTime = x sec. A loop then returns to PRACH, and the clock marks the wait before the next attempt.

• The left note asks how many times the loop should run. Its answer is that the specification does not define it clearly, and the tested UEs kept looping with different retry intervals as long as they could detect the cell.
• The right note says the timer should be longer than WaitTime. In the tested UEs it was much longer than WaitTime, and the value varied widely.
• 36.331 agrees with the lower bound. The UE starts T302 with waitTime and treats the cell as barred until T302 expires or a cell reselection stops it.
• The time beyond waitTime is UE and NAS behaviour. RRC only reports the barring alleviation, and NAS then decides when to request a new connection.

No Contention Resolution

Here the network sends the RACH Response and receives the RRC Connection Request, but it never sends Contention Resolution. The red crosses mark the missing Contention Resolution and the missing RRC Connection Setup. The loop again returns to PRACH, so the random access procedure itself is repeated.

• The note at the lower right says the wait is short, because the RACH procedure was not complete. It also says the wait changes a lot with the Backoff Indicator value in the RACH Response.
• 36.321 explains both observations. When mac-ContentionResolutionTimer expires after 8 to 64 subframes, the MAC considers contention resolution not successful. It selects a random backoff time between 0 and the Backoff Parameter Value, and it sends a new preamble after that time.
• 36.321 Table 7.2-1 maps Backoff Indicator index 0 to 12 onto 0 to 960 ms, and the reserved indexes 13 to 15 are read as 960 ms. A larger index therefore gives a longer and more variable wait.
• Two limits bound the loop. MAC counts preambles up to preambleTransMax and then indicates a Random Access problem. RRC ends the whole attempt when T300 expires, 100 to 2000 ms after the establishment started, and reports the failure to NAS.

No RRC Connection Setup

In this scenario Contention Resolution succeeds, so the random access procedure completes. The network then withholds RRC Connection Setup, and the red cross marks it. The UE is now waiting at the RRC layer rather than at the MAC layer, and a different timer applies.

• The note says the retry interval fluctuated between a small value, such as 70 ms, and a very large value, such as a couple of minutes.
• With random access complete, the MAC backoff no longer applies. The UE waits for RRC Connection Setup until T300 expires. T300 comes from ue-TimersAndConstants in SIB2 and ranges from 100 ms to 2000 ms, with longer values for coverage enhancement.
• On T300 expiry the UE resets MAC and informs NAS that the RRC connection could not be established. NAS handles this as a lower layer failure. For a TAU or an attach, 24.301 then starts T3411, 10 s, and counts the attempt.
• No timer in the specification is as short as 70 ms for this case. A retry that fast is UE implementation behaviour, so it needs its own criterion in the test plan.
• If SIB2 carries txFailParams, a UE that supports them applies connEstFailOffset to the cell after connEstFailCount consecutive T300 expiries on it. The UE then prefers other cells for connEstFailOffsetValidity, which changes the retry pattern in a setup with more than one cell.

No Tracking Area Update Accept

The last scenario runs almost the whole sequence. The UE sends RRC Connection Setup Complete with the Tracking Area Update, and Authentication and Security complete. The network then never sends Tracking Area Update Accept, and the red cross marks it. This time the retry rule belongs to NAS, not to RRC.

• The left note says the case is not clearly defined in the specification. One behaviour was confirmed in the test: after several retries, the UE gave up and started the Attach procedure again.
• The note at the lower right says the interval alternated between several consecutive small values, such as 20 to 30 ms, and one large value, such as over 2 minutes.
• 24.301 clause 5.5.3.2.6 does define this case. The UE starts T3430 when it sends the TRACKING AREA UPDATE REQUEST. If T3430 expires, the UE aborts the procedure, releases the NAS signalling connection locally and increments the tracking area updating attempt counter.
• While the counter is below 5, the UE starts T3411 and sends the request again when T3411 expires. When the counter reaches 5, the UE starts T3402, sets the EPS update status to EU2 NOT UPDATED and deletes the list of equivalent PLMNs.
• In state EMM-REGISTERED.ATTEMPTING-TO-UPDATE, the UE starts tracking area updating again on T3411 or T3402 expiry. The specification does not describe an Attach after T3430 timeouts, so check the Attach seen in the test against the UE log.
• The intervals in the note do not match T3411 and T3402 directly. Before you use them as a pass criterion, check which two messages the interval was measured between.

• The failing message decides the timer : a reject starts T302, and a missing Contention Resolution starts the MAC backoff. A missing RRC Connection Setup ends in T300 expiry, and a missing TAU Accept ends in T3430 expiry.
• Only the NAS case has a retry count in the specification : the tracking area updating attempt counter allows 5 attempts before T3402.
• Observed intervals are not specification values : the notes in the diagrams record tested UEs, so compare them with the timers above before you write a pass criterion.

Reference

• 36.331 : 3GPP - E-UTRA Radio Resource Control (RRC); Protocol specification, v19.3.0. Clauses 5.3.3.6, 5.3.3.8, 5.3.3.11, the RRCConnectionReject message and the T302 timer table.
• 36.321 : 3GPP - E-UTRA Medium Access Control (MAC) protocol specification, v19.3.0. Clause 5.1.5 and Table 7.2-1.
• 24.301 : 3GPP - Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3, v20.0.0. Clause 5.5.3.2.6 and the EMM timer table.