Even though you have the whole knowledge of this technology, it is impossible to implement a protocol stack or test cases which does not need any troubleshooting. In reality, most of the engineers has relatively good knolwedge on a specific area or specific layer but much less knowledge on other layers. However when a problem happens, we usually have to analyze across multiple layers meaning that we need knowledge on several layers and detailed interrelations between those layers.

In a word, there is no way to troubleshoot in a single shot and no short cut for it. A third of them came from the knowledge and a third of them came from experience and the other third came from the combination of these two.

In this section, I would try putting down some troubleshooting tips mostly based on my experience. Following is the list of the tips and this list would get longer as time goes on.

I have seen different types of trouble dominates depending on the maturity level of UE implementation or maturity of LTE technology itself.

Here goes brief summary of common troubles happening in each period. (Of course, this is completely my personal/ subjective classification -:))

< ~ early 2012 >

This is early phase of UE implementation and LTE technology itself, so you would have frequently seen the problems 3) ~ 17), 21)

< Early 2012 ~ Mid 2013 >

You might have seen a lot of test has been done about CSCF and have troubleshoot issues about this accordingly.

< Early 2013 ~ >  

I see a lot of testing has been going on with IMS/SIP related issue and you would have seen those issues described at 24)

< Late 2013 ~ >

I start seeing UEs supporting higher category and carrier aggregation and seeing troubleshoot case mainly for achieving maximum throughput.

< 2014 ~ >

I think most of the basic functionality (Single Cell, Throughput focused) for LTE UE became mature at least for a leading chipset manufacturer. This year, I see more sophisticated/practical test cases as follows.

• CSI based measurement/Report
• MBSFN
• eICIC
• LTE-LTE multi cell test
• LTE-None LTE InterRAT test
• More Active TDD LTE
• WiFi OffLoading
• IMS with IPSec

< 2015 ~ >

I don't see much of new feature test this year... indicating that industry is getting mature and the device is getting mature/stable as well.  Some of the items that attracted much attention from me are

• Carrier Aggregation (2CC, 3CC)
• RCS (early stage of testing)
• GBA (very early stage of testing)

< 2016 ~ >

• DL 256 QAM, UL 64 QAM
• Carrier Aggregation (4CC)
• Carrier Aggregation with 4x4 MIMO and 1Gb Throughput
• UL Carrier Aggregation
• RCS with Auto Configuration
• LTE-U

< 2017 ~ >

• LTE-M1(BL/CE)
• LTE-M2(NB-LTE)

Tools for troubleshoot

The more tools you have, generally the easier to troubleshoot. I hope I can get at least the followings tools as minimum (in many case even this minimum are not meet giving me more headache though)

i) Logging tools on network emulator (It should have not only signaling log (L3 and above) but also all the lower layer log as well)

ii) Logging tools on UE (In this case as well we need not only signaling log but also all the lower layer log)

iii) RF Vector Sepctrum Analyzer (This should have good qulaity of zero-span with triggering capability. It would help a lot at RACH process or handover process troubleshooting).

Among this tools, I want to put a special emphasis on logging tools. Of course the best logging tool would the one which can show the process for all the layers. It should show not only for scheduling information but also for the payload for each layer. Especially it is very important to the logging tools that can show PDSCH and PUSCH payload and SFN:Subframe. But in reality many of the logging tools suppress PDSCH/PUSCH data since collecting all of these can be too much load for processor. However, PDSCH/PUSCH is more important than any other layers mainly for the following reason.

i) PUSCH/PDSCH payload can show the data and header for all other layers like MAC, RLC, PDCP headers.

ii) PUSCH/PDSCH transmission timing (SFN:Subframe) is idential on both UE and Network. You can easily synchronize UE log and Network log.

The most important initial 5 steps

Every later test step assumes that the UE already has an RRC connection. So when anything fails early, I check these five steps first. They are the random access procedure plus RRC connection setup, and each step runs against a timer.

The most important 5 steps for registration are as follows :

We have to know every details of these process and all the factors influencing this process.

i) RACH Preamble

ii) RACH Response (Msg 2)

iii) RRC Connection Request (Msg 3)

iv) RRC Connection Setup

v) RRC Connection Setup Complete

First thing we have to consider is timing requirement between each step and the following step. Time Interval between i) and ii) is 3~12 sub frames. The requirement between ii) and iii) is 6 sub frames. The network should complete the lower layer configuration for Msg3 reception at least 4 sub frames before the msg3 comes into the network.

Let's look at the values of those timers, because the logs only make sense against them. The UE looks for the RACH Response inside the RA Response window. This window starts three subframes after the subframe where the preamble ends. Its length is ra-ResponseWindowSize in SIB2, from sf2 to sf10. That is where the 3~12 subframe range comes from (36.321 5.1.4).

The RACH Response also carries the UL grant for Msg3. For a grant received in subframe n, the UE sends Msg3 in the first available UL subframe from n+6 onward (36.213 6.1.1). If the UL delay field in the grant is 1, the UE postpones Msg3 to the next available UL subframe. In TDD, the UL/DL configuration decides which subframes are available.

Once Msg3 is sent, the MAC starts mac-ContentionResolutionTimer, which SIB2 sets between sf8 and sf64. RRC also runs T300 from the start of the connection establishment, with a value between ms100 and ms2000. If Msg4 does not resolve contention in time, the UE goes back to the preamble. If T300 expires, the RRC connection establishment fails.

• The RACH Response has a deadline : a RAR sent after the window closes is lost, even when its content is correct.
• Msg3 timing follows the RAR subframe : compare the SFN:Subframe of the RAR and of Msg3 in both logs before you look at the payload.
• Two timers end the setup attempt : mac-ContentionResolutionTimer sends the UE back to the preamble, and T300 ends the RRC attempt.

UE does not even try to search any cell

This is the earliest failure you can have. The UE never transmits anything, so the network side log stays empty. The cause is almost always inside the UE: its USIM, its settings, or the bands it supports.

If the UE is equipped with full protocol stack

i) Check if the UE has proper USIM in it. (Sometimes UE requires a special USIM even for testing. In many case, System Operators ask UE vendor to 'lock' the SIM only for the System Operator's SIB. In this case, the UE would not try anything when you put into test USIM).

Two more checks help when the USIM is fine. First, compare the downlink EARFCN of the cell with the bands that the UE supports. A UE scans only its own E-UTRA bands, so a cell outside them is invisible to it. Second, check the network mode setting on the UE. If the UE is set to a mode without LTE, it does not scan LTE frequencies at all.

• An empty network log points at the UE : if the eNB sees no PRACH at all, start with the USIM, the band and the UE settings.
• The band must match first : a correct cell configuration on an unsupported band looks the same as no cell.

"No Service" on Power On

When you turn on the UE connected to the network simulator, you will see "Searching Network... " message for several seconds and you will be sweating a lot for this period if you are protocol stack developer or test case developer.

If it goes to next step and UE start registration, you will be happy and the problem happens when it stop searching and "No Service" message pops up.

First step would be to read section 5.1, 5.2 of 36.331 and get the clear understanding of what is the expected procedure on UE and Network side.

If I have the UE logging tool, I would first check it to see if the UE correctly decoded MIB, SIB1, SIB2 at least. When the UE side log is not available or UE log shows that any one of these are not recieved, we have to see the network side log or protocol stack source code if it is available. In most case you would see that MIB, SIB1, SIB2 is not missing. Then why UE fails to decode them ?

Two possibilities that I can think of

i) The scheduling information on SIB1 for other SIBs so that multiple SIBs overwrite each other.

ii) There is no problem in the scheduling, but UE has some issues with being tuned for the specific schedule. (This kind of situation would not happen when the technology is mature but possible at the initial phase of technology like LTE and I have experienced this situation).

If you have a tool to monitor UE side log, I would recommend you to check.

i) Check if UE decode all the SIBs properly. In LTE case, MIB, SIB1, SIB2 should be mandatory. So you have to make it sure that your device successfully decoded these SIBs.

ii) Examine the SIB scheduling information in SIB1. SIB1 carries the scheduling information for other SIBs.. so your device should decode all the SIBs scheduled by SIB1. If UE failed to decode any one of these SIB, UE would keep waiting for the missing SIB without trying any other things (e.g, initiating RACH process). This be behavior would vary depending on NAS layer implementation on each UE. (I have experienced different behaviour from different protocol stack implementation. In one implementation, I saw a UE never camp on the network unless it decodes all the SIBs specified in SIB1 and I also another UE camp on the network once it successfully decoded SIB1 and 2 even though it didn't decode other SIBs configured in SIB1).

All the SIBs are decoded but UE does not initiate RACH process.

The highest possibility would be that the Band Indicator in SIB1 would not match what UE is configured for. Most of UE (especially a commercialized UE) is configured only for one or a couple of specific bands. Many of UE NAS does not trigger RACH process if the band indicator on SIB1 does not match what it is configured for. .. but the UE behavior in this case would vary a little bit depending on it's NAS implementation.

The band indicator is the first check, but it is not the only reason for silence. The UE starts RACH only after it selects the cell and has something to send. Let's list the other checks in the order the UE applies them.

First, SIB1 may say that the cell is barred. The UE does not camp on a cell whose cellBarred is set to barred. Second, the PLMN in SIB1 must be one that the UE is allowed to select. A commercial UE can block a test PLMN such as 001-01. Third, the cell must pass the cell selection criterion S of 36.304, where Srxlev and Squal must both be above zero. If q-RxLevMin in SIB1 is higher than the RSRP that the UE measures, Srxlev stays below zero. Fourth, access class barring in SIB2 can block the RRC connection attempt even on a suitable cell.

• No RACH usually means no suitable cell : check barring, PLMN and the S criterion before you suspect the PHY.
• Only the UE log can tell which check failed : the network sees nothing in this case, so the reason is on the UE side.

Not all SIBs are decoded

Let's suppose that you have UE side logging tool and captured SIB reception part. You would almost always see SIB1 decoded (If SIB1 is not decoded, you may failed even at frequency search phase. In this case, you have to check if UE properly decoded Physical Cell ID properly.)

Let's assume that you have SIB1 decoded (In UMTS case, let's assume you have MIB decoded).

In this case, the first thing you have to do is to check SIB scheduling portion contained in SIB1 (or MIB in UMTS) and check all the SIBs listed in the SIB scheduling part is properly decoded.

What if Not all SIBs are decoded ? Some of the SIBs are missing.

In this case, you have to think about following things.

i) Did UE fail to decode the missing SIBs ? (i.e, UE tried to decoded it but couldn't decode it)

ii) Did UE chose not to decode the missing SIBs ? (i.e, UE could have decoded it, but didn't decode it)

One of the most common cause of case i) would be that wrong SIB scheduling and multiple SIBs are overwriting each other. You have to check the schedule again and make sure that there are no SIBs overwriting others.

Common causes of case ii) would be

a) The frequency specified in the band indicator in SIB1 does not match with the band that UE detected.

b) The SIBs from the cell ID and PLMN (in SIB1) has already decoded. (If you configured the two cells with same cell ID and PLMN, definitely by mistake, the SIBs (except SIB1) for the second cell may not be decoded because UE think it has already decoded all the SIBs when it camp on the first cell.

Network detected but no further progress

"No Service" message shown on UE screen but no registration process starts. The first item you have to check at this stage is to check whether UE sent RACH or not. How do we verify this ?

i) Check UE log if the log says "RACH" get transmitted

ii) Check Network emulator log if it received "PRACH" signal (You need to have Network emulator which has very detailed logging capability to show this).

iii) Use spectrum analyzer to detect PRACH from UE (Since the signal analyzer does not know exactly the PRACH signal comes in and the PRACH is a burst type of signal, put the spectrum analyzer in zero-span mode and set the proper trigger for it).

Compare the PRACH configuration on both sides when the UE log says that the preamble went out but the eNB saw nothing. The UE takes it from SIB2, and the eNB must use exactly the same values. The key fields are prach-ConfigIndex, rootSequenceIndex, zeroCorrelationZoneConfig, highSpeedFlag and prach-FreqOffset. One wrong value moves the preamble in time or frequency, or changes the sequence that the eNB correlates against.

Power is the next check. The UE sets the first preamble power from preambleInitialReceivedTargetPower, between dBm-120 and dBm-90. It adds powerRampingStep, from 0 to 6 dB, on each retry. After preambleTransMax attempts, from n3 to n200, the MAC indicates a Random Access problem to upper layers. So when the UE log shows a run of preambles at rising power, you are looking at the normal pattern of an unanswered PRACH.

• PRACH parameters must match exactly : the eNB detects a preamble only with the configuration it expects.
• Rising preamble power means no RAR arrived : the retry pattern in the UE log tells you that the eNB did not answer, but not why.

UE keep sending PRACH

In normal case, if UE send PRACH and network send RACH Response and UE is supposed to stop sending PRACH and initiate RRC Session by sending 'RRC Connection Request'. If UE keep sending PRACH, it means there is some issues with processing 'RACH Response' process.

i) Check Network emulator log if it received "PRACH" signal (You need to have Network emulator which has very detailed logging capability to show this).

ii) Check Network emulator log if it sent RA Response.

iii) Check Network emulator log if the timing requirement between PRACH reception and RA Response has been satisfied. (Even though network sents the RA Reponse, UE keep trying RACH process if network sent it too late).

iv) Check UE log if the log says "RACH Response" recieved

v) Check UE log if the PRACH transmission and RA Response has been done within the timing requirement.

Another possibility would be the following case,

i) UE transmit PRACH Preamble

ii) Network sent RACH Response

iii) UE properly decode RACH response

iv) UE sent 'RRC Connection Request'

v) Network failed to decode 'RRC Connection Request' and does not send 'RRC Connection Setup'

vi) (Timeout for 'RRC Connection Setup') UE reinitiate PRACH process

If you see the network side log, you would not see 'RRC Connection Request' even though UE log says it sent the message.

The most common cause for this situation would be related to step iii) and iv). If you read the 'Understand RACH !' section, you would remember that RACH Response message carries 'UL Grant' which basically carries the resource allocation for 'RRC Connection Request' message. If UE uncorrectly decoded 'RA response' message, it will send 'RRC Connection Request' message in the wrong locations and network would fail to decode it even though UE sent the message. Another possibility can on network side. If network sent wrong RACH Response message (wrong UL Grant) which is different from it's MAC Layer setting setting for UL CCCH, it would fail to decode it. This kind of problem would happen pretty often when you create test case for UE testing. If you have a working test scenario on a certain system bandwidth and then just changed the System Bandwidth and all of the sudden RACH process fails.. in this case the first place you have to check would be UL Grant field of RA Response message.

If something problem happened at very low level, there can be some possibility that the problem happened at the very first step.

i) UE send RACH

ii) Network Trace log says it didn't received anything. (PRACH Reception/Decoding Failure)

Actually this is the most difficult type of troubleshooting mainly because you don't get any information on network side log. But at least you can (should) try following.

i) Check on UE side log and see if you can identify PRACH. Since RACH is MAC layer process, you may see RACH transmission in protocol log, but it might not have transmitted in PHY layer.

ii) If you can identify PRACH signal on UE log, figure out SFN:Subframe number for the PRACH and also figure out PRACH transmission power (UL power).

iii) Check on Nework log to see if it get any PUSCH or even any Physical layer error at the UL timing (SFN:Subframe)

iv) If you don't see anything (neither PRACH nor any PHY error) on network side log, there might be some possibilities as follows.

a) PRACH transmission power is too low or too high comparing to the dynmic range of the access network (eNB)

b) PRACH transmission Timing is too far away from the UL frame timing. (PRACH is expected to be non-synchronized signal, Synchronization tolerance would be larger than PUSCH case, but still too much offset from the UL subframe timing would cause in reception on network side)

Normally at this point, there tend to be many finger pointing to each other :)

UE side engineer would say 'our log say UE has sent PRACH, so this is network problem of PRACH deconding failure.

Network side engineer would say 'we don't have any problem on network side since it has been working OK with all other devices, so probably the PRACH signal from UE might not be properly transmitted'.

In this case, you may use Spectrum Analyzer to capture PRACH and see if it is properly transmitted or not. If you can show some form of PRACH burst as shown on RF PRACH Snapshot section, we can say UE side engineer is in better position to attach Network side engineer :)

However even Spectrum Analyzer result cannot be the final conclusion unless you can get all the detained information about Frequency Error, Timing Error, PRACH bit data which normally require another extra cabling and processing equipment or tools which is out of the scope of this post.

In conclusion, PRACH reception failure troubleshooting can be extremly tough to troubleshoot depending on situation. I don't think can provide all the details of tricks here because you may need extra equipment (like digital oscilloscope with frame Sync connection, I/Q capturing equipment etc) and then pass it to FPGA engineers to analyze further details.

I have experienced with this issues at early stage of chipset development (around 3~4 years ago), but haven't seen often lately (Apr 2015).

UE log says "It sent Msg3", but Network log says "It hasn't received it".

In this case each log looks correct on its own side. The UE log shows a decoded RAR and a transmitted Msg3, but the network log shows nothing on the granted PUSCH. So we have to align the two logs step by step.

For the troubleshoot at this step, we need to know all the details regarding this step.

i)UE send PRACH

ii) Network send RACH Response (RAR) which carries Resource Allocation for Msg3

iii) UE send Msg3 from RRC after 6 or 7 subframe after it get RAR

iv) UE transmit PUSCH containing Msg3 from UE PHY using the resource allocation on RAR

v) Network tries to decode Msg3 from the resource allocation specified by RAR

As you may guess from the steps listed above, it will be very difficult to roubleshoot unless you have very detailed logging tool on both side (UE and Network side)

If you can answer all of the following questions you would almost automatically figure out what is the problem.

a) Is the resource allocation from RAR the same as resource allocation for PUSCH transmission ? (You have to compare RAR from Network log and what UE decoded from RAR)

b) Does UE transmit Msg3 at right timing ? (You have to check the SFN:Subframe number when UE transmit PUSCH carrying Msg3).

c) Is Network trying to decode Msg3 at proper resource allocation ? (It may be possible that Network allocated a specific location in RAR but I tried to decode the message at different location. In this case, it is Network or Network emulator's bug. But I think this would be very rare case and in this case all the UE will fail at this step).

Most of trace log will give you the answer to question a),b),c). But the answer to all of the question does not have any problem, the situation gets tricky and you may need some additional equipment for troubleshoot. If you have really detailed logging tool on Network side, you may check the following.

d) Does Network (Network Emulator) properly decode DMRS for PUSCH ?

If the answer is Yes, you have to further details of PUSCH configuration parameters which may require L1 base band engineers on both side.

If the answer is No, there is another possibility. The possibility would be that UE sent PUSCH but the transmission timing (in the unit of baseband samples, not in the unit of subframe) does not exactly align with subframe timing on Network side. The allowable timing offset is specified in "7.1.2 Requirements" on TS36.133 (See the following table).

UE sent Message3 and Network sent Message4, but UE does not send Message5

There can be many cause for this, but one of the most common cause especially during the early protocol stack development would be the mistmatch between UE id in message 3 and and message 4. It means there is problems with contention resolution.

For a reference, let us see an successful case for message 3 and message 4.

< Msg3 and Msg4 MAC PDUs in hex > capture. Byte values come from a live capture, not from the specification.

UE -> Network (Message 3): 20 06 1F 53 01 E0 E6 D3 D6
Network -> UE (Message 4): 3C 20 11 1F 53 01 E0 E6 D3 D6 60 12 9B 3E 86 0F B5 79 68 96 6C 30 64 99 C0 58 F0

The data in blue is MAC header. The red part is the message 3 contents. The green part is the message 4 RRC/NAS layer contents.

Actually RRC part of the whole message 3 becomes an UE ID for the contetional resolution. If you see the hex string above, you will see the red part in message 3 matches with the red part in message 4. If these two red part does not match, UE does not send Message 5.

Simply put, this is Contention Resolution Failure.

Network - Network simulator - sent some data but HARQ ACK/NACK does not received

This kind of troubleshooting is extremely difficult mainly because of the capability of the logging tools and the amount of data you have to analyze. From what I experienced, most of logging tool especially UE side logging tools does not capture this level of log and sometime they have such a logging capability but disables it when they test full protocol stack. I understand the reason behind it. If you enable all of the logging at this level, the amount of log will become huge or the log collection itself would consume a lot of processing power and in worst case the logging process would cause problem in normal protocol stack operation.

Anyway I would comments on this based on the assumption that you have a very detailed logging tool both on UE side and Network side.

One of the basic methodoloty of troubleshooting is just to follow each and every steps of normal process and check all of the steps.

Too simple ?  Yes.. it is very simple.. but I see many cases where even these simple procedure is ignored and the troubleshooting process is purely going with blind repetition of hit-and-miss.

OK.. then let's think about a normal data transmission with ACK/NACK. It is as follows :

i) Network High Layer ( RRC or TE)  -> Lower Layer : Transmit the data toward the lower layer.

ii) Network -> UE : Transmit the data via PDSCH

iii) UE receive PDSCH data

iv) UE checks CRC error for the PDSCH data

v) Now we have two cases at this point,

    a) If UE has some data to transmit to the network, UE send the result of CRC check(ACK/NACK) via PUSCH

    b) If UE does not have any data to transmit to the network, UE sends the result CRC check via PUCCH

vi) Network receives CRC check result from UE and do one of the following steps.

    a) If it receives ACK, Network transmit the next data (new data)

    b) If it receives NACK, Network HARQ process retransmit the exisiting data (with different revision)

For somebody who does not like to read, here goes illustrated version of the process -:).

As I said above, the first step is to go through UE and Network side log to make it sure each of the steps has been done properly. if you have a proper logging tool, you will troubleshoot relatively easily upto step v). But you will come across a tricky situation, if something happens between step v) and vi).

Let me give you an example of this tricky situation. Let's assume that UE sent ACK/NACK via PUCCH, but network didn't get it. In this case, the first thing you have to check is all the parameter settings configuring PUCCH. PUCCH related parameters are distributed across multiple places. SIB2 and RRC Connection Setup is the most important check point. In SIB2, you will find the following parameters which is related to PUCCH reception itself.

< pucch-ConfigCommon inside a decoded SIB2 > capture. Field values come from a live capture, not from the specification.

            |     | +-pucch-Config ::= SEQUENCE
            |     | | +-deltaPUCCH-Shift ::= ENUMERATED [ds2]
            |     | | +-nRB-CQI ::= INTEGER (0..98) [2]
            |     | | +-nCS-AN ::= INTEGER (0..7) [6]
            |     | | +-n1PUCCH-AN ::= INTEGER (0..2047) [0]

In RRC Connection Setup, you will find the following information elements related to ACK/NACK transmission from UE

< pucch-ConfigDedicated inside a decoded RRC Connection Setup > capture. Field values come from a live capture, not from the specification.

              |   +-pucch-ConfigDedicated ::= SEQUENCE [0] OPTIONAL:Exist
              |   | +-ackNackRepetition ::= CHOICE [release]
              |   | | +-release ::= NULL
              |   | +-tdd-AckNackFeedbackMode ::= ENUMERATED OPTIONAL:Omit

First you have to check if UE configured itself as specified in these radio message (SIB2, RRC Connection Setup). If UE configured all of these prameters correctly, the next step you have to do is to check on network side if network configured PUCCH decoding process as indicated on these radio message. If you find any single mismatches among those check points, Network would not be able to decode ACK/NACK even though UE transmitted it.

RRC Connection Reconfiguration Complete doesn't get received on network side

'RRC Connection Reconfiguration' is similar to 'Radio Bearer Setup' message in WCDMA, 'RRC Connection Reconfiguration Complete' message is similar to 'Radio Bearer Setup Complete'. In WCDMA case, if there is some settings in Radio Bearer Setup which is in wrong format or cannot be supported by UE, UE send 'Radio Bearer Setup Failure' message. But in LTE RRC Connection Reconfiguration, UE just does not send anything if there is some problem in the message and this makes troubleshooting very difficult. For example, when you are writing a test case and you don't get 'RRC Connection Reconfiguration Complete' message, there are multiple possible causes as follows :

i) UE failed to receive 'RRC Connection Reconfiguration'

ii) UE received 'RRC Connection Reconfiguration', but there was some information element that cannot be setup by UE

iii) UE received 'RRC Connection Reconfiguration' and transmitted 'RRC Connection Reconfiguration Complete' but Network failed to receive it. (It didn't even detected in Network PHY layer. or It detected by network PHY layer but CRC error happened).

If you come across case iii), the first thing you would check is 'TransmissionMode'. For example, if UE is connected in only one Antenna but 'RRC Connection Reconfiguration' TransmissionMode setting is multiple Antenna configuration, like TM2, TM3 etc.

The trickest one is case ii). In this case, you have to go through every IE(information elements) in the message and check if all those elements comply to UE capability.

The current 36.331 describes what the UE does in case ii). Clause 5.3.5.5 says that a UE unable to comply with part of RRC Connection Reconfiguration keeps its previous configuration. If security is not active yet, the UE leaves RRC_CONNECTED with release cause other. Otherwise it starts RRC connection re-establishment. So the UE is not supposed to stay silent. Look for an RRC Connection Reestablishment Request in the network log right after the reconfiguration.

• An unusable reconfiguration triggers re-establishment : with security active, an RRC Connection Reestablishment Request right after RRC Connection Reconfiguration points at case ii).
• The UE applies all of it or none of it : 36.331 allows no partial success, so one unsupported IE blocks the whole message.

EMM : Security Mode Reject with the cause of #23:UE security capabilities mismatch

I saw this problem with some UEs while I was creating a network simulator program to test UE. With the same program, some UE had this problem but other UE did not. But I think the behavior of UEs that generating this Reject message is correct, meaning my network simulator program had a problem -:).

The issue was that UE send EMM : Security Mode Reject message with the cause of 23 as follows in response to EMM : Security Mode Command.

< EMM Security mode reject, cause #23 > capture. Field values come from a live capture, not from the specification.

NAS_LTE:EMM,Security mode reject
Security mode reject ::= DIVISION
  +-Security header type ::= V
  | +-Security header type ::= CHOICE [Plain NAS message, not security protected]
  +-EPS mobility management protocol discriminator ::= V
  | +-Protocol discriminator ::= PD [7]
  +-Security mode reject message identity ::= V
  | +-Message type ::= MSG [5F]
  +-EMM cause ::= V
    +-Cause value ::= CHOICE [#23:UE security capabilities mismatch]

The EMM:Security Mode Command should carry the UE capability that was reported by UE via Attach Request message. More specifically, the part that caused problem is the one marked in red as follows.

< Security mode command inside a Security protected NAS message > capture. Field values come from a live capture, not from the specification.

[NAS_LTE:EMM,Security protected NAS message
Security protected NAS message ::= DIVISION
  +-Security header type ::= V
  | +-Security header type ::= CHOICE [Integrity protected with new EPS security context]
  +-EPS mobility management protocol discriminator ::= V
  | +-Protocol discriminator ::= PD [7]
  +-Message authentication code ::= V
  | +-Message authentication code ::= OCTETARRAY SIZE(4..4) [00000000]
  +-Sequence number ::= V
  | +-Sequence number ::= INT (0..255) [0]
  +-NAS message ::= V
    +-Octet1- ::= DIVISION
      +-NAS message ::= OCTETARRAY SIZE(0..65535) [075D000002E0E0]

The EMM:Security Mode Command is supposed to specify the UE security capability which is reported to network by Attach Request as shown below.

< EMM Attach request > capture. Field values come from a live capture, not from the specification.

NAS_LTE:EMM,Attach request
Attach request ::= DIVISION
  +-Security header type ::= V
  | +-Security header type ::= CHOICE [Plain NAS message, not security protected]
  +-EPS mobility management protocol discriminator ::= V
  | +-Protocol discriminator ::= PD [7]
  +-Attach request message identity ::= V
  | +-Message type ::= MSG [41]
  +-NAS key set identifier ::= V
  | +-TSC ::= CHOICE [native security context (for KSI ASME)]
  | +-NAS key set identifier ::= CHOICE [no key is available]
  +-EPS attach type ::= V
  | +-Spare ::= FIX [0]
  | +-EPS attach type value ::= CHOICE [EPS attach]
  +-Old GUTI or IMSI ::= LV
  | +-Octet1 ::= DIVISION
    ....
  | +-Octet12 ::= DIVISION
  +-UE network capability ::= LV
  | +-Octet1 ::= DIVISION
  | | +-Length of UE network capability contents ::= LEN (0..255) [2]
  | +-Octet2 ::= DIVISION
  | | +-EEA0 ::= CHOICE [EPS encryption algorithm EEA0 supported]
  | | +-128-EEA1 ::= CHOICE [EPS encryption algorithm 128-EEA1 supported]
  | | +-128-EEA2 ::= CHOICE [EPS encryption algorithm 128-EEA2 supported]
  | | +-EEA3 ::= CHOICE [EPS encryption algorithm EEA3 not supported]
  | | +-EEA4 ::= CHOICE [EPS encryption algorithm EEA4 not supported]
  | | +-EEA5 ::= CHOICE [EPS encryption algorithm EEA5 not supported]
  | | +-EEA6 ::= CHOICE [EPS encryption algorithm EEA6 not supported]
  | | +-EEA7 ::= CHOICE [EPS encryption algorithm EEA7 not supported]
  | +-Octet3 ::= DIVISION
  | | +-spare ::= FIX [0]
  | | +-128-EIA1 ::= CHOICE [EPS integrity algorithm 128-EIA1 supported]
  | | +-128-EIA2 ::= CHOICE [EPS integrity algorithm 128-EIA2 supported]
  | | +-EIA3 ::= CHOICE [EPS integrity algorithm EIA3 not supported]
  | | +-EIA4 ::= CHOICE [EPS integrity algorithm EIA4 not supported]
  | | +-EIA5 ::= CHOICE [EPS integrity algorithm EIA5 not supported]
  | | +-EIA6 ::= CHOICE [EPS integrity algorithm EIA6 not supported]
  | | +-EIA7 ::= CHOICE [EPS integrity algorithm EIA7 not supported]
  | +-Octet4 ::= DIVISION
  | | +-UEA0 ::= CHOICE [UMTS encryption algorithm UEA0 not supported]
  | | +-UEA1 ::= CHOICE [UMTS encryption algorithm UEA1 not supported]
  | | +-UEA2 ::= CHOICE [UMTS encryption algorithm UEA2 not supported]
  | | +-UEA3 ::= CHOICE [UMTS encryption algorithm UEA3 not supported]
  | | +-UEA4 ::= CHOICE [UMTS encryption algorithm UEA4 not supported]
  | | +-UEA5 ::= CHOICE [UMTS encryption algorithm UEA5 not supported]
  | | +-UEA6 ::= CHOICE [UMTS encryption algorithm UEA6 not supported]
  | | +-UEA7 ::= CHOICE [UMTS encryption algorithm UEA7 not supported]
  | +-Octet5 ::= DIVISION
  | | +-UCS2 ::= CHOICE [The UE has a preference for the default alphabet]
  | | +-UIA1 ::= CHOICE [UMTS integrity algorithm UIA1 not supported]
  | | +-UIA2 ::= CHOICE [UMTS integrity algorithm UIA2 not supported]
  | | +-UIA3 ::= CHOICE [UMTS integrity algorithm UIA3 not supported]
  | | +-UIA4 ::= CHOICE [UMTS integrity algorithm UIA4 not supported]
  | | +-UIA5 ::= CHOICE [UMTS integrity algorithm UIA5 not supported]
  | | +-UIA6 ::= CHOICE [UMTS integrity algorithm UIA6 not supported]
  | | +-UIA7 ::= CHOICE [UMTS integrity algorithm UIA7 not supported]
  | +-Octet6 ::= DIVISION
  | | +-spare ::= FIX [0]
  | | +-1xSRVCC ::= CHOICE [SRVCC from E-UTRAN to cdma2000 1xCS not supported]
  | | +-spare ::= FIX [0]
  | +-Octet7-14 ::= DIVISION
  |   +-Spare ::= OCTETARRAY SIZE(0..8) [00]
  +-ESM message container ::= LV-E
  | +-Octet1-Octet2 ::= DIVISION
  | | +-Length of ESM message container ::= LEN (0..65535) [17]
  | +-Octet3- ::= DIVISION
  |   +-ESM message container contents ::= OCTETARRAY SIZE(0..65535) [0201D031D1270A80000300000100000A00]
  +-Old P-TMSI signature ::= TV OPTIONAL:Omit
  | +-Octet1 ::= DIVISION
  | | +-P-TMSI signature IEI ::= IEI [19]
  | +-Octet2-4 ::= DIVISION
  |   +-P-TMSI signature value ::= INT (0..16777215) [0]
  +-Additional GUTI ::= TLV OPTIONAL:Omit
   ....
  +-MS network capability ::= TLV OPTIONAL:Omit
   ....
  +-Old location area identification ::= TV OPTIONAL:Omit
  +-TMSI status ::= TV OPTIONAL:Omit
  +-Mobile Station Classmark 2 ::= TLV OPTIONAL:Omit
  +-Mobile Station Classmark 3 ::= TLV OPTIONAL:Omit
  +-Supported Codecs ::= TLV OPTIONAL:Omit
  +-Additional update type ::= TV OPTIONAL:Omit

The EMM : Security Mode Command should replay the UE capability from Attach Request as follows.

< EMM Security mode command with the replayed UE security capabilities > decoded message. Field values come from a live capture, not from the specification.

NAS_LTE:EMM,Security mode command
Security mode command ::= DIVISION
  +-Security header type ::= V
  | +-Security header type ::= CHOICE [Plain NAS message, not security protected]
  +-EPS mobility management protocol discriminator ::= V
  | +-Protocol discriminator ::= PD [7]
  +-Security mode command message identity ::= V
  | +-Message type ::= MSG [5D]
  +-Selected NAS security algorithms ::= V
  | +-Octet1 ::= DIVISION
  |   +-spare ::= FIX [0]
  |   +-Type of ciphering algorithm ::= CHOICE [EPS encryption algorithm EEA0(ciphering not used)]
  |   +-spare ::= FIX [0]
  |   +-Type of integrity protection algorithm ::= CHOICE [Reserved 0]
  +-Spare half octet ::= V
  | +-Spare half octet ::= FIX [0]
  +-NAS key set identifier ::= V
  | +-TSC ::= CHOICE [native security context (for KSI ASME)]
  | +-NAS key set identifier ::= CHOICE [possible values for the NAS key set identifier 0]
  +-Replayed UE security capabilities ::= LV
  | +-Octet1 ::= DIVISION
  | | +-Length of UE security capability contents ::= LEN (0..255) [2]
  | +-Octet2 ::= DIVISION
  | | +-EEA0 ::= CHOICE [EPS encryption algorithm EEA0 supported]
  | | +-128-EEA1 ::= CHOICE [EPS encryption algorithm 128-EEA1 supported]
  | | +-128-EEA2 ::= CHOICE [EPS encryption algorithm 128-EEA2 supported]
  | | +-EEA3 ::= CHOICE [EPS encryption algorithm EEA3 not supported]
  | | +-EEA4 ::= CHOICE [EPS encryption algorithm EEA4 not supported]
  | | +-EEA5 ::= CHOICE [EPS encryption algorithm EEA5 not supported]
  | | +-EEA6 ::= CHOICE [EPS encryption algorithm EEA6 not supported]
  | | +-EEA7 ::= CHOICE [EPS encryption algorithm EEA7 not supported]
  | +-Octet3 ::= DIVISION
  | | +-spare ::= FIX [0]
  | | +-128-EIA1 ::= CHOICE [EPS integrity algorithm 128-EIA1 supported]
  | | +-128-EIA2 ::= CHOICE [EPS integrity algorithm 128-EIA2 supported]
  | | +-EIA3 ::= CHOICE [EPS integrity algorithm EIA3 not supported]
  | | +-EIA4 ::= CHOICE [EPS integrity algorithm EIA4 not supported]
  | | +-EIA5 ::= CHOICE [EPS integrity algorithm EIA5 not supported]
  | | +-EIA6 ::= CHOICE [EPS integrity algorithm EIA6 not supported]
  | | +-EIA7 ::= CHOICE [EPS integrity algorithm EIA7 not supported]
  | +-Octet4 ::= DIVISION
  | | +-UEA0 ::= CHOICE [UMTS encryption algorithm UEA0 not supported]
  | | +-UEA1 ::= CHOICE [UMTS encryption algorithm UEA1 not supported]
  | | +-UEA2 ::= CHOICE [UMTS encryption algorithm UEA2 not supported]
  | | +-UEA3 ::= CHOICE [UMTS encryption algorithm UEA3 not supported]
  | | +-UEA4 ::= CHOICE [UMTS encryption algorithm UEA4 not supported]
  | | +-UEA5 ::= CHOICE [UMTS encryption algorithm UEA5 not supported]
  | | +-UEA6 ::= CHOICE [UMTS encryption algorithm UEA6 not supported]
  | | +-UEA7 ::= CHOICE [UMTS encryption algorithm UEA7 not supported]
  | +-Octet5 ::= DIVISION
  | | +-spare ::= FIX [0]
  | | +-UIA1 ::= CHOICE [UMTS integrity algorithm UIA1 not supported]
  | | +-UIA2 ::= CHOICE [UMTS integrity algorithm UIA2 not supported]
  | | +-UIA3 ::= CHOICE [UMTS integrity algorithm UIA3 not supported]
  | | +-UIA4 ::= CHOICE [UMTS integrity algorithm UIA4 not supported]
  | | +-UIA5 ::= CHOICE [UMTS integrity algorithm UIA5 not supported]
  | | +-UIA6 ::= CHOICE [UMTS integrity algorithm UIA6 not supported]
  | | +-UIA7 ::= CHOICE [UMTS integrity algorithm UIA7 not supported]
  | +-Octet6 ::= DIVISION
  |   +-spare ::= FIX [0]
  |   +-GEA1 ::= CHOICE [GPRS encryption algorithm GEA1 not supported]
  |   +-GEA2 ::= CHOICE [GPRS encryption algorithm GEA2 not supported]
  |   +-GEA3 ::= CHOICE [GPRS encryption algorithm GEA3 not supported]
  |   +-GEA4 ::= CHOICE [GPRS encryption algorithm GEA4 not supported]
  |   +-GEA5 ::= CHOICE [GPRS encryption algorithm GEA5 not supported]
  |   +-GEA6 ::= CHOICE [GPRS encryption algorithm GEA6 not supported]
  |   +-GEA7 ::= CHOICE [GPRS encryption algorithm GEA7 not supported]
  +-IMEISV request ::= TV OPTIONAL:Omit
  +-Replayed nonce UE ::= TV OPTIONAL:Omit
  +-Nonce MME ::= TV OPTIONAL:Omit

Let's decode the red E0E0 against 24.301 v20.0.0. The UE network capability in Attach Request has a length of 2, so the UE sent two octets. The EEA octet is E0, with EEA0, 128-EEA1 and 128-EEA2 supported. The EIA octet has bit 8 at 0 and 128-EIA1 and 128-EIA2 set, which is 60. The simulator replayed E0 E0, so bit 8 of the second octet differs.

In the current 24.301 that bit is EIA0, the null integrity algorithm, while the decoder in these captures still labels it spare. The UE compares the replayed UE security capabilities with the values it sent (24.301 5.4.3.3). One changed bit is enough, and the UE answers with Security Mode Reject cause #23 (24.301 5.4.3.5).

The captures disagree with the current specification in one more place. The selected NAS security algorithms octet is 00, and the decoder shows the integrity algorithm as Reserved 0. The current 24.301 codes 000 as EIA0. A UE accepts EIA0 only for emergency bearer services or RLOS access. So a current UE rejects this selection on a normal attach, even with a correct replay.

• The replay is compared bit by bit : a network simulator must copy the UE network capability octets exactly, including bits that its decoder calls spare.
• EIA0 is only for emergency or RLOS : a normal attach needs a real integrity algorithm such as 128-EIA1 or 128-EIA2.

PDN Disconnect Request / EMM Detach Request right after EPS Bearer Setup or No Attach Complete/No Activate Default EPS Bearer Accept

This has been one of the biggest headache for UE testing and the root cause was also unclear for a long time (I think I spent several month just to know the cause of the problem, not to mention the solution).

IPv6 related issue

Let's start with the most common trigger. The detach comes after the default EPS bearer is already up, so the RRC and NAS logs look normal. The cause sits one layer higher, in IPv6 address configuration.

It seems this problem happens when we use Ipv6 or Ipv4v6

In IPv6, as soon as a network interface (Network Card, LTE UE with IPv6 works as a network interface as well) is activated, it should automatically go through the following procedure.

i) Networt Interface (Network Card, Device) send "Router Solicitation" to the Router (The network the device is connected to).

ii) Router (the network) reply it with "Router Advertisement".

It seems that whenever a UE with configured for Ipv6 get connected (setup an EPS bearer), it automatically send "Router Solicitation" message (This is not LTE OTA message, it is ethernet protocol message). If UE does not get any response (Router Advertisement) from the other side, initial it retries a couple of times.. but it does not get any response with all those retries, UE just send 'EMM Detach Request' message.

More specifically, in normal case UE seems to go through following sequence.

i)  [NW --> UE] RRC : RRC Connection Reconfiguration + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req (In case, EPS Bearer is using IPv6 or IPv4v6).

ii)  [NW <-- UE] RRC : Connection Reconfiguration Complete

iii) [NW <-- UE] NAS : Attach Complete

iv) [NW <-- UE] NAS : Activate Default EPS Bearer Context Accept

v) [Router <-- UE NIC] Router Solicitation

vi) [Router --> UE NIC] Router Advertisement

I saw Abnormal case happens in various different mode depending on UE implementation. A couple of sample case that I experienced were as follows.

< Case 1 >

i)  [NW --> UE] RRC : RRC Connection Reconfiguration + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req (In case, EPS Bearer is using IPv6 or IPv4v6).

ii)  [NW <-- UE] RRC : Connection Reconfiguration Complete

iii) [NW <-- UE] No NAS : Attach Complete

iv) [NW <-- UE] No NAS : Activate Default EPS Bearer Context Accept

v) [Router <-- UE NIC] Router Solicitation

vi) [Router --> UE NIC] No Router Advertisement or Router Advertisement fail to reach UE NIC

vii) [Router <-- UE NIC] Router Solicitation

viii) [Router --> UE NIC] No Router Advertisement or Router Advertisement fail to reach UE NIC

ix) [Router <-- UE NIC] Router Solicitation

x) [Router --> UE NIC] No Router Advertisement or Router Advertisement fail to reach UE NIC

< Case 2 >

i)  [NW --> UE] RRC : RRC Connection Reconfiguration + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req (In case, EPS Bearer is using IPv6 or IPv4v6).

ii)  [NW <-- UE] RRC : Connection Reconfiguration Complete

iii) [NW <-- UE] NAS : Attach Complete

iv) [NW <-- UE] NAS : Activate Default EPS Bearer Context Accept

v) [Router <-- UE NIC] Router Solicitation

vi) [Router --> UE NIC] No Router Advertisement or Router Advertisement fail to reach UE NIC

vii) [Router <-- UE NIC] Router Solicitation

viii) [Router --> UE NIC] No Router Advertisement or Router Advertisement fail to reach UE NIC

ix) [Router <-- UE NIC] Router Solicitation

x) [Router --> UE NIC] No Router Advertisement or Router Advertisement fail to reach UE NIC

xi) [NW <-- UE] NAS : Detach Request

< Case 3 >

i)  [NW --> UE] RRC : RRC Connection Reconfiguration + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req (In case, EPS Bearer is using IPv6 or IPv4v6).

ii)  [NW <-- UE] RRC : Connection Reconfiguration Complete

iii) [NW <-- UE] NAS : Attach Complete

iv) [NW <-- UE] NAS : Activate Default EPS Bearer Context Accept

v) [Router <-- UE NIC] Router Solicitation

vi) [Router --> UE NIC] No Router Advertisement or Router Advertisement fail to reach UE NIC

vii) [Router <-- UE NIC] Router Solicitation

viii) [Router --> UE NIC] No Router Advertisement or Router Advertisement fail to reach UE NIC

ix) [Router <-- UE NIC] Router Solicitation

x) [Router --> UE NIC] No Router Advertisement or Router Advertisement fail to reach UE NIC

xi) UE setup the IP connection using IPv4

I saw < Case 3 > only in some UE, but not many.

If we can configure IPv4 only in the step i), this kind of problem would not occur. But the problem is that most of UE requires to use IPv6 or IPv4v6 in the first Default EPS Bearer and this requirement gives us a lot of trouble. In even worse case, some UE requires another IP application connection (e.g, IMS) after step ii) and create the same problem if it fails to get through the application service. You will have even more headache in this case -:)

23.401 5.3.1.2.2 describes the network side of this exchange. The PDN GW allocates a /64 IPv6 prefix and sends it in a Router Advertisement, solicited or unsolicited. The UE builds its link-local address from the interface identifier that the network provides. So when no Router Advertisement reaches the UE, the UE has no global IPv6 address on that PDN connection. Some UEs then stop trying and detach.

IPv4v6 Related Issue

In most case this configuration would not cause any problem even though RS(Router Solicitation)/RA(Router Advertisement) process is not complete since UE would fall back to IPv4. However, in some UE I saw UE initiate the detach process if RS/RA step does not go through.

Correlation issue with Signaling Message in previous steps

I have spent so much time to troubleshoot this case and learned another common root cause of unexpected EMM:Detach Request is due to wrong 'NAS:Security Mode Command'. In this case, UE would send 'NAS:Security Mode Reject', but UE goes to the next step unless network does not stop the process at the point. So I didn't realize this problem and try to find the root cause just around 'EMM:Detach Request' message. In conclusion, when you have EMM:Detach Request you have to think of the issues described in all of the following topics.

• EMM Detach Request right after EPS Bearer Setup or No Attach Complete/No Activate Default EPS Bearer Accept
• EMM : Security Mode Reject with the cause of #23:UE security capabilities mismatch
• Message Correlation Issues

Another very important cause that I found recently is mismatched 'Procedure transaction identity value' between PDN Connectivity Request and Activate Default EPS Bearer Setup Request. As you see the message relations shown below, the procedure transaction identity value should be replayed at ESM : Information Request and Activate Default EPS Bearer Setup request. If 'Procedure transaction identity value' between PDN Connectivity Request and Activate Default EPS Bearer Setup Request mismatches you would see following problem.

i)  [NW --> UE] RRC : RRC Connection Reconfiguration + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req (In case, EPS Bearer is using IPv6 or IPv4v6).

ii)  [NW <-- UE] RRC : Connection Reconfiguration Complete

iii) [NW <-- UE] RRC : ulInformationTransfer + EMM : Detach Request

APN Mistmatch

I saw this issue only recently (Mar 2015) with a specific UE. I don't think this is fully in comply with the specification, but I saw some UE having this issue.

i) RRC : RRC Connection Setup Complete + NAS : Attach Request + ESM : PDN Connectivity Request

...

ii) RRC : RRC Connection Reconfiguration Complete + NAS : AttachComplete + ESM : Activate Default EPS Bearer Context Accept

...

iii) Detach Request

Usually UE informs an APN name it wants to use at step i) and network allocate APN in step ii). As far as I understand, Network can assign any APN name at step ii) and the APN is allowed to be different from the one specified at step i). But with this specific UE, UE sent 'Detach Request' when APN at step ii) does not match the APN at step i).

Is there any solution for this problem ?

Ideally the solution is simple. You only have to change network configuration or UE configuration to make APN matched on UE and Network. But there are many cases where this match-making is not simple practically. Followings are some of the techniques that I used in usual test setting.

a) If you are using a test equipment (Network Simulator) with enough flexibility, you may configure the test equipment to assign APN whatever UE request. (Refer to APN (Access Point Name) in LTE if you are not familiar with APN assignment protocol)

b) If you are not in the situation to change network configuration but you have access to UE APN setting, you may change APN name in the setting (Refer to UE Setting Aspect of APN Assignement). <= If you are testing the UE at engineering stage (before commercial release), you may access to almost all UE settings. But once UE is put in the store, there are many cases in which APN setting is not allowed.. or some of APN is not open to UE (e.g, IMS APN).

c) There are some cases that UE APN setting is determined by a specific profile setting provided by UICC. <= This is tricky case. In this case, unless you are using a specific UICC, then APN match-making would not be possible.

d) In some case, UE APN setting is determined by a specific profile setting triggered by specific PLMN. In this case, you have to know what kind of profile is triggered by which PLMN. It means that you need to know about the information on UE implementation.

Notallowed PLMN

I see this problem with only some specific commericialized UE. When UE is not commercialized and being tested, they normally use test USIM with PLMN 001-01, but when they commericialize the UE, some company block the test PLMN. However, recently I saw a UE that has blocked the test PLMN "partially". In this UE, it complete LTE registration with the test PLMN but it sent Detach Request right after the registration. When I change the network PLMN to the specific carrier PLMN, it stay connected after the registration.

UE Internal Profile Setting

You may not see this kind of problem with your device and I would not describe very details of this case, but I briefly touches on this to show how diverse factors can cause this Detach Request problem and how hard it would be to troubleshoot. Usually the troubleshooting process is like hell when there can be so many different causes for a problem and normal protocol log does not carry any detailed information/hints on the problem. Detach Request is a typical example of this case.

In some UE configuration, when you power on UE, UE retrieves various information from various source (e.g, USIM or internal configuration file) and set some detailed profile (e.g, APN setting) based on those information. Sometimes some of these configuration is reset by the protocol sequence during the attach process. In some UE,  I saw UE send Detach Request if the internal configuration is set by attach process before it configures the setting based on USIM setting.

Don't worry if my explanation is not clear to you.. I am pretty sure that it would not clear if you had exactly same problem before.

The point is that this Detach Request can be triggered by so many strange factors.

IMS Registration Failure

This problem (or probably expected behavior) happens for some UE (some UE doesn't care) and happens when the APN is ims. UE send Detach Request when it fails to register CSCF (IMS Registration). Since this happens at the stage of IMS registration, you would see the detach request pretty long time (e.g, 10~30 sec) after the EPS Bearer Setup was complete and this would embarasse you even further. Check IMS Check List page and it would help you troubleshoot this case.

CRC Error

This is also one of the most common problem you would face when testing the device. But unfortunately there cannot be any single / clear solution for this since there can be too many different factors causing this error. So the first step would be to list up all the possible factors which may cause this problem and try to correlate those factors to the problem that you have.

There can be too main factor :

i) Parameters related to Physical Channel Encoding/Decoding process

ii) Transmission or Reception signal quality issue

One of the most important factor for item i) is RNTI mismatch. If this is the case, you would have 100% CRC error for all the received data.

Another factor you can think of it for item i), if it is uplink data (PUSCH), can be SRS configuration. Since PUSCH with SRC and without SRC go through a little bit different decoding process, if some parameter about this one does not match on UE and Network side, it would cause CRC error. In this case, check SIB2, RRC Connection Setup, RRC Connection Reconfiguration message and find all the parameters related to this and check if UE properly configured itself according to the instruction from the network.

Item ii) can also have two different factors as follows :

a) Signal Quality itself is bad

b) Signal Quality is OK, but some of parameter influencing Reciever side signal detection is not properly configured.

For a), there is no direct solution.. spend a long time going through a lot of different power setting (Tx Power, Rx Power etc).

For b), for now the only parameters that I can think of are p_a in RRC Connection Setup, RRC Connection Reconfiguration message and p_b in SIB2. But definitely there would be more of this kind.

Since the technology is mature and most of chipset/RF front end gets stable recently (since late 2014), the most common case were due to signal quality issue as follows.

a) RF quality (e.g, Cell Power) is not so good, but allocated too large MCS is allocated.

b) RF quality is too poor for any MCS (e.g, too low cell power or too high noise level)

c) Test equipment Reciever Dyanmic Range is not properly set to decode UL signal properly.

SR - Scheduling Request - Not Working

If UL Scheduling Request is not received by eNodeB (or Network Emulator) when UL Scheduling Method is set to be 'Non-Persistant' mode, there can be several possibilities as follows.

i) UE does not send SR for some reason (you have to check with UE log analyzer)

ii) UE sends SR but eNodeB does not capture/decode it.

Since SR is carried by PUCCH, the first thing you have to check is following SIB2 parameters.

i) sib2.radioResourceConfigCommon.pucch-ConfigCommon.deltaPUCCH-Shift

ii) sib2.radioResourceConfigCommon.pucch-ConfigCommon.nRB-CQI

iii) sib2.radioResourceConfigCommon.pucch-ConfigCommon.nCS-AN

iv) sib2.radioResourceConfigCommon.pucch-ConfigCommon.n1PUCCH-AN

and you have to ask yourself following questions.

a) Has UE properly decoded SIB2 and configure its own PUCCH parameter accordingly ?

b) Has eNodeB (Network Emulator) configure its own PUCCH decoding parameter properly matching these SIB2 parameter ?

When SR is transmitted, eNodeB (or Network Emulator) gets only PUCCH which takes up very small number of RBs. So total UL power tend to be very low comparing to the case where PUSCH is being transmitted. If eNodeB reciever's expected input level is set to be too high assuming that it will get PUSCH, the failure rate of PUCCH reception would tend to be high. You have to take into account this kind of situation especially when you are testing a UE with Network Emulator.

The dedicated SR resource matters as much as the SIB2 fields. RRC Connection Setup or RRC Connection Reconfiguration carries SchedulingRequestConfig, with sr-PUCCH-ResourceIndex and sr-ConfigIndex. The first selects the PUCCH resource, and the second sets the SR period and subframe offset. The eNB must look for the SR on exactly this resource.

The UE log also tells you whether the SR went unanswered. The UE repeats the SR up to dsr-TransMax times, from n4 to n64. After that it releases PUCCH and SRS and starts a Random Access procedure (36.321 5.4.4). So when a PRACH appears in the middle of a connected session, the eNB has often missed the SRs.

MIMO Related Issue

The first problem that I experienced was : "I just changed configured from TM1 to TM3, I think I got most of the parameter configured properly for TM3."

i) Number of Antenna = 2

ii) Number of Code Word = 2

iii) Number of Layers = 2

iv) CDD = Large CDD

v) Number of RBs = Same as TM1

Can you guess what I did wrong ?

It turned out to be because of item v). For SISO (TM1), we normally choose DCI type and Resource Allocation Type that allows any numbers of continguous RB, but in TM3 with multiple CodeWord we can specify the number of RBs only in the multiples of RBG. The number of RB in a RBG differs depending on the system bandwidth. So the possible number of RBs get different depending on the system bandwidth. For example, if it is 10 Mhz TM3 you can only allocate RBs in the multiples of 3 (e.g, 3,6,9,12,....).

Then you may have a question. Does it mean that I cannot allocate 50 RBs in case of 10 Mhz TM3 because it is not the multiples of 3 ?

Good Question. Yes, it is possible because of the exception rule saying "The last RBG in the system bandwidth can have less number of RBs than the normal RBG.". In case of 10 Mhz, RBG0~15 should have 3RBs in them, but the last RBG is allowed to have 2RBs in it.

For further details, refer to following sections.

• RB Size allocation for each System Bandwidth
• Resource Allocation Type
• Resource Allocation Type vs DCI format vs TM mode Mapping Table

CSFB - CS FallBack - related Issues

CSFB troubleshooting spans two RATs and two core network domains. The call starts with NAS signalling in LTE and finishes with RRC and CS signalling in UTRAN or GERAN. So the failure can sit in either half.

Many issues can happen during CSFB procedure. Followings are a couple of issues that I experienced while I was developing CSFB test scenario.

i) Network send 'CS Service Notification with Paging Identity', but UE does not send back 'Extended Service Request'. I even checked in UE log and confirmed UE received 'CS Service Notification with Paging Identity', but it didn't reply to the message.

ii) Network received the proper 'Extended Service Request' and Network sent 'RRC Connection Release with RedirectedCarrierInfo'. UE is supposed to send 'RRC Connection Request with cause of 'terminatingConversationalCall', but it sends 'RRC Connection Request with cause of 'registration'

I noticed that problem i) happened because I didn't configured LAI and TMSI in the Attach Accept message. Due to this, UE seems to think that the IMSI attach procedure was not complete(See the Combined Attach page for the proper configuration).

I am still seeking the solution for problem ii). I will post my findings later.

Let's look at problem ii) with 23.272 in mind. After the redirection, the UE reads the LAI of the new UTRAN or GERAN cell. If this LA differs from the one stored in the UE, the UE first starts a Location Area Update with the CSMT flag set (23.272 7.4). The LAU needs its own RRC connection, and the UE requests it with a registration cause. So the cause 'registration' can be expected behaviour. Check that the LAI given in Attach Accept matches the LAI broadcast by the target cell.

• CSFB depends on the combined attach : the Attach Accept must return the EPS attach result combined EPS/IMSI attach, with the LAI, before the UE treats itself as registered for CS services.
• A registration cause after redirection is not always a fault : the UE runs a Location Area Update first whenever the target LA differs from the stored one.

Measurement Control/Measurement Report related Issue

Measurement issues appear after the connection is up, when the network adds a measConfig to RRC Connection Reconfiguration. The UE links each measObject to a reportConfig through a measId. It sends a report only when the criteria in that reportConfig are met.

The common issues that I experienced with Measurement Report are as follows :

i) UE lose PHY sync right after it got measurement control (RRC Connection Reconfiguration with Measurement)

ii) UE does not send Measurement Report

iii) UE send Measurement Report but it does not include the specified measurement result

First, get familiar with the procedures described in 5.5 Measurements of 36.331 and get big pictures on how this process goes on.

For case i), some common cause that I have experienced are

a) RRC Connection Reconfiguration tries to configure a frequency which already is specified (This is network issue)

b) RRC Connection Reconfiguration contains a frequency which is not supported by UE (This would be UE issue. UE is still supposed to send Measurement Report which does not contains the result for the unsupported frequency).

For case ii), it is hard to troubleshoot this case since it may be UE side issue or Network side issue (RRC Connection Reconfiguration issue). Looking into both UE side log and Network side log and check if all the details meets to criteria specified in 36.331 would be the first step.

For case iii), this can be regarded as a normal behaviour or problemetic behaviour depending on the situation. If the RRC Connection Reconfiguration specified the unsupported frequency or a supported but not existant cell, the measurement report with missing result is regarded as normal, but if RRC Connection Reconfiguration specified the supported frequency and existing cell and UE does not send Measurement Report with proper result, you have to investigate why.

Some UE specific Issues

I don't know if I can call this "UE specific Issues" or if I have to say "Network Operator specific Issues". I have tested several UEs from the list that I put in [LTE UE] section. I would say "Each of the UE behave in a little bit different ways even when all of them are for the same network operator." and sometime I saw different behavior from multiple different version of the same model for the same network operator. This would be a lot of headache if you are the person who has to test various device from verious vendors.

I would list up several aspects that produce different behavior based on my personal experience (meaning that you would have different experience with different device).

• USIM Issue
• IPv6 Requirement
• IMS Requirement
• Antenna Configuration (Antenna Connection)
• AT Command Issue

< USIM Issue >

This is not a LTE specific issue. You may have had similar issues with WCDMA phone when you try to test them. It's the issue of SIM Lock. Most of the UE accept both Network Operater USIM and Test USIM (with PLMN = 001-01), but some of the UE accept only Network Operator USIM and does not accept Test USIM.

< IPv6 Requirement >

This would be the biggest headache for most of you. (It was like that at least for me). I saw several mode of behavior as follows.

• Some UE require IPv6 (at least IPv4/v6 Dual stack) at the first PDN (Default EPS Bearer). It means that it does not work with IPv4 only mode at the first PDN connection.
• Some UE allows IPv6/v4 dual stack, but UE automatically disconnect PDN when it does not get IPv6 Router Advertisement even though there is no problem with IPv4 connection.
• Some UE allows IPv6/v4 dual stack and maintain PDN connection if IPv4 is successfully established even when it does not get IPv6 Router Advertisement.

< IMS Requirement >

• Some UE disconnect PDN by itself if it does not get access to proper IMS server even when there is no problem with IPv4/IPv6 PDN connection.

< Antenna Configuration/Connection >

This problem didn't happen so often, but I saw a couple of cases for this (I saw more of this problem about a year ago when most of UE is at early development stage, but I see less when they became mature). I guess this is the issue with Equalizer on Reciever side. It would be difficult to figure out this problem when you test the UE in live network environment since the signal from eNodeB will automatically be received by the two antenna port.

• The downlink performance (throughput) for some UE gets very low (more than 50 % Physical Layer NACK) when it is connected by only one downlink Antenna port even when it is configured for TM1 (Single Antenna, Single Layer mode).

< AT Command >

If you are testing UEs from your own company, you would not have this problem since you may have direct connection with your developer to solve this problem, but if it is not the case this would give you a lot of trouble as well.

• Many UEs provide sets of AT Commands so that you can configure the settings in various ways. If the UE opens the full set of 3GPP defined AT commands, you may be able to solve the most of the problem described above. But in many case, most of UE manufactures lock most of AT command and opens very limited set of commands when they put the UEs into market.

Message Correlation Issues

Many LTE failures come from one message that does not match an earlier one. Each message can be valid on its own. But a field in it must repeat, or follow from, a value that the peer sent before.

Refere to Message Correlation pages on Quick Reference

Let's collect the pairs that this page has already met. In each pair, the second message must carry a value taken from the first one. A decoder checks one message at a time, so it never flags these mismatches for you.

• Msg4 must echo Msg3 : the UE Contention Resolution Identity in Msg4 must repeat the CCCH SDU of Msg3, or the UE does not send Message 5.
• Security Mode Command must replay the UE capability : the replayed UE security capabilities must equal what the UE sent in Attach Request, or the UE answers with Security Mode Reject #23.
• ESM messages must reuse the PTI : the MME copies the PTI of PDN Connectivity Request into Activate Default EPS Bearer Context Request.
• RRC responses must reuse the transaction identifier : RRC Connection Reconfiguration Complete carries the rrc-TransactionIdentifier of the RRC Connection Reconfiguration it answers.
• The allocated APN should fit the request : some UEs detach when the APN in the bearer setup differs from the one they asked for.

When a UE stops or detaches without a clear cause, compare these pairs before anything else. The diagram in the Correlation issue part of this page draws the NAS pairs.

Ping does not work

Usuall you would not try this with live network, but if you testing UE with test equipment, this might be the first thing you do before any kind of packet (IP) testing.

Most common issue would be as follows :

i) The IP you allocated to UE and the server IP does not properly assigned (e.g, they are in different subnet)

ii) UE or Server has firewall setting to block Ping

iii) Data Service on UE is turned off.

As far as I experience, most of the problem happens due to this common cause.. but if this does not work, now you have to check every point on the data path and you need to access to trace log or tools that enable you to check each of these points.

Case 1 : UE Packet App on UE PC -(1)-> UE IP Driver -(2)-> UE PDCP -(3)-> UE RLC -(4)-> UE MAC -(5)-> UE PHY

            -(6)-> RF Connection -(7)-> Equipment PHY -(8)-> Equipment MAC -(9)-> Equipment RLC -(10)-> Equipment

            -(11)-> Equipment PDCP -(10)-> Equipment TE -(11)-> Network Interface on Server PC -(12) -> Packet App

             on Server PC

Case 2 : UE Packet App on UE -(1)-> UE PDCP -(2)-> UE RLC -(3)-> UE MAC -(4)-> UE PHY

            -(5)-> RF Connection -(6)-> Equipment PHY -(7)-> Equipment MAC -(8)-> Equipment RLC -(9)-> Equipment

            -(10)-> Equipment PDCP -(11)-> Equipment TE -(12)-> Network Interface on Server PC -(13) -> Packet App

            on Server PC

Case 3 : Client UE Packet App on UE -(1)-> WiFi Stack on Client UE -(2)-> WiFi Connection

            -(3)-> WiFi Stack on Mobile Hotspot UE -(4)-> Hotspot UE PDCP -(5)-> Hotspot UE RLC

            -(6)-> Hotspot UE MAC -(7)-> Hotspot UE PHY -(8)-> RF Connection -(9)-> Equipment PHY

            -(10)-> Equipment MAC -(11)-> Equipment RLC -(12)-> Equipment -(13)-> Equipment PDCP

            -(14)-> Equipment TE -(15)-> Network Interface on Server PC -(16) -> Packet App on Server PC

Ping works but any other IP application doesn't works

In this case, good news is that at least there is no problem with data path. So it is highly likely that the issue is UE or Application configuration. The most common issue that I noticed were UE side setting. you can ask following questions to your self.

i) Have you created any APN on UE ? (You have to set proper APN as per UE requirement or per specific carrier requirement)

ii) Have you confirmed that Data Service on UE is set to be ON ? (Some UE works OK with Ping even when Data Service is Off but it does not allow any other IP application)

iii) Have you confirmed that 'Data Service on Roaming' on UE is set to be ON ? (Theoretically this is required only when you set PLMN to be VPLMN, but it would be safe to enable this option always regardless of PLMN setting)

If a test uses host names, check the PCO first. The UE can ask for DNS server addresses in the protocol configuration options of PDN Connectivity Request, with container 000DH for IPv4 and 0003H for IPv6. The network returns them in Activate Default EPS Bearer Context Request. Without a DNS server address, a browser test fails while ping by IP address works.

Packet size is the other common cause. Ping uses small packets by default, but web and file transfer traffic fill the full MTU. The network can send the IPv4 link MTU in PCO container 0010H. If the UE, the test equipment and the server disagree on the MTU, large packets are dropped or fragmented while small ones pass.

• A working ping proves only the small-packet path : it says nothing about DNS or about full-size packets.
• Check the PCO in the default bearer setup : the DNS server addresses and the IPv4 link MTU arrive there.

IMS Related Issue

Unfortunately I haven't seen any fixed patterns of trouble on this. It seems I have seen almost every possible problems at every stages of IMS/SIP based process. (For this type of troubles, first get your self familiarized to IMS/SIP signaling not only at the RFC level, but also at the level of other specification like 3GPP, GSMA IR, Carrier Requirement). I hope IMS section in this site is helpful.

At the very early stage of IMS implement, it was relatively easy to identify the problems and fix the issue since problems are relatively obvious.. like a certain SIP signaling message is completely missing.

As the basic IMS stack gets stablized, I haven't seen much of these obvious problem.. so just in terms of SIP signaling sequence it looks OK, but the functionality doesn't seem OK. Most of the problem at this stage were non proper parameter settings within a SIP signaling message. (Like UE is not using proper uri type. or UE is not using proper UE ID that is expected by network etc)

• Socket Type Related Issue : In most case, SIP messages are exchanged with UDP packet, but when the message length gets longer than a certain lenth, UA/Server changes packet type to TCP. Sometimes problem happens about this socket type changes.
• Port Related Issue : In most cases (at least in test environement), UA/Server tend to use port 5060 by default. In this case, usually no problem. But some UA changes the port number during a session for various reason (e.g, Internal Network Address Translation or Port Translated being implemented in UE) and this port change sometimes cause problem.
• Precondition Related Issues : If 'Precondition' was required as a mandatory items, a lot of issues happens around implementing this 'Precondition' (Try to understand Precondition mechanism in detail would help troubleshooting)

Before you do any IMS related issue, I strongly recommend you to go through my IMS check list first and make sure that all of those check items are met.

Throughput issues with Cat 4 and higher

Most of the problems for this case were about Max throughput (For the full details of factors influencing throughput, Refer to 'Throughput' section at the Home menu). Most common issues about Cat 4 were

• CFI value : Since transport block size became extremely large for one subframe and code rate gets increased accordingly, setting CFI value as small as possible would help achieving PHY/MAC layer throuput.
• In Cat 4 max throughput, the typical configuration is MIMO and MCS 28. In this case, PDSCH decoding capability is very sensitive to Radio Link Quality (e.g, RF Power, SNR). Make it sure that test environment is configured in such a condition where Radio Link Quality is good and you see no HARQ Nack/DTX.
• Using RLC UM in stead of RLC AM : In many case, it would be very difficult to achieve Max Cat 4 throughput (especially at 20 Mhz BW) with AM mode. Try with UM mode in this case.
• Data processing Power at RLC and higher level and internal buffer size : Simply changing CFI/RLC Mode would not help much as UE categories goes even higher like Cat 6 or Cat 4 Carrier Aggregation. If RLC and higher layer implemented for Cat 3/Cat 4 is used, it would not catch up the processing power required for this kind of super high data throughput.

Reference

• 23.272 v20.0.0 : Circuit Switched Fallback in EPS - clause 7.4
• 23.401 v20.0.0 : GPRS enhancements for E-UTRAN access - clause 5.3.1.2.2
• 24.008 v20.0.0 : Mobile radio interface Layer 3 specification - clause 10.5.6.3, protocol configuration options
• 24.301 v20.0.0 : NAS protocol for EPS - clauses 5.4.3.3, 5.4.3.5, 9.9.3.23, 9.9.3.34, 9.9.3.36
• 36.213 v19.4.0 : E-UTRA physical layer procedures - clauses 6.1.1, 7.1.6.1
• 36.304 v19.2.0 : E-UTRA UE procedures in idle mode - cell selection criterion
• 36.321 v19.3.0 : E-UTRA MAC protocol specification - clauses 5.1.4, 5.4.4
• 36.331 v19.3.0 : E-UTRA RRC protocol specification - clause 5.3.5.5 and the RACH-ConfigCommon, PRACH-ConfigInfo, PDSCH-Config and SchedulingRequestConfig IEs